Quand on développe sous eZ Publish, l'outil indispensable indispensable du développeur est le debugger (ou debogueur en français) interne. Alors comment activer ce mode et gagner du temps en développement ?

La version communautaire du CMS eZ Publish, 2012.4 est disponible au téléchargement.

Plus d’infos :
http://share.ez.no/blogs/community-project-board/ez-publish-community-project-2012.4-available-now

Télécharger :
http://share.ez.no/downloads/downloads/ez-publish-community-project-2012.4

Tip :

Dans l’ancienne interface d’eZ Publish, les champs affichés dans le backoffice sont « codés en dur ». Dans la nouvelle interface d’administration (dont le design est admin2), les champs affichés par défaut sont gérés dans le fichier adminterface.ini (à surcharger bien sûr), dans le bloc [SubItems], variable VisibleColumns :

[SubItems]
VisibleColumns[ezcontentnavigationpart]=checkbox;crank;name;published_date;translations;priority

Un besoin récurrent dans les formulaires de saisie, tels qu’un formulaire de candidature à une offre d’emploi, ou un formulaire de participation à un concours photo, est le téléchargement (upload en fait) d’un fichier, information qui sera collectée et envoyée par mail à X destinaires.

Sur eZ Publish, lors de l’édition d’une classe où l’attribut est de datatype « fichier », ce dernier ne permet pas de cocher la case « information collectée ».  En effet, le datatype « ezbinaryfile »ne le permet pas (Sujet traité sur le forum officiel ici : http://share.ez.no/forums/general/files-and-collected-informations).

Il existe cependant une solution, qui est l’installation d’un nouveau datatype : http://projects.ez.no/enhancedezbinaryfile.

Comment désactiver un compte utilisateur sur eZ Publish ?

(English version available on share.ez.no)

eZ Publish Community Project 2012.3 est sortie aujourd'hui. L'extension ezautosave est embarquée et activée par défaut, elle ajoute un nouveau widget pour faciliter la prévisualisation de contenu depuis le formulaire d'édition. J'ai ajouté cette fonctionnalité viaune pull request faite avec mon chapeau de membre de la communauté; j'en suis plutôt fier ;-)

En plus de cela, plusieurs améliorations du formulaire d'édition dans l'interface d'administration avaient déjà été ajoutées dans les dernières versions:

• le mode plein écran a été supprimé pour être remplacé par un barre d'outil fixe en haut de l'écran pour avoir à disposition les principaux boutons;
• le menu de gauche peut être caché, son état est stocké dans une préférence pour le conserver après un rafraîchissement de page;
• dès que vous scrollez vers le bas, un lien pour retourner en haut du formulaire fait son apparition;
• l'extension ezautosave fait en sorte de sauvegarder automatiquement le brouillon en cours pendant l'édition;
• l'extension ajoute aussi le lien de prévisualisation mentionné ci-dessus dans la barre d'outil fixe

Une image vaut mille mots, qu'en est il d'une vidéo ? ;-)

(Visualisation en HD fortement conseillée)

Parfois, il peut être utile de mettre en place un espace privatif sur son site web. Cela peut être par exemple une zone du site réservée aux membres. eZ Publish dispose d'une solution native pour mettre tout cela en oeuvre.

Afin de comprendre le rôle du « cache de vue » ou des « cache blocks » (détaillé dans les prochains chapitres), il est important au préalable de bien différencier deux concepts qui sont souvent confondus :

• La compilation des templates, qui est abordé dans ce chapitre
• Le cache de template, qui désigne en fait la mise en cache des contenus des cache-block. Le mécanisme de cache-block sera détaillé dans un prochaine chapitre

“

La confusion entre ces 2 systèmes de caches provient des différentes interfaces et documentation, qui exploite l'expression "cache de template", sans préciser s'il s'agit de la compilation ou des fichiers de cache de template-block liés au cache-block

”

A quoi sert la compilation des template ?

Lorsque la directive de compilation des templates est activée, tous vos fichiers de templates péniblement rédigés (*.tpl) sont transformés ou plutôt « compilés » (désolé pour les puristes) en PHP. Ainsi lorsqu'un internaute demande l'affichage d'une page, cette page nécessite forcement l'exécution d'un certain nombre de templates (quelques dizaine la plupart du temps)

