Aller au contenu

davidm

Hubmaster
  • Compteur de contenus

    1 589
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par davidm

  1. Il faut que tu vérifie que le charset de la page où se situe ton formulaire est bien défini, et que form.subscribe.tpl est bien enregistré avec le même charset que ta page... 10 contre 1 que la page dans laquelle tu as inséré ton formulaire est en latin1 (iso8859-1) Sachant que form.subscribe.tpl est par défaut enregistré en UTF-8... ceci explique cela
  2. Oui j'ai utilisé LimeSurvey mais je ne pense pas qu'il réponde à ton besoin à moins que les formulaires que ton utilisateur final ai besoin de créer des enquêtes en ligne / sondages. Par contre, je serai toi j'irai voir du côté de TYPOlight et du module formauto, car c'est l'outil de création de formulaire le plus simple que j'ai vu, le plus fort étant que les tables sont créés automagiquement et liés aux champs que tu créé (le tout est totalement visuel pas une ligne de code, à part si tu mets en place des regex mais bon, faut pas non plus en demander trop...). Sinon en payant (39$, pas cher) et complètement dédié à la création de formulaire tu as MachForm
  3. Bon il doit forcémment rester des chaînes mal traduites, je n'arrête pas de trouver de nouvelles boulettes, erreurs, contre sens... et je me dis que j'aurai mieux fait de repartir de zéro que de repartir du fichier FR existant Ceci étant, l'essentiel doit être à peu près OK donc voilà la traduction. Je précise que j'ai encore un travail d'homogénéisation et de correction fine à faire. Si vous voyez des choses, merci de me faire signe ! poMMo_fr_davidm.zip
  4. Euh, je ne comprend pas ta réponse (???). Maintenant la traduction ne t'intéresse plus ? Et il faudrait quelques explications sur le fameux "serveur blanc". C'est quoi la définition d'ailleurs ? Un serveur avec SPF, que tu whitelist chez les FAI en faisant des requêtes, en t'assurant que tu ne fais que du opt-in et en utilisant un logiciel qui évite de bombarder les destinataires au delà d'un certain seuil ? Qu'est-ce qui empêcherait poMMo de faire des envois propres à partir d'un serveur blanc ? Quelle est la différence avec SnipeMail ? J'imagine que tu as du tracking derrière ? Ca n'est pas sarcastique j'aimerai comprendre... Et pour remettre les choses à plat, je te posai la question par rapport à ça : Quand tu dis 50 euros pour un serveur blanc, je pense que c'est légitime de demander si c'est 50 euros, 50 euros par mois, 50 euros par envoi... ? Si je pose la question c'est que j'aime savoir quelles sont mes options lorsque je conseille mes clients. Et en l'occurence vu que tu as l'air de savoir de quoi tu parles ça veut dire que je peux ramener potentiellement du business
  5. Encore 2/3 jours à reviser la trad, et je met ça en ligne... (50 euros, par mois ?)
  6. Juste pour info, j'ai repris complètement la traduction de poMMo qui était vraiment médiocre (sans compter qu'elle était incomplète). Je suis en train de rebalayer ça "en contexte" car il reste encore probablement du travail mais je vais bientôt publier une version "finale".
  7. Je ne suis pas expert Joomla mais Google est ton ami Réponse en 15 secondes : il faut apparemment activer la retro-compatibilité ("legacy mode"), apparemment il suffit d'activer le plugin "Legacy Mode" (intégré à la 1.5 si j'ai bien compris). Par contre après avoir lu en diagonale, c'est pas top pour la stabilité. Je crois que c'est indiqué sur la page de jFirewall que ça ne marche pour la version 1.5 qu'en legacy mode d'ailleurs, c'est une extension pour 1.0.x ... L'urgence ce serait de lire la notice
  8. On en a parlé effectivement, je vois que tu suis Twitter Evidemment c'est dans l'optique de faire un article public, pour l'instant c'est au stade d'idée il faut qu'on voit sous quel format on fait ça...Personnellement je pense que TYPOlight se recoupe plus avec Drupal que modx, au moins au niveau de la couverture fonctionnelle encore que bien sûr Drupal a plus de addons... Il faut que je me replonge un peu dans Drupal pour l'occasion (ça remonte à loin mes derniers tests approfondis !), l'installation de la 6.8 est au programme ce week-end. J'ai bien envie de jouer un peu avec le module Views notamment, si c'est aussi flexible que Ditto il y aura peut-être moyen de monter des projets sous Drupal (non je ne suis pas sectaire ). Idem pour CCK... ce sont les deux éléments qui m'intéressent le plus. Côté taxonomy, oui c'est vraiment un module qui est un gros avantage de Drupal... j'attend avec impatience que celui de TYPOlight soit au point pour d'autres contenus que ceux de Catalog !
  9. Content de voir que le must-have CCK (pour les modxiens, nos chères TV) va être intégré dans Drupal (puis Views... pour les modxiens un peu comparable à Ditto) et que les champs customs vont être un des focus de Drupal 7 Apparemment ces modules sont devenus clés et le décalage entre la release et la mise à jour de module clés a un peu pénalisé l'adoption... bien vu, Dries, du moins si cela ne pénalise pas la sortie de la release elle-même Par contre je ne partage pas forcémment l'analyse de Dries qui conclu que 2009 vera la confirmation de la tendance de 2008, à savoir le renforcement de la domination des "Big 3" (Drupal, WordPress, Joomla!). Le "while many of the other systems faded into the background a bit" est une erreur à mon avis, je ne pense pas que les CMS plus jeunes s'effacent... attention au raisonnement qui consiste à penser "We're the best platform today, and others will have to move in to stay viable". Il est facile d'ignorer les "signaux faibles" lorsqu'on est en position de force et la réussite d'aujourd'hui peut se transformer en échec de demain si on est pas conscient que la concurrence peut changer les règles du jeux en quelques mois... De ce point de vue, lorsqu'on est attentif aux évolutions et aux concurrents émergents, on peut penser que la donne est peut-être en train de changer et que la maturation des frameworks web comme Symfony, CodeIgniters, CakePHP, Django... va donner naissance à de nouvelles applications et je suis prêt à parier que ces applications vont être extrêmement compétitives. L'exemple de Expression Engine 2.0 est illustratif (nous verrons quel succès EE 2.0 aura mais perso j'identifie comme un compétiteur clé de modx revolution par exemple), avec une ré-écriture complète sur la base de CodeIgniter. Le bénéfice potentiel que je vois c'est la rapidité de développement, la flexibilité liée à l'utilisation d'un framework et surtout le potentiel d'intégration avec d'autres applications bâties sur le même framework. Alors évidemment tout dépend de la base de développeurs existant sur un framework donné et le nombre d'appli existante... cela prendra peut-être du temps mais il faut garder un oeil là dessus. Mais là je suis peut-être plus déjà en 2010 Quoiqu'il en soit, la roadmap pour Drupal 7 est prometteuse mais il ne faudrai pas un peu vite ignorer la compétition qui va s'intensifier... je pense que ce serait une erreur. Je pense aussi que derrière les big 3, CMS Made Simple a progressivement consolidé sa position, en embuscade... Même s'il y a débat sur les applis qui ont fait le choix de PHP5 vs PHP4, et qu'on peut défendre que l'approche procédurale est plus efficiente que l'OO dans certains cas (cf http://api.drupal.org/api/file/developer/topics/oop.html) il n'en reste pas moins que l'avenir de PHP est OO et qu'il faudra bien y passer... Drupal y compris
  10. Non non Evolution est un "rebranding" de modx 0.9.x accompagné d'un nettoyage de printemps côté code. C'est une version qui est transitoire pour ceux qui n'adopterons pas tout de suite Revolution mais l'avenir de modx c'est bien Revolution dont le code n'a plus rien à voir avec la branche "historique" et qui va ouvrir un nouvel univers aux utilisateurs de modx. Dès que la Beta sera dispo (T1 2009), vous verez un peu mieux de quoi il retourne mais l'enjeu numéro 1 c'est la conversion des addons à mon avis c'est ce qui fera que les gens adoptent ou pas Revolution.
  11. Intéressant en effet, j'avais raté Flutter... Merci !
  12. ...ce qui est inévitable lorsqu'on fait un bond de ce type de matière d'architecture sous jacente Par contre ils auraient pu faire évoluer l'interface d'admin que je n'ai jamais trouvé super top... question de goût sûrement. Pour le support réactif de SPIP vrai mais alors quel horrible système de forum à lire et à utiliser... je trouve ça rebutant !!!
  13. ... et aucun SPIPien pour relayer l'info ? Je vous conseille fortement la lecture de cet article qui synthétise les évolutions et les choix architecturaux pour cette version majeure (qui passe à la GPL v3 d'ailleurs), dont voici le résumé : De sacrés évolutions donc, personnellement je retiens la gestion des URLs, la gestion des éditions concurrentes (lisez l'article vous comprendrez ! Une fonctionnalité clé pour des sites à contenus éditoriaux), le support de PostGreSQL et SQLite, la possibilité d'utiliser des bases multiples / serveurs multiples, l'ajaxification de #INCLURE, possibilité de provoquer une jointure entre deux tables SQL en écrivant directement la notation TABLE.NOM dans un critère (cool !)... et j'en passe. Reste à évaluer concrètement l'outil mais on peut dire que c'est un évènement dans le monde des CMS open source francophone (et au delà ?). La note en fin d'article illustre bien l'intention des développeurs : Wait and see, mais cela méritait d'être signalé ici
  14. A noter MODx 0.9.6.3 est sorti le 24 décembre Cette version apporte de nombreuses améliorations (une centaine de modifs dans le changelog) dont certaines sont vraiment importantes : nouvel installeur qui met définitivement un terme aux problèmes d'encodage et de collation de la BDD rencontrés par certains d'entre vous depuis le passage de SET NAMES à SET CHARSET avec la 0.9.6.2 (plus "propre" mais qui a soulevé de nombreux soucis). des contrôles additionnels du côté du manager et un meilleur reporting d'erreurs plusieurs fix de sécurité (notamment meilleure protection contre XSS) Téléchargement, comme toujours ici : http://www.modxcms.com/downloads.html Billet sur le blog (en anglais) : http://modxcms.com/another-year-for-modx-a...ew-release.html A noter il s'agit de la dernière release de la branche 0.9.x 2009 vera la sortie des deux branches Evolution et Revolution. Evolution 1.0 bénéficiera d'un code optimisé qui continuera a utiliser le parser actuel alors que Revolution est une ré-écriture complète de l'application avec un nouveau parser qui apporte la récursivité, la possibilité de passer des paramètres dans les chunks, de définir via le manager les valeurs par défaut pour un snippet, et de nombreuses améliorations (notamment les tests conditionnels seront natifs et non plus via le plugin PHx). Revolution est construit sur la base d'xPDO (prononcer OpenExpedio), qui fourni un ORM "sur-mesure" codé par Jason Coward (OpenGeek) pour MODx. Pour les pros, une version light de Propel avec des choix architecturaux un peu différents que je ne suis pas qualifié pour vous expliquer ! Faites un tour sur http://xpdo.org Revolution apportera aussi un outil d'importation de vos sites sous MODx 0.9.x / Evolution ou encore un outil de gestion des addons depuis le manager... liste non exhaustive ! Vous verez aussi : - un nouveau site pour modxcms.com - un nouveau repository si on peut l'appeler encore comme ça (le nouveau repo s'appelle web transport facility). - un site pour modxcms.fr (encore un peu de contenu à boucler mais j'espère être en mesure de mettre en ligne pour le 1er janvier )
  15. Concernant la logique de construction de Drupal et pourquoi la dév team a choisi de ne pas opter pour un passage à la POO (cela a suscité des discussions nombreuses sur le web, exemple ici), cet excellent article (en anglais) qui approfondi pas mal aussi les choix architecturaux derrière Drupal (notamment une partie intéressante sur les hooks). Pour l'attitude de Léo et le faible niveau d'activité sur les forums anglophones, ce sont aujourd'hui les 2 gros points faibles de Typolight... pourtant le produit lui-même est vraiment impressionnant ! J'avoue que j'ai des doutes car c'est un aspect clé pour un CMS open source, une des raisons qui m'a conduit à quitter la communauté de Textpattern et à ne plus l'utiliser alors que c'est (était) un excellent CMS. Je suis en train de ré-approfondir CMS Made Simple qui a beaucoup évolué et la logique textpatternienne de son système de tag combiné à une dynamique communautaire forte et une aptitude à couvrir des zones où modx est plus long en déploiement est assez intéressante. Silverstripe reste sur mon radar aussi avec un langage très puissant et un code OO dans la tendance. TypePublish est à surveiller aussi... autre Outsider, TangoCMS, encore jeune mais à surveiller.
  16. Si tu es à fond dans Drupal et qu'il te convient bien, je doute que tu trouves un plus dans Typolight (la couverture fonctionnelle native est assez similaire) si ce n'est peut-être au niveau de l'interface d'admin (qui pour moi est bien plus claire et logique mais chacun voit midi à sa porte) ou de la façon de gérer certains aspects (par exemple le multi-site est horriblement facile avec Typolight, je viens de configurer ça et ça roule tout seul vraiment ultra puissant) ou encore l'API / la clarté du code (il faudrait que je relise un peu Drupal depuis la version 6.x par contre ça a peut-être bougé).
  17. Ah les problèmes de terminologie ! articles, pages, billets... le terme va changer en fonction de l'orientation première du CMS (éditorial -> article, blog -> billet, cms avec arborescence -> pages...). Parfois même, ces concepts vont cohabiter (wordpress a aussi ses "pages", et même un plugin qui permet de gérer une arborescence, cms made simple a des pages mais aussi des articles gérés par le module de news : idem pour typolight, etc....). Sinon effectivement Karnabal a raison de dire qu'on a tendance à conseiller les solutions avec lesquelles on a des affinités, en même temps c'est logique on les connaît mieux... ceci dit, ici on parle de catalogue produit, avec probablement la nécessité de comparer les items. A défaut on sort de la structure pré-établie et souvent rigide dispo dans la plupart des CMS : titre, sous-titre, résumé, contenu... ou autre structure prédéfinie qui va être liée à un module (par exemple un module de catalogue). Donc sur ce point précis j'ai envie de dire : TYPOlight + Catalog, Drupal + CCK ou modx peuvent convenir car on peut créér des catalogues avec des champs customs facilement, les lister en templatant le rendu, les trier via des listes déroulantes, ou proposer un moteur de recherche par critère... Si on veut vraiment du simplissime en matière de CMS voir aussi Zimplit mais là on est pas dans des contenus "typés" séparés en différent champs, on retombe plus dans de la gestion dynamique de page toute bête...
  18. Oui c'est ce qu'on disait avec Alexandre, il faut approfondir la définition du besoin pour se prononcer, plus prendre en compte les facteurs d'appropriation et d'affinité vis à vis de la solution puisque plusieurs peuvent convenir... Je pense que la vitalité et le nombre de contributeur côté modx n'est plus à démontrer... l'absence de certaines fonctionnalités natives par contre (versionning, multi-linguisme...) est un handicap. Pour Typolight le problème est plus du côté du support anglophone trop faible (j'ai mis un point d'honneur à aider les gens sans réponses côté english, quand je peux...) et l'attitude de Léo parfois un carrément autocratique (par exemple, j'ai soumis deux tickets via Trac, zappés sans explication et je suis même interdit de soumission de bug !!! Un peu étonnant quand on sait que j'ai contribué à plusieurs communauté et pas seulement modx et que je ne suis pas un newbie... un échange de mail avec l'intéressé n'a rien changé - et je n'ai pas plus compris pourquoi (aucune réponse)... soit... moi je mets un gros mauvais point là ! Ou alors c'est une incompréhension culturelle entre français et allemand ? J'avoue ne rien y comprendre...). Heureusement la communauté française avec un leader de choc en la personne de Cyril Ponce est gérée totalement différemment !!! Côté Drupal, je ne sais pas, j'ai toujours eu du mal avec le forum natif qui ne me plaît pas du tout...
  19. Oui Drupal n'est pas un des CMS les plus répandu et primé pour rien Ceci dit sur ces points précis TYPOlight est aussi très impressionnant, notamment au niveau de la création de formulaires liés à des tables et champs customs créé "automagiquement" par le module formauto sans toucher à une ligne de code (!!!), quand on voit la galère que c'est avec modx et eForm (eForm2db est trop embryonnaire...), ça laisse pantois...
  20. Ok, bon l'intégration de vidéos ça ne devrait pas poser de problème quelque soit la plateforme avec les différents players qui existent soit pour du flv (mais alors se pose la question de l'étape "conversion" de la vidéo en flv), du quicktime ou de l'avi. Il existe des modules qui ajoutent automatiquement le player et sont faciles à paramétrer. Pour le catalogue, idem tu as différentes solutions. Typolight a une extension vraiment bien faite pour gérer ça (et les filtres / la recherche avancée qui va bien) mais ce n'est pas le seul. L'autre facteur à prendre en compte c'est que tu vas devoir t'approprier le CMS que tu vas proposer à ton client, et lui aussi. Donc il faut que tu teste avant pour être sûr que tu vas pouvoir maîtriser l'outil et déployer rapidement un site avec.
  21. Je pense que CMS Made Simple n'est pas à exclure non plus... depuis la 1.4 il y a eu de gros progrès et il y a pas mal de modules dispo aussi, et le language de template à base de tag est très facile à adopter quand on vient de textpattern ou de modx. Côté template Drupal ou Typolight à mon avis c'est plus une question de se sentir à l'aise avec l'un ou l'autre qu'un avantage intrinsèque. Drupal on rentre dans la logique ou pas, c'est un peu trop nerd/geek pour moi. Sans être codeur, j'arrive à m'y retrouver dans typolight, c'est clair et la logique me parle... mais bon j'ai toujours été plus sensible à l'OO (ça donne envie de s'y mettre). Pour ce qui est du nombre de modules, franchement c'est un argument qui a ses limites... on a déjà 60 modules pour TYPOlight dont la majorité couvre bien 90% des besoins les plus courants. La question est plus, à mon avis, de savoir si - quand on a besoin des 10% - le développement d'un module sur mesure sera rapide ou non, facilement templatable ou non, avec un modèle de données customisable et facilement évolutif ou non. Evidemment si on a un besoin spécifique dès le départ et que tel CMS dispose déjà de l'extension pour le satisfaire, cela va orienter le choix mais ça ne me semble pas être le cas ici. Pour prendre un exemple, j'avais besoin de développer l'exportation d'une base de données adhérents construite sous modx avec des TV vers une base de données avec des champs custom sous Excel à destination d'un imprimeur. Avec un CMS traditionnel j'aurai cherché un module qui permette d'exporter mes données et si il n'existe pas il aurait fallu développer un module custom en php. Avec modx, j'ai simplement utilisé Ditto en créant un template formatté en CSV qui permet à l'imprimeur de récupérer le fichier. C'est bête et méchant mais très efficace. Donc on peut aussi dire que modx a moins de modules que certains CMS mais on peut faire beaucoup de choses avec certains snippets (Ditto en premier) sans jamais avoir besoin de modules spécifiques. Je pourrai citer au moins 5 exemples du même genre de logique... modx fait descendre au niveau du designer la logique "légo" qu'on trouve habituellement à un niveau d'abstraction supérieure (l'API) réservé aux codeurs. TYPOlight ou Drupal sont des CMS avec une API puissante tout comme modx mais par contre faute de coder, il est bien plus difficile de customiser ici et là les choses sans module additionnel... Pour ce projet ça ne dépend pas seulement de l'adéquation fonctionnelle mais aussi de qui va travailler dessus et de leur attirance vers tel ou tel CMS qui va convenir à leur façon de travailler, à leur compétences / expériences, etc...
  22. Il y a même un sujet épinglé pour expliquer ce qu'est un CMS : http://www.webmaster-hub.com/index.php?showtopic=14228 Mais j'imagine que tu sais déjà que tu as besoin d'un CMS, puisque tu as posté dans le bon forum Sinon, difficile de répondre à ta question (quel outil choisir) sans savoir de quel type de site il s'agit (contenus et types de contenus, fonctionnalités attendues...etc) même si étant géré en statique c'est probablement un site plaquette...
  23. Oui ça signifie qu'il faut un hébergement Zope, petite liste ici : http://www.zope.org/Resources/ZSP/ Je viens de découvrir qu'il existe des hébergement gratuits pour Plone : http://objectis.org/ http://www.ingenihosting.com/hosting/pppersonal A voir...
  24. Oui c'est ce que disai Alexandre 2 posts plus haut ... Drupal est une des possibilités.
  25. La 2.6.3 est dispo depuis quelques jours... Attention à bien prendre en compte l'impact sur les templates list_*.tpl et memberlist.tpl (mineur mais à savoir) : http://typolight.org/forum/topic/9282.html J'en ai profité pour acheter une licence liveupdate et c'est tout simplement génial, je viens d'acquérir une ID pour 3 domaines (moins de 14 euros, de la rigolade) et de faire la MAJ pour ces trois domaines et à chaque fois ça a pris moins de 30 secondes et tout marche : même pas besoin d'utiliser le backup créé automatiquement pour faire un rollback ). Maintenant qu'on dispose aussi de ce type de service pour les extensions (gratuit, nécessite juste l'extension SOAP activé sur votre serveur), c'est le rêve côté maintenance... A noter pour le liveupdate, si on utilise le multi-site on ne paye bien sûr que pour un domaine si on gère plusieurs domaines avec une install : cool !
×
×
  • Créer...