Réflexions sur MODx Revo et les TVs

Bonsoir à tous,

Utilisatrice de MODx depuis la première heure (2006 je crois), je n'ai jamais cessé de continuer à développer des sites avec ce CMS pour mes clients, ou pour moi.

J'ai notamment développé en 2007 le site www.deco-in.com et je suis en train de le passer sous Revolution (le chemin est long et semé d'embuches )

Je visite le forum assez peu, sauf pour trouver des solutions à quelques problèmes ponctuels, aussi, j'ai perdu de vue certains d'entre vous.. à part JC que je suis sur Twitter et Coroico avec qui je travaille de temps en temps

Si je suis là, c'est que j'ai cherché toute la journée à me convaincre que, oui je dois refondre Déco'in sous Revo et non, les problèmes de lenteur (manager ou front end) ne doivent pas être une raison de rester sous Evo.

Mais... le manager est diablement long. J'en suis à seulement 250 documents créés avec plein de dossiers et de sous-dossiers... et c'est frustrant de perdre autant de temps. J'ai essayé Opera, Safari, même combat (en plus sous Safari, j'ai clairement un problème de cache navigateur qui m'empêche de bosser convenablement mais bref... quant à Chrome, c'est politique, Google me sort pas toutes les pores de la peau donc pas moyen... mais je doute que ce soit mieux !)

A côté de ça, côte front, le calcul de mes quelques 15 appels sur chaque page de getResources couplés à 15 Wayfinder (gros menu déroulant qui affiche 3 documents pour chaque rubrique du style : http://www.cotemaison.fr/) font rougir Firebug qui m'affiche des temps d'attente jusqu'à 2,5s
J'ai installé getPage pour tirer profit du cache (getCache n'a pas été concluant) mais j'ai l'impression que son fonctionnement est aléatoire et je n'arrive pas à descendre sous la barre des 0,8s (sauf quand je refresh de suite ma page). Vous me direz que c'est quand même mieux que les 2,5s !

Oui mais voilà... Evo est beaucoup, beaucoup plus rapide ! Je le vois sur le site actuel de www.deco-in.com, les pages s'affichent quasi instantanément (sans compter que sur le site actuel, c'est 3000 documents, sur Revo (qui est installé sur le même serveur), c'est seulement 250 docs et c'est déjà vraiment plus lent !

Je me suis dit que j'allais développer mes propres snippets pour remplacer getResources et Wayfinder pour le menu déroulant, mais en lisant les forums, j'ai vu qu'un gars avait fait le test et ça n'avait pas changé grand chose.

Du coup, je cherche, je cherche et je tombe sur cette discussion : https://forums.modx.com/thread/69765/une-bonne-nouvelle#dis-post-396230 où il est question de Custom Resource classes.
Dans cette même discussion, JC dit que les TV ne sont pas là pour étendre les modèles de documents (chose que je fais pourtant pour tous mes sites)

Du coup, je m'intéresse à ces Custom Resource classes mais je ne comprends pas bien. Dans quelle mesure on utilise ces Custom Resource classes ? J'utilise les TVs sur Déco'In pour par exemple définir, l'image d'un produit, son prix, son style, sa couleur, etc... Est-ce que les Custom Resource classes peuvent me permettre de définir un nouveau modèle de document, du genre modProduit pour gérer les objets de mon catalogue et modAnnonceur pour gérer les fiches dans l'annuaire ? Pensez-vous que cela soit bénéfique en terme de traitement ?

Quelqu'un ici a un gros site ? 2000+ pages qui tournent sous Revo et qui a (ou n'a pas) ces problèmes de lenteur ?

Il me reste vraiment pas grand chose pour mettre en ligne le nouveau Déco'In (si ce n'est la rédaction) mais côté dév tout est quasiment fait. Ces problèmes de lenteur sur le front n'étaient pas aussi importants au début et j'ai l'impression que plus j'ajoute des documents, plus ça part en sucette !

Merci de m'avoir lue

Si vous avez 5 min, votre retour m'intéresse

Bonjour Perrine,

Sur le papier, les CRC permettent bien de définir ton propre modèle. Un exemple est Articles (bien qu'en soit il n'y ai aucun ajout de table/colonnes, cf schema)

