MODx

[lossendae]

Je consulte assez regulierement le hub, j'ai pu y obtenir un peu d'aide à l'occasion, et aussi retrouver des membres actifs de mon CMS de prédilection: MODx.

Ces derniers mois toutefois j'ai un peu l'impression qu'ils ne sont plus autant attiré par MODx, mais plutot vers Drupal! Je pense notamment à Davidm, Nyl et Aour dont les contributions et l'activisme se sont considérablement raréfié sur les forums officiel notamment (qu'en est il du site modxcms.fr?) mais aussi sur l'énorme travail de traduction et de renseignement des membres francophones (la section française officielle du forum de MODx n'est pas la plus réactive... ce n'était pas le cas il y a de cela 1 an)

Serait ce dû à la derniere version de Drupal (taille, qualité du code, nombre de modules) ?

Au manque d'add-ons de MODx?

A la communauté active mais en plus petit nombre?

A l'attente de MODx Revolution?

En gros quel sont les raisons de votre inflexion sur ce CMS?

[davidm]

Chacun pour des raisons diverses, a eu besoin de recourir à d'autres solutions que modx. Rappelons que Nyl, Aour et moi même sommes des professionnels et que par conséquent les besoins que nous sommes amenés à couvrir sont variés et ne correspondent pas toujours à un CMS unique même si jusque là modx convenait dans 90% des cas pour ce qui me concerne.

Le fait que nous ayons bougé vers d'autre solution n'exclu pas un engagement toujours fort vis à vis de modx. Aour a été le premier à se tourner d'abord vers typolight, puis vers Drupal. Nyl a du bosser sur des projets n'impliquant pas modx pour la boîte qui l'a recruté. J'ai aussi bossé avec Typolight qui est un outil complémentaire à modx.

Si j'ai pu paraître comme exclusivement intéressé et impliqué dans modx, c'est que la vaste majorité des projets sur lesquels j'ai travaillé correspondaient parfaitement (cas typique du site corporate pour lequel modx est LE cms sans doute le plus performant qui soit). Mais comme ont pu le constater les membres du Hub, je ne cesse de tester d'autres solutions et je suis le premier à dire que le choix technique doit toujours se faire en fonction des contraintes du projet / de l'adéquation aux exigences du cahier des charges. Un outil ne peut jamais remplir tout les besoins ou du moins tous les besoins dans tous les contextes ! En plus, il arrive un moment où on maîtrise un cms et on a besoin (si on veut rester au top et résister à la crise) de continuer à développer ses compétences pour étendre les types de marché qui nous sont ouverts.

Dans mon cas, je travaille sur un projet (je viens de remporter l'appel d'offre) ou Drupal est beaucoup plus adapté que modx car il y a plusieurs exigences clés que modx ne peut pas (aujourd'hui) satisfaire étant donné les contraintes temps et budgétaire :

• workflow custom
  
• gestion fine des droits utilisateurs
  
• système de notification
  
• multi-site
  
• plusieurs fonctionnalités de travail en groupe qui sont particulièrement bien satisfaite par Organic Groups
  
• encore d'autres éléments mais je ne peux pas tout mettre ici...
  

En ce qui concerne modx, nous sommes depuis quelques mois arrivé dans une période de transition où l'activité du projet (et pas seulement la mienne ou celle de contributeurs francophones) a subi un ralentissement aussi en raison de la focalisation sur Revolution et le nouveau modxcms.com par la core team.

Aussi, le fait que la structure commerciale derrière le projet prenne de plus en plus d'importance (il suffit de voir la page Team du nouveau site où l'équipe "core" n'est plus composée des contributeurs clés de la communauté mais des salariés de collabpad... à mon sens c'est d'ailleurs un erreur, j'ai eu quelques remontées de la communauté à ce sujet...), a joué un rôle.

Autre facteur, quand j'ai convaincu Jay Gilmore de rejoindre l'équipe (et que j'ai plaidé en sa faveur auprès de Ryan) mon rôle est devenu un peu différent car Jay est un pro du marketing (c'est son métier) qui travaille désormais pour collabpad. Même si je me suis toujours vu comme un évangéliste et non un marketeur, Jay a un peu pris ma place de facto d'autant plus que je n'étais pas très dispo ces derniers mois. J'ai du réduire, il n'y a que 24 heures par jour, mes contributions sur le forum où j'ai toujours été un des 3 plus gros contributeurs donc fatalement ça s'est senti.

Donc pour clarifier mon investissement modx, je vais m'y remettre, mais probablement à 75% sur modxcms.fr (mon action sera plus localisée qu'avant vers la communauté française). Enfin en ce qui concerne modxcms.fr, il faut bien comprendre qu'en dehors de Nyl ou de Jean-Christophe il n'y a pas beaucoup de contributeurs et cela pénalise l'avancée ! Il faut savoir que l'actuel modxcms.com est prêt depuis plus de 6 mois et c'est le temps qu'il aura fallu pour produire les contenus. Pour finir, le fait que je ne sois pas très chaud concernant le design qui avait été choisi par les 3/4 des personnes impliquées dans le débat n'aide pas à motiver...

