Le blog de llaumgui - Balise - AJAX

Fedora-Fr v4.1, étude de cas d'un site sous eZ Publish

llaumgui — Thu, 14 Aug 2008 15:34:00 +0200

Cela fera bientôt 3 ans que je travaille avec le CMS open-source eZ Publish édité par la société eZ Systems. J'ai débuté cette expérience dans la société Kaliop, et je la poursuis aujourd'hui, chez Logica.

Que ce soit en temps qu'expert, consultant ou développeur (« simple » ou référent), j'ai eu la chance de collaborer sur un grand nombre de projets différents utilisant cet outil. Des projets tels que des sites institutionnels (WWF, UM1), des (extra|intra)nets, des usines à sites, ou encore, dernièrement, un portail immobilier avec plus de 150.000 objets eZ (prévoyez 2 jours pour l'import sur un octo proc' ;-)).

Cependant, jusqu'à présent, mon utilisation d'eZ Publish s'était cantonnée au monde professionnel et je n'avais pas de site « personnel » (je mets entre guillemets car Fedora-Fr n'est pas un site perso, mais un site que je gère personnellement...) utilisant cette technologie. J'avais bien commencé le portage de Scénario-Paintball sous eZ, mais je suis toujours en attente d'une charte graphique (Rad' si tu me lis...).
Bref, la refonte de Fedora-Fr sous eZ arrivait à point nommé pour m'offrir un petit bac à sable pour toucher d'encore plus près l'outil, développer autour et reverser du code à la communauté.

Cette migration s'est faite en 2 temps; le premier, la bascule du Planet de Dotclear (+plugin planet) vers eZ; suivie dans un deuxième temps par le passage du site www.fedora-fr.org (le portail) sous eZ.

Le choix d'eZ

Comment s'est fait le choix d'eZ Publish ? Le premier choix qui a été fait à été celui de changer la structure d'avant qui souffrait de 2 problèmes majeurs :

Le premier venait du planet qui avait tendance à sauter des blogs voir même à arrêter l'indexation de ces derniers... Dotclear montrant ses limites, il fallait le changer.
Le deuxième problème venait de la structure même du portail de Fedora-Fr. C'était un portail 100% maison développé par mes soins, mais utilisant un grand nombre de fonctions PunBB. Je craignais que le passage à la 1.3 de PunBB (qui sera en fait la 1.3 de FluxBB) ne cause pas mal de problèmes et demande beaucoup de réécriture de code.

J'ai donc fait le choix de revoir ma copie et de ne plus faire un portail autour de PunBB mais de prendre un CMS déjà existant et de lui permettre de communiquer avec PunBB/FluxBB.

Mon bagage en eZ, ainsi que le fait qu'il correspondait parfaitement à nos besoins (notamment la fonction d'import/export de contenu via RSS), ont fait que c'est naturellement que je me suis tourné vers cette solution et que j'ai commencé le développement d'eZFluxBB.

eZFluxBB

A l'heure où j'écris ces quelques lignes (dans un Starbucks Parisien, la classe ;-)), eZFluxBB est disponible en version 1.O RC1 sur mon Trac. Il est parfaitement fonctionnel et il ne me reste qu'à faire la documentation : exportation de la doc francophone en PDF via Trac et traduction de cette dernière en anglais. Une fois que cela sera fait, eZFluxBB sera packagé et reversé à la communauté.

Bien définir le rôle de chaque outil

Lorsque j'ai commencé le développement de la nouvelle version de Fedora-Fr (v4.1) sous eZ Publish, j'ai délimité le rôle de chaque outil : FluxBB pour les forums et la gestion des membres; eZ Publish pour la partie publication.

Il n'est aucunement prévu de faire une synchronisation des membres eZ/FluxBB ni même de permettre au visiteur de Fedora-Fr de se connecter sur le CMS. Cependant, comme eZFluxBB est sous GPL, si la demande est là et si des volontaires sont motivés, pourquoi ne pas ajouter cette fonctionnalité à eZFluxBB : login handler / loginhandler ] + cronjobs côté eZ, hook côté FluxBB. Cependant, je ne pense pas l'activer sur Fedora-Fr.

Structure eZ mise en place sur Fedora-Fr

Les extensions

On est dans une architecture classique en eZ, à savoir : 1 site = 1 extension.
A cela, j'ai ajouté une extension dite socle permettant de regrouper certains design, les traductions et certains paramètres propres à tous les sites de Fedora-Fr en eZ.

Au extension typées sites, s'ajoute:

