Planète eZ Publish, Ze french corner!

Planète eZ Publish

Damien Pobel : Twig pagelayout pour les modules legacy dans eZ Publish 5

(English version available on share.ez.no)

Je suis en train de mettre à jour le Planète eZ Publish.fr à la dernière version d'eZ Publish 5. J'en profite pour passer en revue les problèmes ou les fonctionnalités manquantes que j'avais recontrés lors de la mise en place de la version avec eZ Publish 5 en décembre dernier. L'un de ces problèmes concernait les différences entre les pages générées par les modules legacy (ezinfo/about, planet/search, ...) et le reste du site. En effet, en 5.0, il n'était pas possible d'utiliser un pagelayout Twig avec un module legacy, et donc le résultat de ces modules étaient toujours injectés dans le bon vieux pagealyout.tpl. À partir des n 2013.4 et 5.1, il est maintenant possible d'utiliser un pagelayout Twig avec les modules legacy. Il s'agit d'une fonctionnalité intéressante dans l'optique d'une mise à jour progressive vers la nouvelle stack, mais certains éléments autour de cette fonctionnalités sont intéressants.

Pour commencer, la version initiale a été ajoutée par Joe Kepley via une pull request. Il mérite un grand bravo pour ça :-)

Ensuite, en travaillant sur une amélioration, j'ai ajouté la possibilité de définir ce pagelayout par siteaccess ou groupe de siteaccess. Il n'y a pas de configuration sémantique, donc pour configurer le pagelayout à utiliser avec les modules legacy, il faut écrire la configuration suivante dans ezpublish.yml :

parameters:
  ezpublish_legacy.planete.module_default_layout: PlanetBundle::pagelayout.html.twig

Dans cet exemple, planete est le nom du siteaccess et la valeur est évidemment le chemin vers le template.

Enfin, avec quelques changements, le même pagelayout peut être utilisé pour les modules legacy comme pour le reste du site. Le principal changement et potentiellement le seul à apporter concerne le block content pour qu'il tienne compte de l'éxécution d'un module legacy. Une simple condition sur la variable module_result permet de détecter le contexte :


<<span class="title">html lang="fr-FR">