Niveau traitement, je suppose que (n'ayant pas "joué" avec je ne peux que supposer)...
vu qu'elles se reposent sur les modResource actuelles, je dirais qu'elles souffriront des mêmes "inconvénients". En revanche, au lieu d'utiliser des TVs (liées à des templates eux même liés à des ressources), il est possible d'utiliser des tables tierces (et de diminuer les jointures ?). Pas certain que le gain de performance soit bien réel (supposition toujours).

Pour moi le défaut des ressources c'est le caching. A chaque ajout/édition de document le cache du contexte est recalculé. Donc dès qu'une installation a beaucoup de contenu stocké dans des ressources, ça peut vite devenir fastidieux.

Lorsque sur un projet j'ai beaucoup de contenu et qu'il n'est pas voué à être souvent modifié, je créé mes propres tables, des CMPs et un système de cache personnalisé. Pour info, sur une installation de test (portail de petites annonces) j'ai un peu moins de 15 000 "documents" (seulement 60 ressources) et Revo s'en sort plutôt pas trop mal (enfin prêt de 700ms tout de même, 400 sur la production avec 1 000 "documents", alors que sur deco-in on dépasse rarement les 300ms).

Après, Evo or Revo, that is the question... la véritable question serait plutôt quel est l'objectif de cette migration ?

Encore une fois, pour ma part c'est Revo all the way, mais j'y ai mes habitudes de développement (je n'ai jamais dev pour Evo) et je suis friant d'ExtJS. J'ai donc point de vue plutôt biaisé.

En espérant apporter un peu d'eau au moulin ;-)

Salut Romain

Merci pour ton retour

Le choix de passer sous Revo est issu d'une réflexion basique : Revo est plus récent, Evo est voué à disparaître... Je passe sous Revo.
Au fil du temps, je me suis habituée à la nouvelle interface du manager (l'installation / mise à jour de snippets y est relativement facile), l'arbre des documents / éléments / fichiers est très pratique... de manière générale, la nouvelle interface est plus ergonomique (temps de chargement mis à part bien sûr !)
Et puis, j'ai de suite retrouvé mes marques avec Wayfinder, getResources, FormIt, etc... et désormais, je fais tous mes nouveaux sites sous Revo.

Du coup, quand j'ai décidé de refondre Déco'in (initialement une refonte graphique seulement et quelques ajouts de fonctionnalités), je me suis dit que j'allais en profiter pour le migrer sous Revo. J'avais déjà lu à propos des problèmes de lenteur, mais je ne pensais pas que c'était à ce point... et surtout, comme je ne les avais pas rencontrés sur mes petits sites clients, je ne me suis pas méfiée.

Du coup, ta question Evo ou Revo revient à l'ordre du jour... et m'apparaît comme pertinente. A première vue, ça m'embêterai de repasser sous Evo pour tous les avantages trouvés à Revo et listés ci-dessus... mais si c'est le prix à payer pour avoir du rapide.

Néanmoins, je continue à me demander pourquoi ce choix a été fait par l'équipe de MODx. Pourquoi ne pas prendre plus en compte les temps de calcul ? Je sais qu'il y a forcément des trucs que je ne maitrise pas (le dév c'est pas trop mon truc, je suis intégratrice à la base :p) mais vu les temps de réponse d'Evo, pourquoi n'arrive-t-on pas à faire aussi bien ?

Salut à vous deux.

Je vous rejoins à ce sujet, puisqu'il est très intéressant
Je travaille également beaucoup sur un site avec plus de 4000 ressources, je ne les comptes d'ailleurs plus tellement il y en a et c'est vrai que j'ai du beaucoup travaillé sur ce site pour en améliorer le temps de chargement.
Côté frontend, il y a pas mal de chose à faire pour que ce temps de chargement s'améliore. Notamment avec le getResources. Lorsqu'on inclut les TVs avec un includeTVs, il faut absolument mettre un paramètre includeTVList avec dedans les TVs que tu utilises pour ce getResources sinon on atteint des temps de chargement halucinant. Après pour le menu avec Wayfinder, j'ai totalement abandonné. Je suis parti sur un script via les plugins modx qui m''insére mon menu dans la base à chaque fois que je sauvegarde une ressource. Le temps de chargement a carrément été amélioré.

Après concernant le back end, à certains moments tout va bien se passer mais alors des fois je pête les plombs devant sa lenteur. Et pourtant j'ai un serveur plutôt puissant

Après tu dis que vu la rapidité de evo ils pourraient améliorer Revo. Oui et non, quand tu regardes Revo, il y a beaucoup plus de fonctionnalités, donc il est plus difficile de garder cette rapidité.

Perso je reste sans hésité sur Revo pour toutes ces fonctionnalités. Par contre pour les gros sites, je suis parfois obligé de dévier sur autre chose que les extensions de MODx. Un peu de dev ça fait pas de mal

(Aaaaaaarg mauvaise manip' je viens de supprimer mes 2 posts lol le "remove post" demande pas de confirmation et tout est parti à la poubelle... Snif)

Bon, je reprends en résumé !

Merci Manuel pour ton retour. Peut-on voir le site en question ? J'utilise déjà le &includeTVList mais j'imagine que c'est la multiplication de mes appels qui génèrent du lag et l'utilisation aussi du &sort RAND. Je dois pouvoir améliorer mais finalement, je doute arriver aux mêmes performances que Evo.

J'ai continué mes lectures entre temps et OpenGeek déconseille clairement d'utiliser les ressources pour sauvegarder les données (s'il y en a beaucoup en tout cas) : https://forums.modx.com/thread/30393/site-slowdown-after-clearing-cache?page=2#dis-post-164735
Il parle de tables custom, je pense que c'est ce à quoi Romain faisait allusion dans son post de ce matin ?
Le souci, c'est qu'en tant que non dév, utiliser ces tables custom me prive de mon autonomie qui m'était si chère sur MODx. Je vais devoir faire intervenir un dév pour développer mes tables en amont, puis faire les snippets pour traiter ces données. Et si dans 2 mois, je veux développer autre chose, je suis encore dépendante. Donc en tant que non dév, ce système de table ne me convient pas.

En revanche, sous Evo, même si ce système de table peut être mis en place (je crois), il n'est pas forcément nécessaire. Déco'In me le prouve avec ses 3.000 documents et ses temps d'affichage de 300ms (contre 2,5s pour 250 docs sous Revo !)

Finalement, toujours au fil de mes lectures, j'ai noté que l'argument principal en faveur de Revo est son API. Mais, en tant que non dév, je n'en n'ai pas l'utilité...
Un autre avantage de Revo est son manager (cf. ici une liste qui résume aussi ce que je pense : https://forums.modx.com/thread/1715/evo-or-revo?page=9#dis-post-12237)
Et pour ça, je pense que Revo marque énormément de points !!!

Le seul bémol, c'est sa lenteur.. et pourtant, afficher une page rapidement me semble être un argument critique : si l'utilisateur ne reste pas, on se moque bien du design, du contenu, etc..
Autre chose : une page lente ne plait pas à Google et en tant que référenceuse, je ne peux pas me permettre de déconner avec ça
Sur un des posts de Jay (mais je ne retrouve plus l'url), il prend pour exemple modx.com... je suis allée faire un tour sur quelques pages du site officiel et on est en moyenne entre 0,5s et 1,5s, je trouve pas ça exceptionnel !


Bref en somme, si je devais résumer mes lectures et ma déconvenue avec cette lenteur de Revo, je dirai qu'il faut choisir entre Evo et Revo en fonction du projet de site et du profil de la personne qui va faire le site.

Depuis 6 mois, je crée des sites vitrines de quelques pages, un menu de navigation, un FormIt et ça fonctionne très bien sous Revo. Les snippets existent, je n'ai pas de dév à faire. De plus, le manager reste rapide, les nouvelles fonctionnalités sont un vrai plus dans la mise en place du site.

En revanche, mon test sur la refonte de Déco'In et les affirmations d'OpenGeek me poussent à croire que Revo n'est pas fait pour des gros sites (à moins de passer par du dev et les tables custom).

J'ai mis dans ma todo list la lecture de ce long pooooooost : https://forums.modx.com/thread/74766/bringing-evo-back-to-life-again dans lequel il est question de donner une seconde vie à Evo. J'en ferai un petit résumé pour les intéressés

J'espère ne pas avoir été trop extrémiste dans mes conclusions
Un développeur PHP aura peut-être une vision différente... A la base, si j'ai choisi MODx, c'est pour l'autonomie qu'il me proposait (full templating, Tvs). Aujourd'hui, Revo impose un fonctionnement différent et je ne suis pas en mesure de m'y adapter !

J'ai poussé mes tests un peu plus loin pour être sûre de ne pas affirmer de bêtises :p

J'ai reproduit les 18 appels getResources et les 18 appels Wayfinder sur une page de Déco'in qui tourne sous Evo. J'ai donc utilisé Ditto sous Evo. J'ai laissé les paramètres de getResources en l'état (un peu fainéante sur les bords je suis :p) donc les appels ne sont pas optimisés car la gestion de &includeTVs n'est pas géré par Ditto. L'appel se fait caché ( [[ ). J'ai aussi beaucoup plus de ressources sous Evo.

La page est générée en moins de 500ms et une fois en cache, elle se charge en 300ms (le temps indiqué est la première ligne dans Firebug, Réseau)

J'ai relancé sous Déco'In Revo, (sans l'utilisation de getPage mais et avec un minimum d'optimisation : &includeTVs et &includeTVList, &depth, pas de &sort) et j'arrive à un temps d'affichage de 3s (1,5s quand la page est en cache)

Par contre, une fois que je supprime ces 18 appels sous Revo, on tombe à des temps plus raisonnables : moins d'1 sec et quand en cache, je frise même les 500ms ! Youhou !!

Bon définitivement, Evo est quand même vachement mieux en terme de performance.
Reste que Revo... ben c'est quand même chouette en terme d'ergonomie

Je pense que 1,5s reste raisonnable pour un site internet non ?

Oui, je veux pas non plus être extrémiste Je souhaitais faire un comparatif entre Evo et Revo pour voir quelle version allait mieux me correspondre.
Quand je vois les temps de chargement d'Evo, je me dis que son choix s'impose pour un gros site.

J'ai finalement lu la longue discussion initiée il y a 5 mois par Stéfanie : https://forums.modx.com/thread/74766/bringing-evo-back-to-life-again
Le but était de continuer à maintenir Evo, corriger certaines choses, en améliorer d'autres car certaines personnes ne souhaitaient pas travailler sous Revo.

Au final, il en ressort un fork de Evo : clipperCMS (https://forums.modx.com/thread/77900/clippercms---announcement#dis-post-429743 et https://github.com/ClipperCMS/ClipperCMS) qui est une nouvelle branche de la version 1.0.6 de MODx Evo

ClipperCMS incorpore, entre autres, des améliorations qui avaient été développées par la communauté chinoise sur la gestion du cache, et par la communauté russe sur le manager
A cela, s'ajoute une refonte du manager avec l'utilisation de jQuery (bien que je ne suis pas sure que cette évolution est déjà été faite mais c'est une volonté de la nouvelle équipe)
Susan a pas mal bossé sur la réécriture des fichiers action pour le manager (ils mixaient apparemment HTML et PHP et alourdissaient le traitement)
Stépfanie a travaillé avec ezSQL pour la base de données
microcipcip sur la refonte graphique du manager : https://forums.modx.com/thread/75556/modx-evolution-manager-restyle-project

Il est question également à l'avenir d'intégrer l'éditeur de texte : http://elrte.org/ et son interface de gestion de fichiers : http://elfinder.org/

Il y a eu un long débat avec la team MODx pour savoir si on partait avec un fork ou si on gardait l’appellation MODx... La Team MODx voulait une personne qui s'occupe de vérifier tous les nouveaux changements apportés, un garde fou en quelque sorte mais cette proposition n'a pas été bien accueillie par l'équipe de ClipperCMS d'où l'évolution vers un fork (si j'ai bien tout compris car parfois l'anglais me posait quelques soucis). Je crois que c'est l'annonce de MODx 3 en 2013 qui a fini de décider l'équipe de ClipperCMS : ils ont capté qu'à terme, ni Evo, ni Revo ne seraient plus maintenus. ClipperCMS se veut donc être un Evo like, en mieux.

A ce jour, les discussion sur le forum au sujet de ClipperCMS sont arrêtés (depuis 1 mois et demi environ). En revanche, on voit que sur le Github, les choses avancent. Je pense qu'on peut récupérer la branche 1.1 pour tester.

Hello,

J'ai eu moi aussi des gros soucis de lenteur avec Revo.
Dès que j'avais des appels getresources un peu lourds (includeTvs etc...) le temps de chargement s'envolait. J'ai failli laisser tomber Revo pour cela.

Au final il s'est avéré que cette lenteur venait davantage de la configuration du serveur que de Modx en lui-même, même si Revo est incontestablement un peu plus lent que son prédécesseur.

Un temps de chargement de 2,5s, ce n'est pas normal du tout à mon avis (bien que je n'ai pas de site avec autant de documents pour comparer).
As-tu essayé de faire un top sur ton serveur pour regarder si la charge CPU ne s'envole pas au moment ou tu refresh la page?
Si c'est le cas c'est un souci niveau config serveur.