davidm

Ok merci pour la clarification Ceci dit qu'est-ce qui empêche quelqu'un d'utiliser poMMo sur un serveur blanc ? Et comment faire de son serveur un serveur blanc ? Dan : il existe des moyens pour ça sur nos dédiés ? Ca coûte combien ???

J'avais cru comprendre que cela dépendait de l'identification du serveur en tant que "serveur blanc" et non de l'application elle-même : explications ? Sinon il ne faudrait pas confondre solution gratuite = mauvaise solution. Le modèle open source a démontré sa capacité à produire des applications de très haut niveau (à commencer par 70% des serveurs de la planète). Si je prend l'exemple des CMS, il est clair que "gratuit" ne veut pas dire "cheap", "pas pro"... maintenant ça ne veut pas dire que côté gestion de liste de diffusion une appli comme phpList soit au niveau (d'ailleurs, que penses tu de celle là ?), mais faire passer le message que "gratuit" = mauvais L'économie de l'open source est fondée sur la valeur ajoutée par les services autour de l'application et non la commercialisation de l'application elle-même. Ceux qui me connaissent savent que je ne lésine pas sur les moyens La question n'est pas là : il faut dimensionner les moyens par rapport aux objectifs. Encore une fois je n'ai pas dit que poMMo prétendait rivaliser avec des solutions "pros" ! Si j'ai un client qui a des besoins, je sous-traiterai cette partie de la prestation à plus spécialiste que moi, c'est ma politique. Tes arguments tiennent la route, et je suis le premier à tenir le même discours aux décideurs que je rencontre. Le domaine de la création de site web est plein de prestataire "pas cher" qui ne savent pas ce qu'ils font, qui appliquent des templates "tout fait" en copier-coller et on un code horrible , non standard, non accessible... etc. Donc oui j'imagine le point de vue que tu dois défendre. Une prestation de qualité a un prix. Par contre je m'élève contre l'association "solution gratuite" = amateurisme ou basse qualité... du moins en ce qui concerne l'open source... Encore une fois, si le débat n'avais pas été placé sur cette question depuis le début par Wefficient, on ne serai pas en train de dire quelque chose que je n'ai jamais dit ! J'avoue que je n'ai pas vérifié... dommage que les concepteurs n'aient pas utilisé jQuery ou mootools, qui se dégradent plutôt bien. Bonne remarque, même si franchement, je ne suis pas non plus pour le fanatisme anti-js pour une appli... autant pour un site web c'est évident qu'il faut que tout se dégrade correctement mais là... Et puis si on applique ce principe, pas sûr que même les solutions pro soient exemptes de js ou avec un js qui se dégrade bien...

Merci pour ces réactions très instructives, même si à mon sens on est sur un autre segment que celui visé par poMMo Pour un site qui souhaite mettre en place une newsletter, sans faire de l'analyse poussée, c'est largement suffisant. Tout le monde n'a pas besoin (ou pas le temps !) de faire du tracking... Maintenant, à chacun son besoin effectivement ! @Wefficient : intéressant ton blog (par contre typepad rame pour le chargement des pages... )

Ca fait longtemps que je n'avais pas fait partager un de mes coups de coeur... pour ceux qui ne le connaîtrait pas, poMMo (anciennement bMailing) est un outil libre (GPL) qui permet de gérer une liste de diffusion / newsletter. A l'opposé de phpList par exemple, le parti est pris d'avoir une interface légère (aromatisée à la sauce AJAX d'ailleurs, merci jQuery) et où l'on peut se repérer facilement. L'accent est mis sur la flexibilité et la légèreté de l'application donc, mais côté fonctionnalités on a l'essentiel et même plus : interface simple pour créer des champs custom au sein du profil des abonnés création automatisée d'un formulaire personnalisé à insérer sur votre site l'interface est facilement thémable via smarty "variateur" (throttle) permettant de contrôler la charge du serveur (rythme d'envoi des mails) URL pour consultation en ligne des newsletter archivées et bien plus... Une démo valant 10 000 mots, faites vous une première idée ici (l'appli est francisée) : http://try.pommo.org/admin/admin.php