• Situation 1 : Ces templates n'existent pas dans leur version « compilée » : eZ Publish va d'abord compiler les templates impliqués (transformer la syntaxe eZTemplate des fichiers .tpl en syntaxe PHP), puis rendre disponible la version compilée (donc en PHP) pour la future construction du cache de vue ou des « cache blocks ». On pourrait résumer cette séquence en « TPL > PHP > xHTML (ou autre) »
• Situation 2 : Ces templates existent dans leur version « compilés » : lors de la construction du cache de vue, eZ Publish exécute directement le code PHP sans interpréter à nouveau les fichiers de template en syntaxe eZTemplate des fichiers .tpl. On pourrait résumer cette séquence en « PHP > xHTML (ou autre) »

Cette « situation 1 » (templates compilés à la volée) peut s'avérer dramatique sur un site à fort trafic et ne devrait jamais se produire en production. En effet, la compilation des templates nécessite une énorme consommation de ressource (RAM/CPU seulement, pas SQL) susceptible de générer toute sorte d'erreurs si le trafic concurrent est important, et si le "stalecache" n'est pas activé (concept détaillé plus loin).

Dans tous les cas de figure il est impératif :

• D'activer la compilation des templates sur un site en production
• De ne jamais supprimer massivement le cache de template
  • pas de « php bin/php/ezcache.php --clear-all –purge »
  • pas de « php bin/php/ezcache.php –clear-id=template », qui ne supprime pas le cache de template block, mais l’ensemble des versions compilés des templates
  • pas de « php bin/php/ezcache.php –clear-tag=template », qui supprime à la fois les caches compilés et les le cache de template block
• Lors d'une mise à jour, de forcer la recompilation ciblée des templates ayant été modifiés, et uniquement ceux ayant été modifié (voir plus loin comment procéder)

Note : La compilation est activée par défaut (site.ini), mais souvent désactivés lors des phases de développement, tests ou autre. Il est donc important de vérifier qu'ils sont bien activés avec une mise en production du site.

settings/override/site.ini.append.php / [templatesettings]

TemplateCompile=enabled # compile les templates dans /template/compiled/
NodeTreeCaching=enabled # pré compile les templates dans /template/tree/, par défaut si TemplateCompile est enabled
 

Il ne faut pas confondre ces 2 paramètres avec celui d'activation du cache de template :

TemplateCache=enabled # met en cache les contenus des cache-block /template-block/
 

Comment sont stockés les templates compilés ?

Pour les courageux qui sont encore attentifs et qui souhaitent en savoir plus, eZ Publish stocke les versions compilées des templates dans le répertoire :

{VarDir}/cache/template/compiled/
{VarDir} = valeur du paramètre VarDir dans le site.ini (ou votre surchage spécifique), généralement "var/monsite/"

Les noms des fichiers sont relativement explicites :
{nomdutemplate}-{hash}php
par exemple : pagelayout-49f4458d0b68aec3cf2de63a6918fd61.php

Le hash est calculé selon 2 méthodes différentes, en fonction du paramètreShareCompiledTemplates (section [TemplateSettings] du site.ini)

Extrait de lib/eztemplate/classes/eztemplatecompiler.php

if ( $shareTemplates )
 $cacheFileKey = $key . '-' . $language;
else
 $cacheFileKey = $key . '-' . $internalCharset . '-' . $language . '-' . $useFullUrlText . $accessText . "-" . $pageLayoutVariable . '-' . eZSys::indexFile();
 
$cacheFileName = $extraName . md5( $cacheFileKey ) . '.php';
 
return $cacheFileName;
 

Tableau des éléments de la clé de hash, en mode ShareCompiledTemplates=disabled