eZFluxBB : Communication FluxBB / eZ
MyUtils : Contient des fonctionnalités que je peux récupérer sur d'autres projets
ezrssfeed : Pratique pour afficher du contenu extrait de fils RSS sans avoir à le mettre en base
eZOE 5 : Pour finir, notons que j'ai fait le choix de partir sur la version 5.0 beta d'eZ Online Editor, l'éditeur de contenu d'eZ à la place du traditionnel ezdhtml (v4)

Les classes

Je ne vais pas décrire toutes les classes utilisées sur les différents sites. Je vais simplement dire que plutôt que de créer des classes spécifiques par typologie de contenu, j'ai fait le choix que toutes les pages soient de la classe page (ou website pour les pages d'accueil). Ensuite, j'inclus les différents blocs (qui eux sont des contenus spécifiques) via l'éditeur eZOE.

Je me suis même amusé à personnaliser le contentstructuremenu.ini.

Les différents sites de l'instance eZ Publish

L'une des forces d'eZ est de pouvoir créer plusieurs sites à partir d'une seule instance de l'outil. Voila ce que ça donne sur Fedora-Fr (je fais un peu de teasing sur les prochains projets....).

Concrètement, pour un professionnel, avec une bonne configuration des vhost apache, cela permet de confier tout son système d'information à eZ : site institutionnel, extranet et intranet , etc...

Planet

Comme écrit plus haut, le planet a été le premier sous-domaine à migrer sous eZ. Bien que la fonction d'importation des flux RSS d'eZ a l'air taillé sur mesure pour un planet, il souffre d'un manque de souplesse et elle m'aurait obligé à renseigner les flux RSS de chaque blog moi-même...

Comme je suis fainéant (c'est un avantage en informatique il parait), j'ai fait le choix d'étendre la classe utilisateur et de modifier le cronjobs rssimport.php en planet.php pour que ce dernier aille chercher les informations directement dans le profil des utilisateurs du groupe blogeur.

Le contenu de chaque billet est stocké dans un datatype Bloc-text, directement en HTML. Comme certaines versions de Dotclear utilisent des liens relatifs pour leurs smileys (ce qui invalide un flux, soit dit au passage) et que tous les blogs ne respectent pas les normes du W3C (je ne citerai pas de nom), cela m'a contraint à nettoyer les contenus avec quelques expressions régulières et à utiliser php-Tidy (yum install php-tidy, merci Remi).

Pour ceux qui seraient intéressés par mon, cronjob planet, il est disponible dans mon extension MyUtils téléchargeable sur mon Trac ou par svn.

WWW

Le portail est plus classique dans son développement, il s'agit en effet d'un site de présentation. Sa seule particularité est l'utilisation d'eZFluxBB pour récupérer les informations à partir de PunBB.

Choix technologiques

Cache statique

Passer un site de la recette à la production est toujours cause de stress. En effet, il est toujours difficile d'apprécier la charge que va provoquer une nouvelle application avec 3.000 à 4.000 utilisateurs quotidiens (quoi qu'il existe des logiciels pour ça). Les développeurs d'UbuntuUser.de en ont récemment fait les frais.

En terme de performance, la référence était pour moi le site précédent. Basé sur PunBB, pas complètement POO ce qu'il faut le dire lui confère des pages servies en moins de 0,05s. Malheureusement, malgré tous les caches possibles et toutes les optimisations de développement envisageables, eZ, de par sa richesse fonctionnelle, n'arrivait pas à de tels scores. J'ai donc entrepris des tests de cache statique sur le planet. Les tests m'ont convaincu et j'ai mis en œuvre cette technique également sur le portail.

Concrètement qu'est-ce que le cache statique ?

Avant de servir la page, Apache va aller vérifier si elle existe dans un répertoire de cache. Si c'est le cas, il servira une simple page HTM, sinon, il servira une page issues d'eZ Publish. Le gain de performance est conséquent puisqu'on ne sert plus des pages php mais de simples pages HTML sans aucun calcul.

## Cache static

RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$

RewriteCond /path/to/ez/static/fedora_portail/index.html -f

RewriteRule ^/$ /static/fedora_portail/index.html [L]



RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$

RewriteCond /path/to/ez/static/fedora_portail/index.html -f

RewriteRule ^$ /static/fedora_portail/index.html [L]



RewriteCond %{REQUEST_METHOD}      !^POST$

RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$

RewriteCond /path/to/ez/static/fedora_portail$1/index.html -f

RewriteRule ^(.*)$ /static/fedora_portail$1/index.html [L]

RewriteRule !\.(gif|css|jpg|png|jar|ico|js)$ /index.php

Limitation