Ma priorité sera donc :

1) redynamiser la communauté et recruter une équipe francophone dispo et motivée

2) mettre enfin modxcms.fr en ligne

3) probablement, basculer le support technique sur modxcms.fr car je pense qu'au final c'est une condition sine qua non de la vie du site

Je pense que dès que Revolution va entrer en beta on va voir un regain d'activité du projet dans son ensemble et un retour aux affaires de certains contributeurs clés. En attendant j'espère une clarification concernant le fait que la core team semble être collabpad seulement, et une ouverture sur la communauté (il faut savoir que les forums privés "project team" ont toujours été le lieu des grandes décisions, et impliquaient les nombreux membres de l'équipe issu de la communauté. Depuis quelques mois, l'activité est tombé proche de zéro...).

[nyl auster]

Salut

Pour ma part je considère toujours Modx comme un grand CMS, parce que j'aime beaucoup la clarté de sa logique d'ensemble. Maintenant la boite où je travaille est pas mal axé sur des sites communautaires; en général avec une boutique en ligne en prime. Modx ne me convient pas du tout pour ce genre de projet; alors que Drupal + ubercart + les modules qui vont bien fait ça comme un chef.

En revanche c'est sans hésitation que j'utiliserai Modx sur les sites de présentation d'entreprises avec un design précis. Il va me faire gagner beaucoup de temps sur le design.

Si j'ai pu autant m'investir dans modx il y a quelque mois c'est surtout parce que j'étais alors au chômage.

Maintenant il faut aussi avouer que Drupal est une arme de guerre d'une puissance assez redoutable une fois qu'on a appris à le manier, avec un champ d'action franchement impressionnant.

Modifié 4 Mars 2009 par nyl auster

[lossendae]

Merci pour ces clarifications.

Nyl, si MODx proposait le même type d'outils avancées que Drupal, tu reprendrais donc MODx, ou tu penses que Drupal est dans sa conception même mieux conditionné pour des sites communautaires ou des magasins en lignes.

Je remarque que vous insistez souvent sur le fait que MODx est plus approprié pour des sites un peu statique (plaquette, portfolio, corporate).

Le nouveau MODx pourra t'il plus rentrer en confrontation avec Drupal sur ce terrain?