La clé de hash est donc constituée de plusieurs paramètres combinables, qu’il faut impérativement connaitre afin de bien comprendre et maîtriser l'impact d'une suppression complète des templates compilés. En effet, un site multi-langues, avec de nombreux siteaccess, et une utilisation massive du module 'layout' (layout/set/... ce qui est tout à fait déconseillé par ailleurs, mais c'est un autre sujet) peut générer un grand nombre de combinaisons possibles de caches compilés, autant de cache à reconstruire lors d'une expiration massive.

Note : Les plus attentifs auront remarqués la présence du répertoire « {VarDir}/cache/template/tree/ ». Ce répertoire contient une sorte de pré-cache ou « arbre de compilation », qui n’est présent que lorsque le setting NodeTreeCaching est activé, et qui accélère la compilation des différentes variantes d'un même template (par exploitation de l'arbre PHP de compilation plutôt que le .tpl d'origine). Lors de suppression manuelles et ciblées des caches (rm), il peut être nécessaire de supprimer également le fichier correspondant dans le répertoire en question, sous le nom de [hash]-[nomdutemplate].php

Travailler en mode ShareCompiledTemplates

Lorsque l’on active le paramètre ShareCompiledTemplates=enabled (section [TemplateSettings] dusite.ini), la clé de hash du stockage des templates compilés est alors beaucoup plus triviale, à savoir le chemin du template et la langue du siteaccess courant :

Tableau des éléments de la clé de hash, en mode ShareCompiledTemplates=enabled

Cette configuration est tout à fait adaptée à des instances eZ Publish propulsant de nombreux siteaccess, comme par exemple des usines à site, dont on ne maîtrise pas le nombre de siteaccess dans le temps

Cependant, il faut être attentif aux valeurs des settings (fichiers INI) spécifiques à chaque siteaccess, dont les valeurs sont par défaut compilés dans les templates. Il est donc nécessaire de charger dynamiquement ces valeurs de settings à chaque exécution des templates, en utilisant :

• Soit la directive globale DynamicTemplateMode=enabled (site.ini [eZINISettings])
• Soit au cas par cas dans l’utilisant de l’opérateur de template eZINI ( paramètre ‘dynamic’ )

Comment forcer la recompilation d'un lot de templates spécifiques ?

Pour forcer la recompilation d'un ou plusieurs templates en particulier (2 templates d'ezwebin dans cet exemple) :

php bin/php/eztc.php -s monsiteaccess --force extension/ezwebin/design/ezwebin/templates/pagelayout.tpl extension/ezwebin/design/ezwebin/templates/page_leftmenu.tpl
 

Résultat :
Compiled template file: extension/ezwebin/design/ezwebin/templates/pagelayout.tpl
Compiled template file: extension/ezwebin/design/ezwebin/templates/page_leftmenu.tpl

Lorsque la liste des templates est un peu longue, on peut se simplifier la tâche en utilisant une liste stockée dans un fichier TXT ou encore en résultat d’une commande ls / find ou autre...

Compile tous les templates d’ezwebin qui commencent par “page_header_” :

find extension/ezwebin/ -name "page_header_*.tpl" | xargs php bin/php/eztc.php --force
 

Compile tous les templates contenu dans le fichier template_list.txt :

cat template_list.txt | xargs php bin/php/eztc.php --force
 

Documentation officielle :
https://auth.ez.no/ezpublish/documentation/development/scripting/supplied_scripts/template_compiler

Attention : Le chapitre précédent nous apprend que la clé de hash d'un template compilé exploite le paramètre $pageLayoutVariable. eZ Publish ne déduit cette valeur que lorsqu'elle est appelé dans une URL de type « layout/set/... », à la volée dans le index.php. Le script eztc.php ne peut donc pas connaître et prévoir à l'avance les diverses combinaisons possible.

Pour le dire autrement, lorsqu'on utilise le module layout :

• eZ Publish compile autant de version des templates que de layout différents exploités, par exemple un template « page_head.tpl » existera en 4 versions si 3 layouts supplémentaire sont exploités (version par défaut, 3 version spécifiques)
• Le script eztc.php ne recompile que le layout par défaut, les 3 autres compilations seront effectuées par appel frontal des URL concernées. Pour mettre à jour ces templates spécifiques sans purger l'ensemble du cache, il faudra donc supprimer individuellement les versions compilés de ces templates dans le répertoire {VarDir}/cache/template/compiled/, puis attendre leur appels par des internautes (impact généralement négligeable en performance lorsque l'opération est ciblée sur un seul lot de templates)

Pour supprimer manuellement les différentes variantes d’un template compilé afin de forcer la recompilation à la volée (par exemple pour le page_head.tpl) :

find var/ezflow_site/cache/template -name "page_head-*" | xargs rm
 

Comment faire expirer le cache des overrides de templates ?

Lorsque vous ajoutez des templates dans votre extension spécifique, et que vous définissez de overrides sur ces templates, 2 caches sont impliqués dans cette opération :

• Le cache de la liste des répertoires de designs par site_access invoqués progressivement, stocké dans {VarDir}/cache/designbase_{hash}.php. Le {hash} est constitué d’un md5 du site_access invoqué

Il est possible de faire expirer ce cache par la commande :

php bin/php/ezcache.php -s monsiteaccess --clear-id=design_base
 

Le cache de la liste des overrides de templates par site_access invoqués progressivement, stocké dans {VarDir}/cache/override/override_{hash}.php. Le {hash} est constitué d’un md5 :

• du tableau des répertoires /design (design.ini [ExtensionSettings] DesignExtensions[])
• du SiteDesign “standard”
• du SiteDesign déclaré dans site.ini [DesignSettings] SiteDesign

Il est possible de faire expirer ce cache par la commande :

php bin/php/ezcache.php -s monsiteaccess --clear-id=template-override
 

Today I started to dig into the tons of unread mails I received this month. My first priority was to fix 2 formulas I've submitted to the homebrew project (one is for the eZ Components, the other one to be able to install php-intl which is a requirement for Symfony2 developments).

But, I discovered that homebrew people decided to stop maintaining PHP formulas in the main repository. They are not PHP developers and can't have a good sight on what they review and pull. Well, homebrew-php is the new repository to PHP-related formulas and adamv told me that multi-repositories management will be handled in a short term. So that's quite a good news !

Before doing anything regarding the formulas I've submitted, I was curious to install PHP 5.3.10 using homebrew and see how it works. This blog post is about that.

eZ Publish est un CMS infiniment flexible et puissant, qui propulse actuelle une grande variété de sites à faible ou à fort trafic. Cette puissance a un prix : la consommation de ressource en général, et la consommation de ressource SQL en particulier, ainsi que les I/O disque !

Autant de mécanismes à maîtriser pour dimensionner son architecture, ou comprendre l'impact d'un paramètre, d'une directive de cache-block ou encore d'une suppression massive de cache (template, cache-block ou cache de vue).

“

La lecture de ce tutoriel est particulièrement pénible et requiert une concentration & une patience à toute épreuve. Il est conseillé de le parcourir en plusieurs fois, équipé d'une bière ou d'une bonne bouteille de vin pour les plus aisés d'entre nous.

”

Introduction

Cette série d'articles donne un éclairage assez avancé sur le fonctionnement du cache eZ Publish, avec un focus particulier sur :

• le « cache des INI » : la mise en cache PHP des settings
• le « cache de template » : la compilation des fichiers *.tpl en *.php
• le « cache de vue » : la mise en cache des contenus stockés dans eZ Publish vers une sortie statique xHTML (ou autre)
• les « cache-block », la mise en cache des « template-block », portions xHTML (ou autre) contenus dans les templates, et hors de portée du cache de vue (pagelayout.tpl, templates des modules personnalisés, etc.)
• le rôle du fichier expiry.php
• le fonctionnement détaillé du script ezcache.php
• une simulation de performance sur les combinaisons d’indisponibilités des différents systèmes de cache
• et autres chapitres susceptible d'être ajoutés lors de la rédaction continu de cet ouvrage

Cette série d'article s'efforce de ne pas expliquer à nouveau ce qui est déjà décrit et compréhensible dans d'autres didacticiels ou documentations officielle, elle a pour vocation :

• D'expliquer comment eZ Publish gère « bas niveau » les fonctionnalités de cache qu'il propose : il s’agit de l’aspect « documentation » des articles
• D'en déduire un possible impact, une possible bonne ou mauvaise pratique dans l'utilisation et la combinaison des paramètres proposés. Il s’agit de l’aspect « tutoriel » des articles

A tous ceux qui considèrent que la gestion du cache eZ Publish est complexe et/ou problématique, il est également nécessaire de considérer les points suivants :

• Ce didacticiel existe (ce qui change tout), merci de le lire, de le critiquer, de le compléter, et de remonter toutes les questions ou erreurs détectées
• eZ Publish est gourmand en ressource (notamment SQL) de part son mode de stockage de données : le concept de classe & le concept d'EAV (entity / attribute / value), c'est le prix à payer pour profiter du concept magique de « classes de contenus », d'une stabilité fonctionnelle ou encore des possibles montées de versions depuis l'origine du CMS (modèle de données stable & universel)
• Les autres CMS « concurrents » ont la réputation de proposer une gestion de cache plus simple à manipuler, tout simplement par l'absence de gestion réelle de cache (généralement un simple TTL, une délégation à Varnish, une absence de cache en mode authentifié...)

Note : Les exemples et mécanismes décrits s'appuient sur la version eZ Publish 4.5+ Enterprise ou eZ Publish 2011.x communautaire

Un tutoriel / documentation pour qui ?

Cette série d'article s'adresse essentiellement :

• aux développeurs / administrateurs ayant une connaissance avancée d'eZ Publish
• aux développeurs de sites à fort trafic ou en recherche de gain de performance
• aux développeurs souhaitant se réconcilier avec leur hébergeur / administrateur de serveurs
• aux éco-citoyens soucieux du nombre d'ampoules grillées (ou de Panda assassinées) lors de la reconstruction des caches de vue ou des caches de template-block

Le cache de INI

Le cache des fichiers INI n’a pas de gros impact sur charge serveur, puisqu’il ne consomme pas de SQL, et assez peu de RAM / CPU. Comme nous le verrons dans ce chapitre, le cache de INI limite essentiellement le volume des I/O, et accélère de façon homogène le temps de construction des pages.

A quoi sert le cache de INI

eZ Publish accepte plusieurs conventions dans le nommage d’un fichier de configuration INI :

• mysetting.ini
  • à la racine de : settings
  • à la racine des extensions : extension/myextension/settings/mysetting.ini
  • à la racine de share/locale
• mysetting.ini.append (progressivement déprécié, à éviter)
• mysetting.ini.append.php pour surcharger un fichier INI dans les différents emplacement dédié :
  • settings/siteaccess/
  • settings/override/
  • extension/myextension/settings/
  • extension/myextension/settings/siteaccess/

La syntaxe exploitée dans les fichiers INI est de la forme :

<?php /*
 
[section]
setting1=value1
array_setting[]=value2
array_setting[]=value3
# ...
*/ ?>
 

La mise en cache permet de transformer cette syntaxe familière en tableau clé PHP hiérarchique, ne nécessitant pas un parsing systématique des fichiers INI

Comment sont générés les caches de INIeZ Publish génère les caches de INI « à la volée » de la façon suivante :

• Le chargement d’un fichier INI est invoqué par un template (ezini), ou l’API PHP (classe statique eZINI)
• Le hash et le chemin du fichier de cache concerné est calculé en amont
• Si le fichier existe en cache, on charge les données :
  • Si EZP_INI_FILEMTIME_CHECK est commenté (par défaut) dans config.php, alors vérification récursive dans toutes les surcharges concernés que les données n’ont pas changées, et sauvegarde d’un nouveau cache le cas échéant
  • Si EZP_INI_FILEMTIME_CHECK est décommenté (et reste à FALSE) dans config.php, utilisation directe des données du fichier de cache, sans vérification automatique de possibles mises à jour

define( 'EZP_INI_FILEMTIME_CHECK', false );
 

Comme le précise la documentaton dans le config.php, décommenté la ligne EZP_INI_FILEMTIME_CHECK améliore les performances puisqu’elle permet à eZ Publish de ne pas vérifier systématiquement la présence de possibles mise à jour dans l’arbre de surcharge des INI (gain en I/O, et gain constaté de 10% à 15% sur le chargement des pages eZ Publish, en fonction des performances I/O du système de stockage) :

eZ Publish stocke le cache des INI (ou plutôt les INI compilés en tableaux PHP) dans le répertoire non modifiablevar/cahe/ini/, de la façon suivante :
{nomdufichierini}-{hash}.php

Par exemple pour les différentes versions de design.ini :

• design-677247a49e428aa0837411b52777b920.php
• design-704216b4d0e3ea68c09742504bb366c8.php
• design-7333039e7e19aa411f8dd01836555861.php

Le hash est calculé à partir des clés suivantes :

Comment faire expirer l'ensemble du cache de INI

L’expiration complète du cache de INI s’effectue de la façon suivante :

php bin/php/ezcache.php --clear-id=global_ini
 

Supprime le répertoire var/cache/ini

php bin/php/ezcache.php --clear-tag=ini
 

Supprime le répertoire var/cache/ini, ainsi que le cache des extensions actives dans /var/cache/active_extensions_{hash}.php

php bin/php/ezcache.php --clear-id=ini
 

Ne fait rien, ou du moins tente de supprimer récursivement un répertoire qui n’existe pas, à savoir {varDir}/ini. Le répertoire ‘var/cache/ini/’ est fixé en dur dans lib/ezutils/classes/ezini.php...

Comment faire expirer un lot de cache de INI

Il n’est techniquement pas possible d’expirer un lot de cache de INI avec les commandes de base d’eZ Publish. Cependant, une expiration ciblée du cache des INI (site.ini par exemple) peut être effectuée par simple suppression des fichiers concernés :

find var/cache/ini -name "site-*" | xargs rm