Hâte de voir ce que ça donne après une beta 1 assez buggée qui ne permettait pas de réllement apprécier ce que la 1.5 apportera... merci pour la news !

Cool, ça veut dire que je fais bien mon job alors Sans rire, MODx m'a convaincu en quelques minutes de test, et jamais déçu depuis... être convaincu ça aide à être convaincant Cf le lien que j'ai posté plus haut, j'ai créé un thread sur les forums de MODx qui liste les sujets comparant MODx à d'autres CMS : Pourquoi choisir MODx plutôt qu'un autre CMS ? Mais tu pourrai aussi lire celui là, plus ancien : http://forum.textpattern.com/viewtopic.php...=101001#p101001 (désolé, in english) Il faut bien distinguer le concept de catégorie, dans Textpattern, qui est équivalent au concept de mot clé dans SPIP ou de tag dans plusieurs systèmes de blog (i.e un moyen "tranversal" de catégoriser l'information) et celui de section qui correspond aux rubriques dans SPIP ou au dossiers dans MODx. Dans SPIP tu as des sous-rubriques jusqu'à N niveaux, et dans MODx tu peux avoir un nombre ilimité de dossier imbriqué. Il y a une relation hiérarchique c'est à dire qu'un document ou un article est l'enfant d'un autre. Les catégories ne sont pas hiérarchiques. A moins que cela n'ai changé, ou qu'un plugin soit apparu pour contourner ça, avec textpattern tu ne peux pas avoir des URLs avec plus de trois niveaux de profondeurs hiérachique (section/categorie/sous-categorie). C'est une limitation pour un site corporate dans bien des cas, même pour une PME ou une association... C'est probablement la raison pour laquelle nous étions plusieurs a demander au moins des sous-sections, mais c'est resté lettre morte (encore un truc qui me fait penser que Textpattern stagne depuis que Dean est parti).

Je te conseille de lire : J'hésite entre Joomla et MODx, lequel choisir ? ou encore Pourquoi choisir MODx plutôt qu'un autre CMS ? C'était la minute de pub Sérieusement, je vais répondre en détail... Par approche modulaire de Joomla, tu parles des extensions ou alors de la flexibilité de l'outil ? Si c'est l'approche "en 1 clic" des extensions, il est certain que Joomla est l'outil qui permet de mettre vite en place des solutions standards. Maintenant côté modularité, ça reste à voir... Du moins ça dépend de ce qu'on appelle modularité : pour moi ça veut dire la capacité de l'outil à répondre sélectivement à des besoins spécifiques (c'est d'ailleurs ce qui m'a poussé à choisir MODx...). Et dans ce domaine, je pense que MODx n'a pas vraiment d'égal : contrôle total -> le système et ses extensions laissent la main sur le design : quasiment tout le code généré par les extensions dispose de micro-templates, qui permettent de contrôler à 100% le code en sortie. MODx donne accès à toutes les variables manipulées par le snippet via ce qu'on appele des conteneurs, avec une syntaxe simple : [+ma_variable+] qu'on insère au choix dans le code html qu'on a écrit soi même (et non généré par l'extension !). Autrement dit, on n'affiche que ce dont on a besoin, où on en a besoin ! Et si vous avez besoin de champs additionnels, vous avez à votre disposition les variables de modèle. C'est un aspect crucial pour proposer des sites totalement personnalisé aux clients. Liberté -> aucune structure de données pré-définie : grâce aux variables de modèles, on peut ajouter des champs additionnels de n'importe quel type (texte, RTE, dropdown, checkbox, image, url...), et sans limite de nombre. Mieux encore, ces variables sont associées à un template (et bientôt, document par document), et on peut gérer le droit d'accès à ces champs. Avec les @bindings, on peut même lier ces variables à une BDD externe, à un fichier, à un snippet... c'est très puissant ! Et surtout, cela permet de vraiment coller au besoin des clients (franchement, la structure Introduction / Corps du texte est vraiment limitée... là l'avantage c'est que tu as vraiment des données structurées champ par champ et non tout dans un même champ). Besoin d'un catalogue produit ? Facile, il suffit de définir un template fiche produit, associer les variables de modèle choisies, styler le tout via CSS et hop modularité -> ré-utilisation du code : les chunks permettent de ré-utiliser des bouts de code (comme dans Textpattern ou CMS Made Simple). Là où MODx pousse la logique un cran plus loin c'est qu'on peut à la fois se servir de cette logique dans les templates mais aussi dans les feuilles de style pour peu qu'on utilise les feuilles de style dynamiques (c'est à dire, stockées en tant que document MODx... donc, parsées ). C'est très facile alors de créer des blocs ré-utilisable de code pour manager plus facilement la maintenance et l'évolution de celui-ci. A noter on peut aussi introduire des test conditionnels dans les CSS Evidemment, je ne vais pas forcémment être d'accord sur tout ce que tu viens de dire 1) L'admin de MODx, pour un utilisateur, est très simple. Je peux le confirmer parceque parmi mes clients j'ai des personnes très peu familière du web et de la micro-informatique en général, qui s'en servent sans problème avec une simple doc (pas même besoin de formation). 2) Le support francophone : là je vais te contredire, va faire un tour sur les forums et regarde les délais de réponse, le nombre d'utilisateurs experts (je pense autour de 25 personnes aujourd'hui) dont Heliotrope qui fait partie de la coding team. Tu verras que le forum est dynamique et que les réponses sont rapides 3) La documentation : là oui admettons que la doc souffre d'un manque de contenus, particulièrement pour les extensions majeures mais le support compense ça en partie. Ca va venir, sache que je bosse actuellement sur modxcms.fr et que j'ai une équipe d'une douzaine de personne qui bossent avec moi pour qu'en septembre on ai quelque chose qui vienne combler ce problème. 4) La courbe d'apprentissage : effectivement, il faut investir du temps pour acquérir les bases mais la liberté sans pareil de MODx est à ce prix 5) La maturité : ayant plusieurs site client qui tourne sous MODx, je peux garantir que c'est un produit tout aussi stable que Joomla, et d'après plusieurs benchmark, plus rapide. La version 0.9.6 qui sort d'un jour à l'autre est une version extrêmement mature et stable, ne pas se fier au numéro de rév inférieur à 1.0 (ça ne veut rien dire). Pour Drupal je laisserai Vincent ou Claire en parler, mais pour Textpattern auquel j'ai contribué pendant 2 ans (modo du forum notamment, et traducteur), je peux dire que c'est un excellent CMS qui a beaucoup de point commun avec MODx (l'esprit est similaire, extensions templatables, modularité, flexibilité, contrôle du design) avec quand même un élément clé qui le pénalise pour le site corporate : le nombre de niveau hiérarchique dispo (3) est parfois trop faible pour de gros sites (d'ailleurs la remarque vaut pour Joomla !), là où MODx n'a pas de limite (grâce à un concept d'arborescence de documents, différent du concept d'article avec catégorie et section/rubrique). Drupal, sinon, est pour moi le seul véritable concurrent de MODx

En même temps les infos sur cmsmatrix sont parfois obsolètes (même quand on veut les mettre à jour, pas facile d'avoir une réponse des admin... ) Ceci dit, en matière de multi-linguisme côté open source peu mieux faire... on a peut de choix effectivement pour des solutions natives... dommage. Ca force à aller vers des paquebots du genre, peu maniables... ou alors à mettre en place des solutions "bricolées" (qui marchent parfois bien, en fonction des cas) Question quand même : pourquoi avoir éliminé Drupal et son module i18n (qui me semble être le meilleur compromis, mais en même temps je n'ai que des témoignages sur i18n, pas testé moi-même) ?

Pour ceux que ça intéresse, la sortie de la 0.9.6 finale est imminente, question d'heures maintenant

La version finale est imminente, et sera très proche de la RC3 (quelques bugs mineurs corrigés). Toujours difficile de dire avec précision ce que fera la dev team, mais il est quasi certain que d'ici la fin de la semaine, on aura la version finale La 0.9.7 beta sortira quelques jours après, pour ceux que ça intéresse... ce sera une "early beta" peu stable et la plupart des extensions ne fonctionnent plus, nouveau core oblige... mais ça va permettre de se familiariser avec xPDO

Je dirai même plus, mootools a remplacé script.aculo.us au sein du manager, donc MODx est "mootools powered" Pour la date, question de jour... très prochainement !

Salut Effectivement c'est un questionnement légitime, étant donné que l'on bifurque vers le nouveau core. Gildas un des dév français explique bien sur les forums de MODx (cf ce post)ce que va amener xPDO : Alors évidemment, comme je l'ai rappelé à deux ou trois reprises, cela va nécessiter une ré-écriture du code des extensions. Mais mon point de vue, sur ce sujet, c'est que la 0.9.6 (sortie de la version finale imminente) propose déjà un niveau de flexibilité rare pour un CMF open source s'appuyant sur PHP. Avec les dernières touches apportées, cette version est hyper stable et bénéficie du remplacement de script.aculo.us par mootools côté backend et frontend (QuickEdit) ainsi que d'améliorations appréciables d'utilisabilité. Pour moi, ça ne vaut pas le coup d'attendre, de plus il est certain que les extensions majeures de MODx (Ditto, Wayfinder, Jot, eForm...) seront ré-écrites et distribuées avec MODx 0.9.7 finale (la beta ne disposera probablement pas de ça par contre). Et connaissant le talent et la passion des dév d'extensions pour MODx, je doute que la transition soit si longue pour les autres extensions On peut être sûr, aussi, que tout sera fait pour que l'upgrade de 0.9.6 > 0.9.7 soit aussi simple que possible. Je ne vois pas de raison d'attendre, sauf peut-être pour des projets ou l'on utilisera une base de données autre que MySQL, ou qui nécessite un ORB. Mais même là, il est possible d'installer xPDO pour la 0.9.6. Au fait on est maintenant en RC2 : http://modxcms.com/beta.html et dans les heures qui viennent, en version finale

A mon avis tous les CMS cité ci-dessus permette d'ajouter une pièce jointe, en tout cas MODx c'est certain ! Mais c'est vrai aussi avec Textpattern par exemple. Ce n'est pas parceque ce n'est pas intégré à l'origine que ça n'existe pas La plupart des CMS permettent a minima d'insérer un fichier via l'éditeur WYSIWYG directement dans le contenu ou alors via un gestionnaire de fichier/media. Ajouter un champ pour insérer une pièce jointe, façon SPIP (donc méthode différente que l'insertion dans le contenu) dans MODx est enfantin : 1) Créer une variable de modèle de type "File" 2) Associer la variable au template pour lequel on souhaite ajouter ce champ. Lorsque tu éditera un document, tu veras alors, en plus du champ de contenu par défaut, un champ pour uploader ton fichier. 3) Insérer une balise dans ton template pour ton lien de téléchargement : <a href="[*ma_variable_attachement*]">Télécharger la pièce jointe</a> Ceci il y a au moins 4 ou 5 méthode parceque MODx a plusieurs snippets qui gèrent les téléchargement de fichier, si tu veux aller plus loin dans les fonctionnalités (type décompte des téléchargement, listing de répertoire... etc). Pour ce qui est de la taille ce n'est pas une question de CMS mais de limitations au niveau du serveur. Il y a des moyens pour modifier la valeur limite notamment via .htaccess si je ne m'abuse. Enfin pour la publication depuis le frontend, là ça dépend des CMS... MODx le propose via le snippet NewsManager.

J'ai bien vu ton MP wapy, je suis un peu booké en ce moment désolé pour le retard de réponse... Non ce n'est pas secret et effectivement le meilleur moyen d'avoir une bonne compréhension de la construction de la base c'est un outil visuel type DB Designer. Je n'ai pas sous la main de schéma pour MODx. Je poserai la question voir si les dév ont ça sous la main

Je vais contredire cette affirmation : WordPress est un outil de blog complet, avec lequel on peut certes construire autre chose que des blogs grâce aux "pages" hors du flux du blog et aux plugins. MODx est un framework et si tu n'installes pas les extension par défaut, le core est probablement plus léger que celui de WordPress (logique, vu que c'est un framework) car il est alors vraiment dépouillé de toute fonctionnalité superflue (tu n'as que le parser et les fonctions de base dispo) : autrement dit tu n'installes que ce dont tu as besoin ! Essaye de désinstaller les trackback dans WordPress par exemple (j'ai dit désinstaller, pas désactiver)... Donc non MODx est probablement un des outils dont le core est le plus léger. Habituellement, un CMS inclue par défaut et on ne peut pas changer ça, un certains nombre de fonctionnalités inclues dans le core : MODx a pris un parti différent en sortant du core quasiment toute les fonctions hors de l'admin et du parser...

Concernant la similarité avec DotClear 2, il me semble que ça ne concerne que la version 2 beta de Puntal (voir ce post sur le blog de puntal.fr) Précisons aussi que Puntal est à la base un mod de PunBB, un excellent forum open source pour ceux qui ne connaîtraient pas... Ceci dit, l'approche est intéressante, car ce petit Mod est devenu une véritable extension "communauté" pour PunBB : news, téléchargements, calendrier, pages annexes, lexique... avec effectivement une architecture légère.

Les boucles, c'est une logique à intégrer voilà tout, mais l'avantage principal de celles-ci c'est justement la possibilité de test conditionnels style if... then...else qui permet d'éviter de multiplier les templates Pour MODx ce n'est pas moi qui vais dire le contraire mais comme l'indique ma signature sur les forums "MODx est l'outil idéal pour les developpeurs et webdesigners qui cherchent un framework de gestion de contenu hautement flexible et performant, tout en étant simple d'accès pour les utilisateurs finaux. Actuellement, il vise avant tout un public averti (ayant de bonnes connaissance en XHTML, CSS voire quelques notions de PHP). MODx évoluera vers un public moins technique, et sera mieux documenté à l'avenir, mais avant cela nous devons tout d'abord finaliser son développement !" Au delà du côté promotionnel qui fait partie de mon job, cela permet d'éviter les déconvenues...

Oui pardon pour cet oubli, c'est vrai que le système de template de SPIP est lui aussi flexible...

Pour moi la liste des CMS (pas des blogs, car effectivement là on pourrait citer WordPress ou DotClear) qui ont une réelle séparation entre contenu et présentation, et donc qui libèrent les designers des éléments de style hardcodés dans le code source de l'application ou ses extensions c'est : Textpattern CMS Made Simple Drupal et of course, MODx

Puisqu'il n'y avait jamais eu vraiment de réponse sur ce sujet, si jamais quelqu'un tombe de dessus via Google ou autre, j'ai posté une explication et un début de réponse ici : http://www.webmaster-hub.com/index.php?showtopic=33488

Est-ce qu'un hébergeur comme 1&1 supporte la ré-écriture d'URL pour commencer ? Car sinon ce qu'il te faut, CMS ou pas, c'est un bon tuto sur l'écriture du .htaccess... du genre : http://web.developpez.com/tutoriel/apache/urlrewriting/ Le CMS n'a pas un .htaccess par défaut (comme beaucoup) ?

Personne n'a jamais recontré de problème similaire ? Edit : Ok j'ai fait une tentative de synthèse sur mon blog... Edit 2 : Encore des infos très instructives sur la gestion le gamma des PNG : http://hsivonen.iki.fi/png-gamma/ ou sous la gestion des couleurs sous Mac : http://blogs.smugmug.com/onethumb/2007/02/...r-mac-on-drugs/

(J'avais initialement répondu à ce vieux fil qui traitait de la même question sans apporter de réponse, mais au final cela mérite surement un nouveau fil) Pour la première fois, je travaille avec un graphiste (d'habitude, je m'occupe de ça) et j'ai des fichiers PSD avec un profil en sRGB IEC61966-2.1. Précision je travaille sur Mac donc le profil de mon écran LCD est un peu différent des PC (gamma 1.8 versus gamma 2.2 du monde PC). Si j'ouvre le PSD en chargeant le profil sRGB pas de problème. La conversion en JPEG en utilisant sauvegarder pour le web donne après contrôle un écart de couleur flagrant : couleur délavée (toutefois logique puisque je suis sur Mac avec un LCD, j'ai l'habitude). Je prendre le colorimètre numérique et par exemple si mon original a un code hexa de #FFCC00 l'image convertie me donne #F9D33A. De toute évidence lors de la conversion les informations de profil sont perdues. J'ai donc tenté une autre méthode : ne plus utiliser sauvegarder pour le web mais sauvegarder sous en sélectionnant le profil couleur pour la conversion en JPEG : là lorsque j'ouvre avec Photoshop CS 2 pas de problème mais avec toute autre application : même problème que mentionné ci-dessus :-\ Plus étonnant, si j'ouvre le fichier JPEG contenant le profil sRGB avec ImageReady (module web de PhotoShop) : le profil n'est pas chargé (ou du moins, le résultat est le même couleur délavées ) L'écart de couleur est perceptible, c'est donc problématique. D'habitude je travaille avec FireWorks 8 (png avec calques, et apparemment il travaille en sRGB par défaut) et je n'ai pas ce genre de problème à l'export web. Alors, amis graphistes pro, quid de ce problème et surtout, comment le résoudre ? J'ai lu ici et là que le profil sRGB est interprété par certains navigateurs mais pas tous... qu'en est-il ? Edit : J'ai trouvé un début d'explication qui correspond à ce que je suspectai mais qui ne règle pas mon problème pour le moment... In english : http://www.gballard.net/psd/saveforwebshift.html On trouve notamment une page qui permet de tester la prise en charge des profils ICC par le navigateur.... apparemment seul Safari, Omniweb (même moteur WebCore) et Internet Explorer pour Mac supportent les profils ICC. Le reste des navigateur interpète toute image comme appartenant à l'espace sRVB (donc une image traitée sur Mac avec un profil Adobe 1998 est complètement délavée dans un navigateur sur PC). Ca commence à s'éclaircir ! Edit 2 : Suite de mes investigations, et un article intéressant ici : http://www.arnaudfrichphoto.com/tutoriaux-...photoshop-2.htm et aussi plus généralement cet excellent récap sur ICC et aussi des explications d'une rare clarté concernant la conversion de profil : http://blog.aube-nature.com/?2006/12/21/70...rie-profils-icc Je suis sur la bonne piste je pense, récap ultérieurement une fois que j'aurai testé les résultats... Apparemment l'essentiel est : 1) Quand on travaille pour le web sur Mac, systématiquement calibrer son écran en Gamma 2.2 et spécifier sRVB comme espace couleur de travail par défaut pour éviter tout problème... pas un souci si on bosse comme moi sous FireWorks qui le fait par défaut mais quand on a un graphiste sous Photoshop PC et qu'on ouvre le fichier sous Mac : attention ! 2) Si on dispose d'un fichier non taggé (aucun profil ICC), lorsqu'on part d'un profil autre que sRVB : soit ajouter un tag de profil pour les navigateurs qui le comprenne, soit convertir l'espace couleur vers sRVB sans tagger le fichier (car cela ajoute un overhead de 4ko environ). Ouf... travailler sur Mac a de nombreux avantage, mais il faut avoir tout ça en tête !

Aussi ce qui manque dans MODx aujourd'hui c'est un véritable workflow :-\ Il faut dire que contrairement à SPIP MODx est un framework et que l'aspect éditorial est hérité d'Etomite avec ses points forts et ses limites. Pour l'instant ce n'est pas géré par le core et personne n'a développé de module qui ajoute ce genre de fonctionnalités, donc si c'est un point clé MODx ne conviendra pas. Par contre c'est vrai que l'éditeur choisi le template au moment de la rédaction Pour le redimensionnement automatique il y a maintenant le plugin DirectResize. Par contre pour Drupal je pensai que le module i18n était assez performant, mais jamais testé... il ne serait pas aussi performant qu'on ne le dit ? MODx ne gère effectivement pas encore nativement le multilinguisme, il faudra attendre le concept de Cultures (avec la classe modCulture) qui permettra de définir la langue, la localisation, les aspects monétaires et de date et tout ce qui peut être culturellement spécifique. En attendant, il faut être astucieux mais c'est gérable, cela demandera toutefois des adaptation ultérieures pour profiter du nouveau système...

Diificle de répondre avec une demande aussi imprécise... Quelle est la nature des contenus que tu as besoin de publier (articles, news, offre/demandes d'emploi... ?) et aussi quelle fonctionnalités (forum, espace privé, messagerie instantanné... ?) ?