<<span class="title">body>
{% block content %}
    {% if module_result %}
        {# we are in a legacy rendered module #}
        {{ module_result.content|raw }}
    {% endif %}
{% endblock %}
</<span class="title">body>
</<span class="title">html>

Rien de compliqué, non ? Il s'agit là d'un des nombreux ponts entre eZ Publish legacy et la nouvelle stack eZ Publish 5. Vous voulez en apprendre plus ? Si j'étais vous, je m'inscrirais à la prochaine eZ UnConference #2. Sans conteste, le moyen le plus rapide de tout apprendre ou presque sur eZ Publish 5!

Mise à jour à 14h30: cette fonctionnalité est documentée avec un exemple utilisant l'héritage de template Twig.

Publié par Damien Pobel le

Damien Pobel : eZ Community UnConference #2

eZ Unconference #2 banner

La seconde édition de la eZ UnConference se déroulera les 27, 28 et 29 mai 2013 à proximité de Montpellier (à Palavas pour être exact). La première édition était une vraie réussite, je suis sûr que la seconde sera encore meilleure. Déjà, contrairement à Cologne au mois d'Octobre, le soleil est (presque) garanti ;-) et la plage n'est vraiment, mais alors vraiment pas loin!

Au programme, des ateliers sur eZ Publish 5, Symfony 2, l'API REST, la backward compatibility avec eZ Publish 4 et tout autre sujet que vous apporterez sur la partie unconference!

En plus, en plaçant le logo et un lien vers le site de l'évènement, il est possible d'obtenir une réduction de 20%, ce serait dommage de s'en priver.

Et enfin, un espace expert lounge est prévu où il sera possible pendant toute la durée de la UnConference de poser toute sorte de questions techniques à l'ingéniérie eZ et surtout d'obtenir des réponses (on fera le maximum).

Alors, on se voit là bas ?

Publié par Damien Pobel le

Alexandre Sebbane : Import/export de contenu sous/vers eZPublish

Parfois, il est nécessaire d'exporter du contenu d'une instance ezpublish vers une autre pour une fusion de 2 sites et il y a autant de méthodes que de situation.
Nous avons utilisé avec Emmanuel ( https://twitter.com/edelaunay ) une solution avec les packages .
attention cette méthode a des limites que j'exposerai par la suite.

la création du package se fait en trois étapes :

    Creation symbolique du package
    Typage du package
    Creation physique du package d'export
    Import

Étape préalable


Ces trois étapes doivent être précédé d'une étape de préparation des données : dans un package, seul un nœud peut être exporté : il faut donc déplacer tous les contenus a exporter sous un seul nœud

créons pour notre exemple un nœud "export" dans l'arbre de contenu sous la racine. nous déplaçons donc tous les contenus a exporter sous ce nœud.
Export des données

passons a notre première étape : il suffit d’exécuter cette ligne de commande a la racine du site ezpublish

php ezpm.php -sSITEACCESSADMIN --login=LOGINADMIN --password=MDPADMIN create NOMDUPACKAGE "DESCRIPTION DU PACKAGE" 1.0

puis, il faut préciser que le package est un package de contenu :

php ezpm.php –sSITEACCESSADMIN --login=LOGINADMIN --password=MDPADMIN set NOMDUPACKAGE type contentobject

enfin, il suffit de lancer cette commande :

php ezpm.php -sSITEACCESSADMIN –logfiles --login=LOGINADMIN --password=MDPADMIN add NOMDUPACKAGE ezcontentobject --exclude-classes --exclude-templates --current-version "export/*"

des lors, votre package est disponible à cet emplacement : /var/storage/packages/local

Import des données


il vous suffit de déplacer le package précédemment obtenu dans l'arborescence du site cible au même endroit.

ATTENTION : il vous faudra bien vérifier les droits d’accès sur les fichiers : le plus simple est d'appliquer un ( chmod 777 ) afin d’être sur que toutes les données seront mis en place.

Pour réimporter les contenus, il suffit alors d’exécuter la commande suivante dans la racine du site cible :

php ezpm.php -sSITEACCESSADMIN --login=LOGINADMIN --password=MDPADMIN install NOMDUPACKAGE

Limite de l'exercice


cette methode exporte des contenus avec fichiers joints, avec bloc de texte xml ...

MAIS

il ne restaure pas completement les relations d'objets : si l'objet relié a été inclus avant alors la relation est restauré.

il ne restaure pas les images et autres fichiers inclut dans les blocs XML.

il ne restaure pas les sections d'origine.

par contre, il exporte les object_remote_id, il vous sera donc possible de creer un ou plusieurs scripts afin de controuner ces problemes.

par definition, un objet sera importé si la classe de contenu existe avec les memes attributs ( il peut y en avoir en plus)


Publié par Alexandre Sebbane le

Damien Pobel : Planet eZ Publish.fr mis sur orbite par eZ Publish 5!

(English version available on share.ez.no)

Comme annoncé via Twitter et Google+ il y a une semaine, le Planet eZ Publish.fr est dorénavant mis sur orbite par eZ Publish 5 (en réalité des clones github du 04/12/2012 soit quelque part entre la version 5.0 et les futures 2012.11/2012.12). Pour autant que je sache, il s'agit du premier site utilisant eZ Publish 5 ou au moins qui ne se contente pas d'utiliser le fallback sur la partie legacy (ie eZ Publish 4.x). En effet, j'ai tenté de ré-implémenter au maximum le site dans la nouvelle pile basée sur Symfony 2. L'ensemble du code source est disponible dans le dépôt git dpobel/planet-ezpublish.fr, pour les curieux les éléments dignes d'intérêt se situent dans le PlanetBundle et dans les fichiers de configuration ezpublish.yml, override.yml et parameters.yml.

Nouvelle stack vs. legacy

Au final, il reste 3 fonctionnalités basées sur la partie legacy :

  • Le formulaire de contact, les attributs collecteur d'information n'étant pas pris en charge pour le moment
  • Le moteur de recherche, là encore l'intégration de Solr est incomplete
  • Un script de nettoyage de la partie planétarium, pour ce dernier point, j'avoue que c'est par pure flemme :-)

À l'inverse, le reste du site n'utilise que les nouvelles API et le moteur de template Twig:

Bugs et difficultés diverses

Sans surprise, il y a quelques bugs dans cette nouvelle version; pour une version majeure en point 0, le contraire aurait été très étonnant, mais il y a aussi des manques plus globaux.

D'une manière générale, l'API publique est très verbeuse. J'ai publié un gist qui compare le code nécessaire pour récupérer une liste de nœuds triée par priorité dans l'ancienne et la nouvelle API. Je crois que le constat est assez clair. Pour éviter de répéter encore et encore, les mêmes bouts de code, j'ai 2 méthodes utilitaires dans une surcharge du Location service. Avec le recul, ce n'est probablement pas la meilleure manière de faire, mais en tout cas, cette petite addition m'évite de me répéter.

Les templates eZ Publish 5 sont radicalement différents des templates eZ Publish 4.x. Et c'est pas uniquement une question de langage. Le point le plus impactant est la disparition de nos bonnes vieilles fonctions fetch. Il s'agit d'une excellente chose en terme d'architecture technique mais en l'état elle complexifie un peu l'écriture de template. Il est en effet assez rare de pouvoir se contenter du contenu et de l'emplacement de ce contenu pour générer la vue d'objet. Dans ce cas, une solution est d'appeler dans une sous requête une action d'un controller custom (voir par exemple la vue full correspondant à la page d'accueil). Une autre solution consiste à utiliser l'évènement ezpublish.pre_content_view mais cet évènement est générique ce qui oblige à détecter d'une manière ou d'une autre dans quel cas l'évènement est lancé ce qui n'est pas forcément évident (voir par exemple PlanetBundle/EventListener/PreContentViewListener.php). Bref, pour moi il manque quelque chose ici qui permette de facilement injecter des paramètres dans les templates de vue.

En tant qu'ancien intégrateur, j'espère qu'on pourra remédier à ces deux points pour rendre le au jour le jour développement un peu plus facile.

Performances

Qu'en est il des performances ? Contrasté est probablement le terme le plus adapté. En effet, sur un site sans identification et peu d'évolution dans le contenu, il est relativement facile de maximiser l'utilisation du cache HTTP et de finalement atteindre les performances du reverse proxy Symfony 2. Dans ce cas eZ Publish 5 est assez nettement supérieur à eZ Publish 4.x qui servirait une page complètement cachée et optimisée (cache-block + viewcache)! Si, le reverse proxy de Symfony se révèle trop lent, il est bien sûr possible de le remplacer par un reverse proxy dédié; dans ce domaine Varnish est un candidat de choix qui apportera de bien meilleures performances encore!

En revanche, lorsque des parties de la page doivent être recalculées, les performances s'effondrent rapidement. Un chantier est en cours pour améliorer les performances des API et cela devrait durer quelques temps.

Conclusion

ÇA FONCTIONNE! À vrai dire plutôt mieux que je ne l'aurai cru il y a quelques mois! Bien sûr il reste bien des bugs à corriger et des choses à améliorer, mais clairement eZ Publish 5 est utilisables dans pas mal de cas et pour tout le reste il y a le legacy fallback :-)

Publié par Damien Pobel le