Comme il n'y a plus d'opérations php, la page est la même pour tous. Ça ne dérange pas sur le planet, mais sur le portail, la barre d'utilisateur de PunBB est confiée à une requête AJAX (voir plus bas).

Le bug #9126 faisant que le cache d'eZ se regénérait à partir de la version déjà en cache, cela m'a contraint à mettre quelques fichiers d'eZ 4.0 à jour par rapport à la version 4.0.1.

L'utilisation du cache statique sur Fedora-Fr

Fedora-Fr ne confie pas la régénération du cache statique à eZ Publish. En effet, la page d'accueil possède des contenu indépendants d'eZ et le planet également. J'ai donc fait le choix via cronjobs de mettre à jour le planet toutes les heures et la page d'accueil toutes les 5 minutes.

# Planet

0 * * * * cd $EZPUBLISHROOT && $PHP runcronjobs.php planet -q 2>&1 /dev/null; $PHP bin/php/makestaticcache.php -s $PLANET -f 2>&1 /dev/null



# Portail

*/5 * * * * cd $EZPUBLISHROOT && $PHP bin/php/makestaticcache.php -s $WWW -f 2>&1 /dev/null

MooTools

Fedora-Fr embarque la librairie MooTools dans ça version 1.2. Son utilisation est essentiellement due à 2 points :

L'événement domready qui comme le montre la démo, est bien plus rapide que le classique onload. Cet événement permet notamment de gérer les requêtes AJAX avant le chargement total de la page ce qui fait que vous ne voyez presque pas que la page se charge en 2 temps.
L'autre raison est une volonté d'aller plus vers le web 2.0 (même si je n'aime pas ce terme) avec l'utilisation d'info-bulles plus riches en informations et bien d'autres évolutions qui seront visibles avec l'arrivée de FluxBB 1.3.

window.addEvent('domready', function(){

        

        /* Récupération du brdwelcome en AJAX */

        if ( $('brdwelcome') && $('brdwelcome').hasClass('ajax')) {

                // Requète AJAX en 1 ligne...

                $('brdwelcome').load( ezroot + 'ajax/brdwelcome.php');

        }

});

Design

La façon dont les designs sont gérés sur Fedora-Fr diffère quelque peu des sites eZ classiques. En effet, après avoir hésité avec une utilisation classique conjointe à l'emploi d'ezoescript et ezoecss, j'ai fait le choix de conserver la structure de Fedora-Fr actuelle. A savoir, utiliser un sous domaine (common) pour les javascripts, les images et les feuilles de styles.

Cela permet, par exemple, de ne télécharger qu'une fois la librairie MooTools (60Ko normalement mais 19Ko une fois compressée) pour le portail et le planet. Ça me permet aussi d'avoir toutes mes feuilles de styles et mes javascript à un seul endroit et de les compresser facilement avec YUICompressor.

Et demain

Les projets futurs en eZ ?

Passer la Faq non-officielle sous eZ.
eZFluxBB 1.1 compatible FluxBB 1.3. D'ailleurs, je travail actuellement sur la nouvelle version du forum utilisant FluxBB 1.3.

jQuery 1.2 est dans les bacs

llaumgui — Tue, 11 Sep 2007 13:53:00 +0200

C'est juste au moment où je suis en train de réfléchir aux côtés dynamiques, 2.0 & funky de Scénario-PaintBall v3; que mon framework JavaScript / AJAX préféré voit publier sa version 1.2.
Pour ceux qui ne le connaissent pas (encore), jQuery est une bibliothèque permettant de « Write less, do more » (Traduction partisane : « Faire un max de choses en n'en foutant le moins possible » ; j'adore ce slogan !) et qui surtout est compatible tous navigateurs. Dépassé (enfin presque) le temps où l'on perdait du temps à déboguer ses JS sous Internet Explorer !

Je vais donc explorer, pour SPB, les nouvelles pistes offertes par jQuery 1.2.
Comme certaines librairies peuvent être incompatibles entre elles et que je ne veux pas forcer à l'utilisation d'un framework en particulier : je ne pense pas utiliser jQuery dans ezipb-shoutbox.
Cependant, comme eZ publish le permet, dans le cadre de mon site (qui est dans une extension), je vais surcharger le JS d'ezipb-shoutbox et utiliser jQuery.

Thème llaumgui-ng, Dotclear 2 et jQuery

llaumgui — Sun, 25 Feb 2007 23:49:00 +0100

Je viens de basculer par défaut le thème "llaumgui-ng" et je devrais bientôt retirer le thème "llaumgui" de mon blog. Ce nouveau thème est plus moderne est plus sérieux que le précédent. Il est pour le moment en version bêta et devrait évoluer graphiquement (couleur, header, etc...) et techniquement, me permettant ainsi de transformer LLaumguiDotCom en petit Labo Web 2.0.

Pour agrémenter le design et améliorer l'ergonomie, j'utilise jQuery, la librairie JavaScript proposée en standard dans DotClear 2 :

La liste des tags et le formulaire

L'onglet Tags du menu du haut permet de faire dérouler la liste des tags, il en est de même pour le formulaire permettant de poster un commentaire qui par défaut est caché. Pour cela j'utilise la fonction toggle() de jQuery pour afficher et masquer un élément CSS (.tabstags) qui par défaut est masqué.

$(document).ready(function() {



        /* Gestion des tags déroulants */

        $("li.tags a").click(function() {

                $("ul.tabstags").toggle("slow");

        });

});

Les info-bulles

Simple utilisation du plugin ToolTip disponible pour jQuery et activable via la syntaxe :

$(document).ready(function() {



        /* Plugin ToolTips */

        $('a, input, img').Tooltip();

});

Quelques idées à venir si elle ne demande pas de modification du kernel de Dotclear :

Formulaire Ajax powered pour éviter de recharger la page lorsqu'on demande une prévisualisation, sous condition que ça ne facilite pas le SPAM.
Formulaire de recherche à la Google Sugeste.
Et bien plus encore ;-).