De ce que je retire de vos post (pas que sur ce topic), MODx est trop compliqué pour un blog (d'autant plus que sans conteste WP et DotClear le font mieux et plus rapidement), pas assez avancé pour des sites communautaires, webstores, webzines.

En gros il ne satisfait vraiment que sur des pages plutot statiques -j'ai regardé les annonces pour Revolution, il rempli certains manques, mais arrivera probablement sans les modules qui vont bien, du moins au début -? ça me donne furieusement envie de franchir le pas et d'aller voir ce qui se fait du côté de Drupal (et ce même si l'approche des templates ne me donne pas envie)

[aour]

Salut

Disons en fait que je cherche toujours à optimiser mon choix en fonction des caractéristiques des sites à produire.

Aujourd'hui, si tu veux je m'oriente vers :

Typolight avec des créations sans programmation grâce à catalogue

Modx lorsque j'ai besoins de mettre la main dans le code

Drupal quand le client peut prendre un virtuel ou un dédié et que le projet le demande.

Thelia pour les boutiques.

Blog c'est vrai que WP est quand même fait pour. Maintenant si il s'agit juste de créer une liste de news sans la volonté d'être inscrit de partout tu peux utiliser Modx sans souci vu que tu maitrise.

Quand à ma participation, elle est en fonction de mes activités. La je croule pas sous le boulot mais sur la recherche de clients, relance, formation ...

Voila.

Aour

PS le template de drupal est pas non plus si mal. C'est pas parce qu'avec modx vous avez mangé du caviar qu'il faut pleurer sur du saumon

Modifié 4 Mars 2009 par aour

[davidm]

Comme on dit en anglais, "I beg to differ" !

Le caviar c'est modx, c'est clair, le saumon c'est typolight mais Drupal c'est plus de la truite fumée

Attention à ne pas me faire dire que que je n'ai pas dit, les sites corporate ne sont pas que des sites plaquettes "statiques" au contraire modx permet de placer de la logique / du traitement partout très facilement. On peut aussi très facilement construire des catalogues et faire de l'ecommerce simple. Ce qui manque à modx ce n'est pas le potentiel mais certains "gros" addons qui sont dispos sous Drupal.

Aussi, comme le souligne Nyl, pour les sites communautaires/collaboratifs il manque pas mal de addons à modx mais aussi un schéma de permission / de droits plus adapté. Typolight peut être d'un grand secours pour des sites moyennement complexe (il lui manque encore la richesse de module de Drupal par contre son code est bien plus moderne et son templating bien plus flexible et rapide à mettre en oeuvre), mais pour du "lourd" Drupal est sans doute la meilleure solution aujourd'hui. Je ne pense pas que je le conseillerai pour faire des sites peu ou moyennement complexes...

Enfin concernant Revolution, on entre dans un autre monde d'un vrai CMF avec un grand F avec un code moderne et un ORM maison, qui ouvre énormément de porte mais comme je me tue à le dire sur les forums (et à Ryan/Jason) la clé du succès de Revolution sera son adoption par les développeurs et les addons qui verront le jour et lui permettront d'étendre la couverture fonctionnelle de modx sur des terrains sur lesquels pour le moment il n'est pas compétitif. Je crois qu'il faudrait (je l'ai souvent répété) mettre en place un système de bounty ou de code sprint pour les gros modules qui pourraient vraiment booster modx, à l'instar de ce qui se fait aujourd'hui chez plusieurs CMS open source.

[nyl auster]

PS le template de drupal est pas non plus si mal. C'est pas parce qu'avec modx vous avez mangé du caviar qu'il faut pleurer sur du saumon

Les templates de drupal sont pas si mal en effet; on maitrise sans peine 95% de ce qui se passe en une matinée de travail. De plus Drupal respecte à fond la séparation html/php côté framework.

Les 5% qui restent sont carrément moins évidents par contre et demande d'apprendre à connaître drupal de façon plus approfondie. Mais tous les projets ne demandent pas à tel degré de personnalisation....

Modifié 4 Mars 2009 par nyl auster

[nyl auster]

il lui manque encore la richesse de module de Drupal par contre son code est bien plus moderne

Je suis pas supercalé en code php. Tu dis ça parce que drupal n'est pas orienté objet?

Je ne sais pas trop ce que vaut drupal côté code interne mais il me parait d'une rigueur assez dingue et élégante quand même. On fait beaucoup de choses en très peu de lignes de php et on sent que tout ça a été pondu avec un côté quasi-maniaque dans l'organisation. (encore une fois, l'API des formulaires est assez ahurissante de mon point de vue. J'avais moi même bricolé une sorte d'api pour générer des formulaires orientée objet; quand j'ai vu celle de drupal j'ai laissé tombé la mienne de suite).

En ce qui concerne le côté orienté objet, je n'ai pas d'avis à cause de mon manque d'expérience en php mais je tiens quand même à préciser que drupal fonctionne entièrement sur un systeme d'assemblages et d'interactions de fonctions qui me parait proche de la porgrammation objet; si ce n'est qu'elles ne sont pas regroupées en classes.

Mais je peux être dans le faux; je serai curieux d'avoir l'avis d'un expert sur ce point !

Modifié 4 Mars 2009 par nyl auster

[lossendae]

Enfin concernant Revolution, on entre dans un autre monde d'un vrai CMF avec un grand F avec un code moderne et un ORM maison, qui ouvre énormément de porte mais comme je me tue à le dire sur les forums (et à Ryan/Jason) la clé du succès de Revolution sera son adoption par les développeurs et les addons qui verront le jour et lui permettront d'étendre la couverture fonctionnelle de modx sur des terrains sur lesquels pour le moment il n'est pas compétitif. Je crois qu'il faudrait (je l'ai souvent répété) mettre en place un système de bounty ou de code sprint pour les gros modules qui pourraient vraiment booster modx, à l'instar de ce qui se fait aujourd'hui chez plusieurs CMS open source.

Les bounty ou code sprint consiste en quoi?

[nyl auster]

quand chez drupal il font un "sprint", ça veut dire qu'ils réunissent tous les contributeurs et qu'ils travaillent ensemble comme des bourrins pendant une journée ou deux journées par exemple, sur des axex définis à l'avance.

Ca a l'air d'être un bon moyen de motiver les contributeurs, et surtout de collaborer ensemble en même temps en se mettant d'accord sur une date. C'est plus facile de caser ça dans son emploi du temps du coup.

Modifié 4 Mars 2009 par nyl auster

[lossendae]

Effectivement ça m'as l'air d'être une bonne idée

[nyl auster]

je comprends tout à fait vos propos néanmoins mais je pense quand même que c'est hyper-rare que quelqu'un désactive son javascript, exception faite des professionels du web.

j'avais pu lire que cela concernait 5% des utilisateurs mais ça m'étonnerait fortement; c'est en contradiction avec ce que j'ai pu observé autour de moi.

Me trompe-je?

Modifié 4 Mars 2009 par nyl auster

[Dudu]

J'ai toujours entendu dire que 78,13% des statistiques étaient fausses

Blague à part, quand bien même ça concernerait 0,01% de la population, je n'ai pas envie de discriminer qui que ce soit en tant que webmaster.

D'autant qu'une bonne dégradation, ce n'est pas la fin du monde, c'est même hyper-simple, et ça oblige à une rigueur de codage qui est saine.

[davidm]

Quelques news par rapport à certaines orientations qui semblaient avoir été prises avec le nouveau site : votre serviteur (par mail) et quelques membres de la core team actuelle (Doze, devcw) sur le forum de l'équipe ont soulevé la façon un peu indélicate dont la plupart des contributeurs ont été zappé de la page team et il s'avère qu'au final c'est temporaire et que la liste sera étendue à "l'ancienne garde" et aux contributeurs de la communauté comme c'était précédemment le cas.

Pas de changements d'orientation donc, et c'est tant mieux...nous étions quelques uns à être un peu agacé... la page sera mise à jour pas la semaine prochaine, mais plutôt la suivante.

[nyl auster]

Nyl, si MODx proposait le même type d'outils avancées que Drupal, tu reprendrais donc MODx, ou tu penses que Drupal est dans sa conception même mieux conditionné pour des sites communautaires ou des magasins en lignes.

Je remarque que vous insistez souvent sur le fait que MODx est plus approprié pour des sites un peu statique (plaquette, portfolio, corporate).

Le nouveau MODx pourra t'il plus rentrer en confrontation avec Drupal sur ce terrain?

Salut. je me suis replongé hier dans Modx pour les besoins d'un site. Les points qui m'impressionnent toujours autant sont le systeme de template génial, sa vitesse d'éxécution par rapport à Drupal.

En revanche, concernant le framework derrière je commence à me poser des questions. J'ai voulu faire un formulaire de contact avec e-form et j'ai constaté que cela impliquait de taper TOUT le code html à la main. A mois qu'il y ait un fichier pour gérer les formulaires que je n'ai pas vu ?

Pour donner une idée, voici à quoi ressemble le code php de drupal pour générer un formulaire qui demande son nom à un internaute, avec un bouton submit. (ceci peut se faire dans l'admin avec un module mais voici à quoi ressemble le code php)

	$form['name'] = array(
		  '#type' => 'textfield',
		  '#title' => 'Votre nom',
		  '#required' => TRUE,	 
		  );

	$form['valider']=array(
		'#type' => 'submit', 
		'#value' => 'envoyer ! '
		);

Le html est généré automatiquement à partir de ce php, de plus l'api de drupal effectue seule certaines vérifications de sécurité. Je pense que le framework de Drupal est quand même relativement puissant et fait preuve de beaucoup de rigueur.

Comme les formulaires sont un truc systématique, je suis bien content de disposer d'une api très solide de ce côté me permettant d'accélérer considérablement mon temps de développement pur. (c'est à dire quand drupal ne répond plus à mes besoins et que je dois mettre les mains dans le cambouis)

Modifié 24 Mars 2009 par nyl auster

[lossendae]

Merci pour cet exemple!

Effectivement, ça m'a l'air tres puissant ce "générateur d'html" (pour la partie sécurité, parce que concrètement, c'est aussi long d'écrire le code php qui génère le code que d'écrire directement en html).

Je ne suis pas fan d'eform du coup je ne l'ai pas énormément utilisé.

Ceci le formulaire de contact m'a l'air relativement bien pensé et ce même si la logique derrière n'est pas la plus facile d'acces.

Le fait de s'appuyer sur des chunks en full html permet de laisser une grande liberté sur le code produit.

Je peux aussi me tromper donc je vais essayer de prendre des exemples.

Si pour générer ton formulaire avec Drupal, comment procede tu si tu que chaque <input> soit dans des listes (<li>), ou si tu veux rajouter une annotation à côté ou en dessous du nom de champ (<em>)? Est ce que le générateur de formulaire est assez souple pour permettre le code désiré?

J'imagine bien qu'avec les contraintes de temps qu'implique certain projet, le côté purement cosmétique n'est probablement pas la priorité, mais le but est est de savoir si cela est possible sans toucher au code php.

[nyl auster]

Salut

Comme tu le dis, Modx reste le maître pour avoir un parfaite maîtrise de la sortie html, considéré de manière globale.

En revanche :

si tu veux rajouter une annotation à côté ou en dessous du nom de champ (<em>)? Est ce que le générateur de formulaire est assez souple pour permettre le code désiré?

on met simplement ça :

$form['annotation']=array(
		'#value' => '<em> j'écris ici ce que je veux et je mets ça ou je veux dans le formulaire</em> '  //ca ne fait pas un champ de formulaire, on met juste ce qu'on veut.
		);

ou encore

$form['name'] = array(
		  '#prefix' => '<li>',   // on peut ajouter du code html avant et après avec les propriétés suffixe et préfixe, même si ça revient à mélanger html et php
		  '#suffix' => '</li>',  // donc un peu dommage, il vaut mieux passer par une fonction de theme comme ci-dessous.
		  '#type' => 'textfield',
		  '#title' => 'Votre nom',
		  '#required' => TRUE,	
		  );

A noter aussi que pour les formulaires que tu n'as pas généré toi même, tu peux utiliser une fonction permettant de themer comme on le désire n'importe quel formulaire après coup.

Ici un exemple de formulaire "classique" pour créer un node dans drupal que j'ai complètement restructuré :

(je reconnais que ça devient un peu plus obscur)

function theme_livre_node_form($form){


	$output.='<table class="fiche-livre">';
	$output.='<tr><td class="left">';
		$output.= drupal_render($form['title']); //on peut accéder à chaque champ du formulaire indépendamment. ici le champ titre
		$output.= drupal_render($form['field_sous_titre']); //le sous_titre
		$output.= drupal_render($form['field_auteur']); //le champ auteur
		$output.= drupal_render($form['field_co_auteur']); 
		$output.= drupal_render($form['taxonomy']['3']); 
		$output.= drupal_render($form['field_format']['key']);
		$output.= '<div class="submit-livre">'.drupal_render($form['submit']).'</div>';
	$output.='</td>';

	etc...  
	return $output;
}

Modifié 31 Mars 2009 par nyl auster

[lossendae]

Effectivement c'est très puissant!

L'approche est différente et certainement plus "directe" que celle d'eform dont la logique m'échappe parfois!

Il me semble d'ailleurs que Ryan à annoncé sur le forum qu'eform ne serait pas porté sur MODx Revolution. Peut être vont ils proposé une méthode plus simple...

On verra!

[nyl auster]

En fait il faudrait plutôt comparé E-form au module webform de drupal (tout se fait au clic dans l'admin, systeme hyper confortable).

L'API des formulaires dont je parle concerne plutôt n'importe quel type de formulaire du site : c'est ainsi que sont codés les formulaires de tout le site (formulaire pour créer des articles, commentaires etc..).

Le gros avantage pour moi c'est d'avoir à disposition cet API de formulaires qui peut me permettre de créer rapidement n'importe quel type de formulaire pour n'importe quel type d'action.

C'est un énorme plus quand je dois personnaliser à fond un site.

En regardant le code source de modx, je m'attendais à trouver une api de formulaire en objet ou quelque chose comme ça mais apparemment ce n'est pas le cas.

Modifié 31 Mars 2009 par nyl auster

[lossendae]

J'imagine que c'est très pratique mais je ne suis pas du tout sûr que ça concorde avec la logique de MODx de séparation entre le code php et les templates en html avec des placeholders.

Il me semble toujours plus naturel de manipuler du html pur plutôt que d'utiliser un quelconque générateur. Par exemple, quand je m'amusais à reprendre les (tres jolis) themes wordpress, ça a été tres simple de reprendre le code html, de faire mes adaptations, changer/adapter mes classe, avoir une vue concrete du html puis juste de faire l'appel via Jot.

Générer le code via php aurait été un peu moins pratique, moins direct.

Ceci dit, je ne pense pas non plus qu'eform soit la méthode idéal. Peut être qu'il faudrait un juste milieu (pour moi j'entend) entre automatisation tout en gardant l'aspect séparation de MODx! Un modele qui n'a pas encore été pensé.

[nyl auster]

et oui, de toute façon je fais bientôt un site modx dans le cadre du travail et ça va être un vrai bonheur de le retrouver. :!: