- Publié le 26 Mars 2009 à 00:13
eZ Systems organise le 9 avril à partir de 15h une rencontre communautaire à Paris autour de son CMS eZ Publish. Il ne s'agit pas d'un nouveau developper day mais bien d'un évènement qui se veut plus communautaire et 100% francophone !
Avis aux développeurs débutants ou expérimentés, intéressés par le CMS eZ Publish (qui je le rappelle est écrit en PHP, est libre et est publié sous licence GPL), voila une excellente occasion de se rencontrer et d'échanger sur divers sujets :-) Toutes les informations pratiques sont dans la news sur ez.no. On se voit le 9 avril ? :-)
- Publié le 21 Mars 2009 à 15:22
Est ce que les problémes de performance ont bien été corrigé ? voila le sujet d'un commentaire de abhunguru sur un des billets consacrés au Planet eZ Publish.fr ; commentaire qui fait référence à deux billets de Pierre Jean Duvivier à propos de l'expérience eZ Publish chez Edipresse et du passage à Drupal pour résoudre plusieurs problèmes. Il y'a d'autres billets du même auteur sur le sujet dont un ou j'avais laissé un commentaire. Les questions de performances des applications web est un vaste sujet, je vais essayer de pas faire trop long.
Première chose, les informations fournies dans ces billets sont assez confuses voire inexactes (voir le paragraphe intitulé eZpublish ré-invente la compilation en PHP par exemple), je pense qu'il s'agit de la vision non technique de problèmes techniques, en fait ce qui ressort avant tout, c'est la frustration de l'auteur. Ensuite, la comparaison brute des chiffres Drupal / eZ Publish est complètement biaisée. Comparer des installations eZ Publish 3.8 utilisant PHP4 avec des installations de Drupal utilisant probablement PHP5, ce n'est pas très sérieux ! eZ Publish 4.0 (avec PHP5) est 2 fois plus rapide qu'eZ Publish 3.10, alors par rapport à eZ Publish 3.8... Je connais mal Drupal, donc je ne parlerai donc que d'eZ Publish.
Bref, en essayant de démêler tout ça, l'auteur dénonce finalement deux problèmes :
- Une architecture technique complexe en raison des mauvaises performances supposées du CMS
- Des difficultés de développement et d'évolution du/des sites.
Architecture, performances...
Avec une estimation à la louche, 500 000 pages vues par jour correspond à moins de 30 pages / secondes en pointe, un nombre certes respectable mais qui ne donne jamais que 8 pages / secondes sur chacun des 4 frontaux qui étaient d'après les articles des bi-Xeon quadcore ! Par expérience, la plupart du temps la cause de ce genre de problèmes est souvent une ou des énormités de configuration au niveau système ou au niveau applicatif. D'ailleurs dans ce cas, je me pose la question de la pertinence d'héberger plusieurs sites sur la même grosse plateforme plutôt que de séparer chaque site sur sa propre plateforme plus légère ?
Mais tout n'est pas 100% blanc ou 100% noir ; la version 3.8 d'eZ Publish était la première à implémenter le mode cluster tel qu'on le connait actuellement (tout ce qui est relatif aux contenus est dans une base de données) et il est clair que ce mode souffrait de défauts de jeunesse importants. Ce mode a été grandement amélioré au fil des versions, en version 3.10 et 4.0, il me semble que ça fonctionne bien et la version 4.1 apporte encore des améliorations importantes avec notamment le Stale cache, Charles-Christian Croix en parle également. Il y a aussi un excellent fil de discussion sur le mode cluster d'eZ Publish et comme suggéré par Bertrand dans ce fil, un article référence sur les architectures de ce type serait le bienvenu ! Donc pour revenir à la question initiale, au niveau des performances, il est clair que la version actuelle d'eZ Publish fonctionne mieux (le contraire serait malheureux).
Le développement
Le second point soulevé par l'auteur est la difficulté de développement et de maintenance (et la maintenance je connais !). Là encore tout n'est pas blanc ou noir. eZ Publish est un outil assez complexe, c'est un fait mais ce n'est pas insurmontable ! Il semble qu'il y ait eu un mélange entre mauvaises pratiques et réels problèmes techniques. Exemple, le fait de mettre des identifiants dans les fichiers de configuration est une pratique à utiliser avec parcimonie. La sur-utilisation de ce genre de mécanisme est clairement une très mauvaise pratique et souvent révélatrice d'une mauvaise conception des contenus. En revanche, le problème de mise à jour d'une classe avec beaucoup d'instances est clairement un vrai problème, ce point a été amélioré mais il existe encore mais il est néanmoins contournable. Et puis les problèmes de performances exposés juste au dessus ne sont probablement pas étranger à d'autres mauvaises pratiques ou d'autres manques dans le développement ou la conception.
Et pour finir quand je lis que d'excellents développeurs PHP ont du mal à utiliser le langage de template d'eZ Publish, on frise le ridicule.
Conclusion ?
Il y a probablement une partie de réels problèmes dans les points remontés dans les articles de Pierre Jean Duvivier (eZ Publish n'est pas parfait) mais il est toujours plus facile de démonter une solution dans son ensemble que de se remettre en cause... Le fait est qu'eZ Publish est utilisé sur une large palette de sites à plus ou moins fort trafic et les chiffres indiqués ne sont pas non plus exceptionnels !
Et pour revenir au commentaire initial, oui les problèmes imputables à eZ Publish sont réglés petit à petit mais il ne faut pas oublier que la qualité de la mise en oeuvre de l'outil est largement aussi importante que l'outil lui-même !
- Publié le 27 Janvier 2009 à 13:55
Cette série de 3 billets présente les principaux points de la conception et de la réalisation du Planet eZ Publish.fr avec eZ Publish.Il s'agit d'un site simple à tous les niveaux, mais il concentre tout de même quelques astuces que j'espère intéressantes !
I. Organisation et Import des articles
II. Modules/vues sur mesure et templates
III. Performances : caches et compagnie
Organisation
Classes de contenu
Pour tout site réalisé avec le CMS eZ Publish, la détermination de l'arborescence ainsi que la définition des classes de contenus est l'étape préliminaire nécessaire. Dans le cas du Planet, le cahier des charges est assez simple, il s'agit d'importer des billets (classe Post) de divers blogs (classe Site) francophones consacrés à eZ Publish. Je souhaitais aussi pouvoir gérer une liste de Planets, le Planétarium, (classe Site également) avec pourquoi pas l'affichage des derniers billets de chaque Planet.
J'ai aussi créé une classe Planete qui sert de page d'accueil au Planet actuel. Le but de la création de cette classe est multiple :
- elle permet d'avoir un affichage spécifique sans faire une surcharge sur le node id de la page d'accueil qui peut changer aux grès des évolutions du site
- si un jour je souhaite que la même instance eZ Publish héberge d'autres Planets, le travail sera restreint à la duplication de l'arborescence
- La définition d'une classe spécifique permet également de faciliter l'écriture des règles de vidage de cache dans le fichier viewcache.ini.
À cela, il faut ajouter les inévitables pages À propos (classe Page) et formulaire de contact (classe Formulaire de contact) ainsi que la classe Folder existante pour des questions d'organisation du contenu et de gestion de cache.
Arborescence
À partir de cette liste de classes, l'arborescence est assez « évidente ». Le découpage se fait naturellement et en plus il permet de gérer facilement les caches template (cache-block) en évitant que tous les blocks n'expirent avec la racine. Elle est aussi prévue pour faciliter la construction du menu horizontal.
Import des articles et nettoyage
Contrairement à un site classique, le contenu sur un Planet provient d'autres sites via leur flux RSS. Ma première idée était d'utiliser le mécanisme d'import RSS d'eZ Publish. J'avais commencé par écrire un Content Edit Handler qui, pour chaque objet Site, créait un import RSS utilisé ensuite par le script de cronjob rssimport.php. Mais la fonctionnalité d'import RSS souffre de plusieurs limitations / bugs gênants :
Le script rssimport.php me semble par ailleurs assez mal écrit, du coup, j'ai choisi d'en écrire un autre quasiment from scratch basé sur le composant Feed des eZ Components et le mapping entre champs du flux et champs des objets Post est fait dans un simple fichier de configuration.
Parallèlement au script d'import RSS, j'ai aussi écrit un script de nettoyage des articles issus des Planets puisque seuls les 5 derniers de chaque source sont liés sur la page Planétarium, autant ne pas encombrer la base pour rien.
- Publié le 26 Août 2008 à 23:34
Clochix a publié cette semaine deux articles à propos de sécurité; le premier sur les CMS en général et le second plus spécifiquement sur eZ Publish. Le problème pointé est l'affichage par défaut de tous les objets dans eZ Publish par les templates par défaut même lorsque cela ne devrait pas arriver. La solution (simple) proposée est de faire des surcharges s'appliquant en dernier et n'affichant rien pour éviter d'afficher tout ce qui n'a pas été prévu. Évidemment il est toujours mieux de restreindre les droits, mais c'est un bon dernier rempart à la divulgation d'informations...
Il y a évidemment d'autres éléments à considérer et j'en oublie probablement d'ailleurs mais voici ceux qui me viennent à l'esprit.
Au niveau template, il faut toujours penser à utiliser l'opérateur wash(), il permet de s'assurer que tous les caractères spéciaux sont échappés pour produire du code XHTML valide mais aussi pour éviter des attaques de type XSS si surtout votre site propose aux internautes de contribuer.
Au niveau système pour un site en production, seul le répertoire var devrait permettre l'écriture au serveur web. On peut aussi restreindre les droits de l'utilisateur MySQL utilisé par eZ Publish pour limiter la portée d'une éventuelle mauvaise utilisation de ce compte.
On peut aussi penser à désactiver les modules et/ou les vues inutiles pour un siteaccess donné. Par exemple, pour ce site, le fichier site.ini.append.php de mon siteaccess correspondant au front comporte la configuration suivante :
[SiteAccessRules]
Rules[]
Rules[]=access;enable
Rules[]=moduleall
Rules[]=access;disable
Rules[]=module;user/register
Rules[]=module;user/forgotpassword
Rules[]=module;user/activate
Rules[]=module;user/success
Rules[]=module;ezinfo
Ces quelques lignes désactivent quelques vues du module user ainsi que le module ezinfo qui sont accessibles aux utilisateurs anonymes alors qu'ils ne me sont pas nécessaires. La vue ezinfo/about en particulier donne des informations sur les extensions activées et surtout sur la version d'eZ Publish ce qui permet de savoir à quoi est potentiellement vulnérable le site. Dans tous les cas, il vaut mieux être à jour, les versions 4.0.0, 3.10.0 et 3.9.4 sont vulnérables à quelques failles connues.
Il faut aussi penser à nommer les fichiers de configuration en .ini.append.php et à encadrer le contenu par des commentaires PHP ce qui évite toute possibilité de lecture via un accès direct par le serveur web. À ce niveau, avoir un site eZ Publish en mode Virtual Host devrait aussi apporter un gain en cachant presque complètement l'arborescence "physique" du site.
Enfin au niveau des extensions il faut évidemment penser à échapper toutes les données inconnues avant de l'utiliser dans une requête SQL (ça n'est pas spécifique à eZ Publish !), la méthode escapeString() de la classe eZDBInterface est faite pour ça.