Les nouveauté d'IPB 2.1

llaumgui — Sat, 17 Sep 2005 01:28:00 +0000

Il y a quelques jours, IPS a publié la nouvelle version de son produit phare : Invision Power Board 2.1.
Cette nouvelle version a bien sûr été installée sur les 4 forums que je gère, mais la mise à jours n'a pas été si simple...

En effet, Matt, le développeur, a modifié profondément la structure des répertoires d'IPB et a renommé un grand nombre de variables principales telles que $ibforums. J'en ai donc profité pour relire, reformater et recommenter convenablement mon code plutôt que de faire de bêtes "rechercher/remplacer".

Une fois mon portail migré (IPB 2.1 + ipbSDK 1.6), je me suis livré à une petite étude des nouveautés.

L'éditeur de texte enrichi :

La 2.1 offre le choix entre un éditeur classique relooké et un éditeur enrichi en mode WYSIWYG. Même si pour le moment je teste cette fonction, qui est quelque peu bugée, selon moi, force est de constater qu'un geek tape le bbcode plus rapidement à la main qu'avec un éditeur.

L'AJAX :

L'AJAX est très en vogue actuellement et pourrait être vulgarisé comme étant du php côté serveur mais avec un dynamisme côté client.
Cependant Matt en a usé et abusé (Mon assistant par exemple). Mais je retiens 2 fonctions très pratiques : In-line Topic Editing et In-line Post Editing.

Du RSS à foison :

Comme indiqué lors de mon précédent billet, la 2.1 apporte la gestion du RSS pour les forums et les calendriers. Cerise sur le gâteau, cette gestion passe par un cache.

Mais après avoir décortiqué ce cache, je me pose des questions sur son utilité. Si dans mon esprit, un cache est fait pour faire un appel fichier en lieu et place d'un requête MySQL, ici ce n'est pas le cas puisque les informations sont stockée dans la base de donné.
En stockant les flux RSS dans un fichier sur le serveur, Matt aurait pu économiser 1 connexion serveur ainsi qu'1 requête MySQL. Mais le cache n'est là que pour avoir une requête simple à la place d'un requête musclée faisant appel à plusieurs LEFT JOIN.

Les questionnaires :

Matt a remplacé les simple sondages par des questionnaires avec plusieurs questions. Mais toujours 1 seule réponse par question ! Pourquoi recoder un truc et ne pas tenir compte des demandes ?

L'anti-bump (Merge member's concurrent posts) :

Petite fonction sympa qui fusionne les messages si on se répond à soit même.

Les calendriers

Et oui, je dis les car la version 2.1 permet la gestion de plusieurs calendriers et leur modération. Cependant, on ne peut afficher qu'un calendrier à la fois, il n'y a malheureusement pas de vue permettant d'afficher tous les calendriers.

Une autre faiblesse est la modération qui consiste à masquer l'évènement et à ne le faire apparaître que pour les modérateurs et d'une autre couleur. Encore faut-il que les modérateurs remarquent ces évènemlents en attente. En effet, aucun message privé ni email pour les prévenir.

Pour ceux qui veulent plus d'informations sur les nouveautés qu'apporte IPB 2.1, vous pouvez consulter le changelog complet.