Planète eZ Publish, Ze french corner!

Planète eZ Publish (Page 6)

Gilles Guirand : Comprendre le fonctionnement bas niveau du cache eZ Publish : Le cache de vue (Article 3)

Après ce « préambule » sur les compilations de templates, ce chapitre détaille le fonctionnement du cache de vue selon un axe pédagogique certainement perfectible (il est difficile de sélectionner un axe plutôt qu'un autre dans un contexte multidimensionnel).

Le cache de vue est mentionné sous diverses formes dans les fichiers de configuration, documentation ou tutoriaux : le cache de contenu, le cache de vue, le cache de vue de contenu, le cache d'affichage de contenu... ces termes désignent tous la même chose. Cet article utilise l'expression "cache de vue" afin d'être cohérent avec le vocabulaire du fichier de configuration "viewcache.ini"

A quoi sert le cache de vue ?

Pour vulgariser son usage, ou peut considérer que le cache de vue permet d'extraire « une seule fois » le contenu stocké dans eZ Publish, pour ensuite le mettre en cache (portion xHTML), en attendant une future expiration provoquant sa reconstruction (pour X raisons, la plus courante étant la mise à jour du contenu).

  • le cache de vue s'applique pour les URL couplée à un nœud par le module « content » : « content/view/... », qui retourne le contenu « cachable » au travers de $module_result.content
  • le cache de vue ne s'applique pas pour tout le reste, à savoir :
    • Le code autour du $module_result.content dans les divers pagelayout.tpl
    • dans tous les autres modules (natifs ou personnalisés)

Les différents modes d'expiration du cache de vue

Pour contrôler les performances d'eZ Publish, il est nécessaire de bien comprendre quels sont les évènements / actions / déclencheurs qui peuvent provoquer l'expiration du cache de vue pour une URL donnée (la home par exemple), un lot d’URL, ou encore toutes les URL (la pire des situations, qui ne devrait jamais être possible sur un site à fort trafic).

Une fois ces déclencheurs identifiés, le travail d'optimisation consiste à supprimer tous les déclencheurs critiques, au cas par cas, surtout ceux capable de provoquer une expiration massive du cache de vue (voir l'impact sur les performances). Ce chapitre décrit les différents mécanismes d'expirations du cache de vue, alors que le prochain chapitre décrit les différents évènements qui peuvent provoquer l'un ou l'autre de ces mécanismes d'expiration.

Le cache de vue peut expirer selon 2 mécanismes bien distincts, selon qu'il s'agisse d'une expiration complète (tous les caches de vue) ou partielle (1 lot de noeuds impactés) :

  • Expiration par lot de cache de vue (voir le chapitre suivant)
  • Expiration complète du cache de vue (voir le chapitre suivant)

Expiration par lot de cache de vue

Lorsqu'un cache de vue expire pour X raisons détaillés plus loin (partons du scénario courant de la mise à jour d'un article), il implique généralement une liste de noeud ayant un cache à expirer : le noeud de l'article lui même, et par exemple les noeuds des articles en relations, les frères, les parents, ou les noeuds exploitant les même mots clés (datatype ezkeyword), etc. (selon les directives du viewcache.ini). Il faut donc faire expirer un ensemble de fichiers de cache corrélés à cet ensemble de noeuds.

Une expiration d'un lot de cache consiste à "altérer" les fichiers de cache correspondant aux noeuds impliqués stockés dans{VarDir}/cache/content/

Le mode d'altération des fichiers est différent en fonction du filehandler (file.ini) exploité :

  • filehandler par défaut "ezfsfilehandler" : une suppression des fichiers impactés (unlink)
  • filehandler expérimental (stalecache) "ezfs2filehandler" : une modification de la date des fichiers impactés (touch), fixé au 25/05/1977 (jour de la sortie du 1er Star Wars)
  • filehandler de cluster DB "ezdbfilehandler" : une modification des enregistrements dans la table SQL "ezdbfile" (UPDATE expired=1)
  • filehandler de cluster DFS "ezdfsfilehandler" : une modification des enregistrements dans la table SQL "ezdfsfile" (UPDATE expired=1)

Une fois altérés, les caches sont reconstruits par comparaison entre 2 états :

  • filehandler par défaut "ezfsfilehandler" : si le fichier n'existe pas OU si la date du fichier est antérieure au timestamp du fichier expiry.php, recréer un cache
  • filehandler expérimental (stalecache) "ezfs2filehandler" : si la date du fichier est antérieure au timestamp du fichier expiry.php, le recréer
  • filehandler de cluster DB "ezdbfilehandler" : si le champs "expired=1" dans la table "ezdbfile" (pour rester simple) OU si la date du champs "mtime" est antérieure au timestamp du fichier expiry.php, recréer un cache
  • filehandler de cluster DFS "ezdfsfilehandler" : si le champs "expired=1" dans la table "ezdfsfile" (pour rester simple) OU si la date du champs "mtime" est antérieure au timestamp du fichier expiry.php, recréer un cache

La reconstruction de ce cache intervient (si la comparaison est positive) :

  • Soit : Par défaut, à la volée, lors de l'appel de l’URL par l'internaute
  • Soit lors de la publication de l'objet (si le paramètre PreviewCache du site.ini est activé). Dans ce cas, l’attente du contributeur lors de la publication en back office est plus ou moins supportable, puisque dépendante de la “boucle” sur l’ensemble des caches de vue à expirer

Expiration complète du cache de vue

Pour des raisons de stabilité du système, lorsqu'un évènement exige l'expiration "complète" du cache de vue, eZ Publish ne peut bien évidement pas boucler sur l'ensemble des fichiers pour les faire expirer. Dans ce cas, la valeur 'content-view-cache' du fichier {VarDir}/cache/expiry.php est modifiée afin de rendre opérant le mécanisme de comparaison expliqué ci-dessus.

Cet évènement n'est pas anodin, notamment sur les sites à fort trafic qui vont subir une charge importante lors de la reconstruction massive et rapide de l'ensemble des caches de vue. Il faut ainsi considérer que cet évènement ne doit jamais se produire sur un site à fort trafic et qu'il est important d'identifier tous les déclencheurs possibles afin de les neutraliser (voir le chapitre concerné).

Cependant il est parfois difficile de contourner cet évènement (par exemple sur la création d'une classe de contenu), il faut dans ce cas disposer d'une architecture & d'un configuration eZ Publish suffisamment dimensionnée (ou neutraliser le expiry.php par un backup...), par exemple :

  • Utilisation du stalecache (ezfs2filehandler, ezdfsfilehandler, ezdfsfilehandler seulement) permet de limiter les impacts sur les reconstructions concurrente des caches (homepage par exemple). Pour en savoir plus sur stalecache :http://share.ez.no/learn/ez-publish/ez-publish-knowledge-series-stale-cache-or-how-caches-in-ez-publish-4.1-are-handled-in-a-smarter-way
  • Utilisation d'un cache frontal (varnish)
  • Infrastructure d'hébergement flexible (virtualisation, haute disponibilité), permettant d'assumer un pic de charge
  • Dans tous les cas une optimisation du code des templates, afin de limiter les pages générant trop de requêtes (utilisation eZ Find pour les listes à filtres, persistent variables, loadDataMap = false, etc.). Ces mécanismes d'optimisations du code pourraient faire l'objet d'un autre tutoriel...

Les déclencheurs d'expiration du cache de vue & les modes d'expirations associés (lot ou complet)

Le chapitre précédent détaille les différentes modes d'expiration du cache de vue (par lot ou complet), ce chapitre décrit quand en lui les différentes évènements déclencheur qui peuvent provoquer cette expiration (par lot ou complète), que soit volontaire ou malgré vous.

Ces 2 notions de « volontaire » ou « malgré vous » sont déterminantes, puisque :

  • L'expiration « volontaire » des caches de vue peut être utilisée à mauvais escient, par exemple pour tenter de résoudre un problème non lié au cache de vue ou encore en sous estimant l'impact d'un vidage massif du cache de vue, qui n'implique en fait qu'un seul lot de cache (on expire souvent tout le cache par facilités, ou parce qu'on ne connaît pas d'autres façon de procéder, sans considérer l'impact de cet action)
  • L'expiration « malgré vous » des caches de vue signifie que le cache a expiré suite à une action / évènement qui peut paraître anodine et non impactant pour les caches : vous ne saviez tout simplement pas que cette action provoquait un expiration complète du cache de vue. Ainsi l'ajout d'une classe de contenu provoque l'expiration complète du cache de vue, sans lien direct déductible, ce qui peut provoquer une charge serveur insupportable en fonction du contexte (fort trafic, pas de cache Varnish...)

Expiration complète du cache de vue par script

Cette action est forcement « volontaire » :

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

Résultat : Cache d'affichage de contenu

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

Résultat : Cache d'affichage de contenu, Cache des identifiants de classes, Cache des clés de classement, Cache des alias d'URL, Cache des template block, Cache RSS, Menu de l'arborescence de contenu., Cache des limitations d'états.

L'exécution de ces scripts ne cible pas un nœud ou une liste de nœud en particulier. L'expiration du cache de vue est donc globale : mise à jour du fichier {VarDir}/cache/expiry.php, et le changement de la valeur 'content-view-cache' => timestamp à jour

Expiration partielle du cache de vue par script

Cette action est forcement « volontaire » :

php bin/php/ezcontentcache.php –clear-node=2
php bin/php/ezcontentcache.php –clear-node=2,46,63
php bin/php/ezcontentcache.php –clear-node=/company/about
php bin/php/ezcontentcache.php –clear-subtree=/company/about
php bin/php/ezcontentcache.php –clear-subtree=/company/about,/news

Documentation du script ezcontentcache.php :
http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/View-caching/Clearing-the-view-cache

Attention : la suppression partielle du cache de contenu peut automatiquement se transformer en suppression complète du cache de vue si le nombre de nœuds impliqués ( par n’importe que noeud de la liste ou du sous arbre ) est supérieur au CacheThreshold (250 par défaut), voir le chapitre sur le CacheThreshold

Attention : Actuellement une expiration du cache de vue à partir d’une liste de noeuds ou d’un sous arbre reproduit l’ensemble du processus ( smartviewcache, CacheThreshold, expiration des template-block liés à un subtree expiry relatif, etc. ) pour chacun des noeud concernés (liste de noeuds, ou noeuds du sous arbre ). Ainsi, et pour simple exemple parmi d’autres, une règle de smartviewcache sur les frères ( siblings ) pourrait entraîner une expiration du cache de vue “au carré” ( les noeuds expirent autant de fois que le nombre de noeuds frères ), et rendre instable le système.

Expiration partielle du cache de vue par le viewcache.ini

Le mécanisme du viewcache.ini est déjà largement détaillé dans d'autres tutoriaux, cet article souhaite s'attarder en particulier sur les configuration critiques ou les recommandations concernant les sites à fort trafic.

Il est en effet fréquent que les règles du viewcache.ini provoquent régulièrement l'expiration complète des caches de vues, malgré vous, sans réelle pertinence ou besoin fonctionnel. En effet, la suppression partielle du cache de contenu peut automatiquement se transformer en suppression complète du cache de vue si le nombre de nœuds impliqués est supérieur au CacheThreshold (250 par défaut), voir le chapitre sur le CacheThreshold.

Il est donc important de maîtriser le nombre de nœuds impactés par une mise à jour de contenu, et pour cela de travailler en mode « Smart view cache », en prenant soin de :

  • Ne pas utiliser de directive « all »
  • Ne pas utiliser de directive « siblings » si le contenu est massivement stocker sous le même emplacement (frères)
  • Configurer le KeywordNodesCacheClearLimit à 0 si vous utilisez massivement les mots clés

Documentation du fonctionnement du Smart view cache :
http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/View-caching/Smart-view-cache-cleaning
Documentation du KeywordNodesCacheClearLimit dans le fichier viewcache.ini
# The maximum number of linked keyword nodes to go trough
# when looking for objects that needs to have its cache cleared.
# Set to integer to activate, 0 to disable keyword clearing globally
# or disabled to not have any limit at all (default value)
KeywordNodesCacheClearLimit=0

Documentation du fonctionnement du Smart view cache :
http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/View-caching/Smart-view-cache-cleaning

Expiration volontaire du cache de vue en Back Office

Expirer le cache de vue “volontairement” en Back Office, que ce soit via un nœud, un sous arbre ou l'ensemble du cache de vue (onglet /setup/cache/) est une mauvaise pratique a réserver exclusivement aux versions de développement du site.

Ce tutoriel ne souhaite pas faire la promotion de cette pratique (malheureusement trop répandu) et n'en dira donc pas plus à ce sujet à part : un webmaster ou éditeur de contenu ne doit en aucun cas avoir accès aux fonctionnalités de gestion du cache, qui peut dans tous les cas :

  • être automatisé et sécurisé sans avoir recours à des actions manuelles
  • provoquer d'énormes instabilités du système / crash serveurs sur un site à fort trafic

Attention : Actuellement une expiration du cache de vue à partir d’un noeud (back office ou script ezcontentcache.php), implique l’expiration récursive de tous les sous noeuds de l’emplacement sélectionné. Cette expiration reproduit l’ensemble du processus (smartviewcache, CacheThreshold, expiration des template-block liés à un subtree expiry relatif, etc.) pour chacun des noeud concernés. Ainsi, et pour simple exemple parmi d’autres, une règle de smartviewcache sur les frères (siblings) pourrait entraîner une expiration du cache de vue “au carré” (chaque noeud expire autant de fois que le nombre de noeuds frères), et rendre instable le système.

Expiration complète et involontaire du cache de vue suite à une action en Back Office

Un certain nombre d’opérations font expirer l’ensemble du cache de vue en back office, malgré l’utilisateur ou l’administrateur, qui n’a pas forcement connaissance de la corrélation entre une action back office et l’expiration du cache de vue. Voici une liste, qu’on espère exhaustive des actions en back office qui font expirer l’ensemble du cache de vue :

  • Rôles : édition / suppression d’un rôle, édition / suppression de l’assignation d’un rôle
  • Sections : assignation d’une section
  • La manipulation du ezshop : manipulation des règles de discount, groupes de discount, affectation d’utilisateurs aux groupes, édition / suppression des monnaies, etc.
  • Classes de contenu : la création d’une nouvelle classe (même sans objets associés), l’édition et la suppression d’une classe
  • Langues : ajout / suppression d’une langue

En dehors de la fonctionnalité de création d’une classe (sans object par défaut), les autres actions back office expirent logiquement l’ensemble du cache de vue. Comme nous le verrons dans un prochain chapitre, ces informations sont exploitées “par défaut” dans la clé de hash du cache de vue (sans prise en compte toutefois d’une éventuelle désactivation de certaines clés par exploitation du paramètre ViewCacheTweaks).

CacheThreshold, une expiration partielle du cache de vue qui devient complète

Lorsqu'un cache de vue expire pour X raisons (mise à jour d'un article, script ezcontentcache.php...), il implique généralement une liste de nœud ayant un cache à expirer : le nœud de l'article lui même, et par exemple les nœuds des articles en relations, les frères, les parents, ou les nœuds exploitant les même mots clés, etc. (selon les directives du viewcache.ini).

Au final, eZ Publish est capable de calculer le nombre de nœuds impliqués dans le vidage de cache déclenchés. Pour stabiliser le système et éviter par exemple d'ordonner l'altération de trop de fichiers de caches sur le serveur (unlink, touch, update SQL... selon le filehandler exploité), eZ Publish utilise pour cela une limite, le CacheThreshold :

  • Si le nombre de noeuds impactés est inférieur au CacheThreshold : eZ Publish « invalide » les fichiers de cache selon le filehandler exploité (suppression par défaut). Voir le chapitre qui détaille les différents mode d'altérations (unlink, touch, update SQL...)
  • Si le nombre de noeuds impactés est supérieur au CacheThreshold : eZ Publish bascule alors en mode d'expiration complète du cache de vue par changement de la valeur 'content-view-cache' (timestamp à jour), du fichier{VarDir}/cache/expiry.php

Comment sont stockés les fichiers de cache de vues ?

eZ Publish utilise une arborescence de répertoires sous {VarDir}/cache/content/{siteaccess}/, qui permet de répartir le gros volume potentiel de fichier générés, de la façon suivante :

  • A la racine de {VarDir}/cache/content/{siteaccess}/ : les fichiers qui sont compris en "2-" et "99-"
  • dans les répertoires {VarDir}/cache/content/{siteaccess}/{chiffre}/{chiffre}/{chiffre} : les fichiers qui commencent par les "chiffre" cumulés + 2 chiffres, par exemple : "2/1/5" -> "215xx-"

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

Voici une simulation simplifié d'une arborescence de cache de vue :
{VarDir}/cache/content/{siteaccess}/
2-ce182234bd70236c6a009578d2a34632.cache
20-ce182234bd70236c6a009578d2a34632.cache

{VarDir}/cache/content/{siteaccess}/1
101-ce182234bd70236c6a009578d2a34632.cache
105-ce182234bd70236c6a009578d2a34632.cache

{VarDir}/cache/content/{siteaccess}/2
204-ce182234bd70236c6a009578d2a34632.cache
210-ce182234bd70236c6a009578d2a34632.cache

{VarDir}/cache/content/{siteaccess}/5/2/1
52101-ce182234bd70236c6a009578d2a34632.cache
52144-ce182234bd70236c6a009578d2a34632.cache

Les noms des fichiers est construit de la façon suivante :

{nodeid}-{hash}.php
2-ce182234bd70236c6a009578d2a34632.cache

Le hash est calculé à partir de nombreuses valeurs séparées en 2 catégories :

  • Les valeurs de clé présentes par défaut et non désactivables
  • Les valeurs de clé présentes par défaut et désactivables par des directives du site.ini : les ViewCacheTweaks. Ces paramètres permettent de partager un même cache lorsque le contenu n'est pas influencé par le paramètre en question. Il est en effet plutôt inutile de générer et stocker des caches différents par « view_parameters » ou « user_preferences » lorsque le résultat produit n'est pas influencé par ces valeurs.

Tableau des éléments de la clé de hash non désactivables

Elément de la clé de hash

Signification

Exemple de valeur

nodeID

Noeud courant

2

viewMode

Vue courante, dont la liste est extensible dans :

[ContentSettings] / CachedViewModes=full;sitemap;pdf

full | sitemap | pdf

layout

Nom du pagelayout personnalité, si la vue est invoquée lors de l'appel d'un URL de type « layout/set/print » par exemple (module layout)

print

language

Sur définition de /(language)/value

Null par défaut, sinon « value »

offset

Sur définition de /(offset)/value

Null par défaut, sinon « value »

indexFile

La racine de l'index du site, qui peut varié selon divers paramètres, comme par exemple : le nom du siteaccess en mode « URI », ou encore la racine «layout/set/... »

site_admin | layout/set/print

Tableau des éléments de la clé de hash désactivables (Tweaks) par noeud ou en global

ViewCacheTweaks[<node_id>]=<setting>[;<setting2>]
ViewCacheTweaks[global]=<setting>[;<setting2>]

Elément de la clé de hash

Signification

Exemple de valeur

roleIDList

Liste des rôles affectés à l'utilisateur courant

ViewCacheTweaks :
ignore_userroles

5.10
implode de Array( 5, 10 )

limitValueList

Liste des limitations affectés à l'utilisateur courant (subtree)

ViewCacheTweaks :
ignore_userlimitedlist

/1/2/./1/43/
implode de Array( '/1/2/', '1/43' )

discountList

Liste des règles de « discount » liées à l'utilisateur courant (eZShop)

ViewCacheTweaks :
ignore_discountlist

Non testé, même logique de tableau que ci-dessus

cacheNameExtra

Détermine que le « access type » du siteaccess est défini par URI, afin d'éventuellement stocker séparément les caches selon les « access type »

ViewCacheTweaks :
ignore_siteaccess_type

NULL | 2

pr_user

Détermine s'il faut ou non stocker un cache par utilisateur (désactivé par défaut)

ViewCacheTweaks :
pr_user (active cette fois)

15-

ObjectID, suivi de « - »

viewParameters

Liste les viewparameters : /(clé)/valeur/(clé2)/valeur/...

ViewCacheTweaks :
ignore_viewparameters

vp:day=vp:month=vp:namefilter=vp:offset=vp:year=
Liste de « vp: » + clé + « = » + valeur

userPreferences

Liste les préférences utilisateur courante, en ajoutant celles définies dans

[ContentSettings] / CachedViewPreferences

p:admin_navigation_content=1; p:admin_children_viewmode=list; p:admin_list_limit=1 ;

Liste de «p: » + clé + « = » + valeur + « ; »

Au final le nom du fichier est constuit selon la trame :
{VarDir}/cache/content/{siteaccess}/{$numbers}/$nodeID . '-' . $cacheNameExtra . md5( implode( '-', $cacheHashArray ) ) . '.cache';

  • $nodeID est le noeud courant
  • $cacheNameExtra est vide en mode HOST, égal à 2 en mode URI (ou vide si le ViewCacheTweaksignore_siteaccess_type est activé)
  • $cacheHashArray est le tableau de toutes les valeurs décrites ci-dessus

La clé de hash est donc constituée de plusieurs paramètres combinables, qui font impérativement connaître afin de bien comprendre et maîtriser l'impact d'une suppression complète du cache de vue.

En effet, un possédant de nombreux siteaccess et surtout de nombreuses combinaisons de 'viewparameters' pourrait générer un grand nombre de combinaisons possibles de cache de vue, autant de caches à reconstruire lors d'une expiration massive !

Si on suit cette logique de construction, cela implique que la construction d'une URL erronée, mais "valide" dans la typologie d'URL eZ Publish génère également systématique un cache de vue : http://website.com/(param)/hello1, http://website.com/(param)/hello2, http://website.com/(param)/nimportequoi , etc... On peut ainsi remplir progressivement le disque de cache inutiles, et rendre critique une expiration de cache sur le nœud concerné par une invalidation trop massive de fichiers de caches

Comment faire la correspondance entre un cache de vue et la page / URL d'origine ?

Pour les plus courageux qui souhaitent explorer les fichiers de caches générés et en déduire une exploitation / information utile, voici quelques pistes permettant d'effectuer un peu d'optimisation.

Comme nous l'avons détaillés précédemment, un même nœud peut avoir une grande combinaison de caches de vues (voir la clé de hash du nom du fichier dans le chapitre concerné). Dans un souci d'optimisation, il peut être utile d'investiguer la cause d'une génération massive de cache de vue (homepage par exemple) : des centaines de caches de vue sur le noeud "2-{hash}.cache".

Dans ce cas, lorsqu'on explore un fichier généré, on retrouve en pied de fichier la combinaison de paramètres qui a provoqué sa génération, puisqu'à l'origine d'une clé différente de hash, par exemple :
"view_parameters";a:6:{s:6:"offset";b:0;s:4:"year";b:0;s:5:"month";b:0;s:3:"day";b:0;s:10:"namefilter";b:0;s:4:"test";s:1:"2";}

On peut en déduire que ce cache a été provoqué par la présence du viewparameter "/(test)/2"

Comment logger l’activité du cache de vue ?

La meilleure façon de maitriser son optimisation du cache de vue reste encore de pouvoir logguer son activité de la façon suivante :

  • Quelle URL a déclenché une expiration ?
  • Quel est le noeud concerné ?
  • Combien d’autres noeuds sont concernés par cette expiration ?
  • Quel est la liste de ces autres noeuds ?

Depuis eZ Publish 4.5, il existe une façon assez simple de procéder, en utilisant le mécanisme de programmation événementiel : ezpEvent. Un certain nombre d’évènements sont ainsi positionnés dans le Kernel eZ Publish ( en fonction des évolutions fonctionnelles ou des besoins du eZ Market ). Ainsi l’évènement “content/cache” est disponible par défaut sur eZ Publish.
Pour logger l’activité du cache de vue, il suffit donc :

  • 1. De faire un mapping entre l’évènement “content/cache”, et une méthode statique d’une nouvelle classe ( par exemple la méthode logviewcache de la classe test )

Dans votre settings/override/site.ini.append.php :

[Event]
Listeners[]=content/cache@test::logviewcache
  • 2. De créer la classe PHP en question ( répertoire classes/ d’une extension ), en écrivant le code souhaité, par exemple :
<?php
class test
{       
   static public function logviewcache( $nodeList )
   {
    $uri = $GLOBALS['_SERVER']['REQUEST_URI'];
    eZLog::write('node_id count : '. count( $nodeList ). ' / node_id list : ' . implode(', ', $nodeList ) . ' / URI : '.$uri, 'chachethresold.log');
 
    return $nodeList;
}}
?>
  • 3. Regénérer les autoloads :
php bin/php/ezpgenerateautoloads.php

Le cache de vue « in a nutshell » : 5 minutes et 2 schémas

eZ Publish viewcache

eZ Publish viewcache 2

Publié par Gilles Guirand le



Jean-Luc Nguyen : Tip eZ Publish : affichage des colonnes par défaut dans l’interface d’administration

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
Publié par Jean-Luc Nguyen le

Jean-Luc Nguyen : eZ Publish : upload d’un fichier binaire dans un formulaire

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.

Publié par Jean-Luc Nguyen le


Damien Pobel : Quelques nouveautés dans le formulaire d'édition de contenu d'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é via une 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)

Publié par Damien Pobel le

Sébastien Morel (Plopix) : eZ Publish on Windows server 2008 and Oracle 11g

Hello everybody,

Reading this title is very strange for me ! I never thought of writing an article on eZ Publish, Windows and Oracle !

But, the customer is the king and for several reasons, sometimes, we have to install specials architectures.

First, I must say, that it's not a good advice to install eZ Publish on Windows, my advice is to install it on Linux!
The choice of the database implementation is more complicated, personnaly I like MySQL but Postgres is good too. (Oracle? why not, but if you have reals reasons and money)

End of this introduction, let's you enter into a new world.
I'm not a Windows expert, and this article shows the point of view of a Linux user.

1. Windows and Oracle Installation

Windows OS installation is not very funny, so I will skip this part.
And, happy me, I only had to install eZ Publish over an existing Oracle database 11g.

I think an Oracle installation is a real big work, it can't be resumed simply, so I will skip this too. I only want to explain the eZ Publish installation.

2. PHP and Internet Information Server 7.x

2.1 IIS 7

eZ Publish Community 2012.2 can run on IIS 7 and PHP5 (http://doc.ez.no/eZ-Publish/Technical-manual/4.6/Installation/Requirements-4.6).
As you know, eZ Publish needs somes rewrite rules, so you will have to install the Microsoft URL Rewrite Module 1.1.

2.1.1 Installation

The IIS 7 installation begins with : Control panel > Get programs, and you can add "Internet Information Server".
This step is really simple and quick.

2.1.2 Configuration

When it's finished, configure the default site to set the DocumentRoot of your eZ Publish installation.
Create a new file index.html in you DocumentRoot in order to test your webserver : http://localhost. (localhost, I assume that you are working on the Windows web server)
The next step is the installation of the Microsoft URL Rewrite Module 1.1 : double click and proceed this installation.

Don't be impatient, you will add the RewriteRule for eZ Publish later.

Note: I'm not a expert on Windows, but at this time, I searched where to set the IIS user. I didn't find this information.
I had some rights problems during my entire installation, but I think they are related to the security policies of the company.

IIS 7 Manager

2.2 PHP 5

2.2.1 Installation

When IIS 7 is running, you need to install PHP (5.3.10 for now). Here, you can download the Window Installer (.msi) of the thread safe version.
When you install this msi, choose the IIS Fast CGI mode.

Concerning the extensions, choose as you want.
If, like me, you want to install eZ Publish with Oracle, you have to install oci8 driver but choose the mysqli driver too. (I will explain later why)

2.2.2 Configuration

Now, you can create a index.php with a phpinfo() to see your PHP installation configuration.
At this time, you would change the php.ini parameters for your server, but, it's not so easy !

I don't know why but my changes in the php.ini had no effect. After some research on my best friend Google, I installed a new module on IIS "PHP Manager". It saved my life !
Through this manager, I could change the php.ini configuration correctly.

Note: It's very strange on Windows, the PHP Manager gave me a path for the php.ini (the same path as in the phpinfo()), but when I modified this file manualy, it didn't change anything.
Double check this configuration with a php.exe -i in the command line.

Note: If some things are strange don't hesitate to restart some services like

  • FastCGI settings
  • PHP Manager
  • IIS
  • The OS (if you want to be sure)

Note: I'm sad to say that but we are on Windows...

2.3 PHP - Oracle

2.3.1 Database driver installation

The Oracle database installation was already done. But on the web server, there was neither the oracle client, nor the good library.

As this time, when I launched the php.exe in a command line I had this error : "OCI8.DLL not found". Later on, I found I have the same in the PHP error log.

As described in the eZ Oracle installation documentation, the Oracle Instant Client must be installed on the webserver.

Even if your OS is in 64bit mode, you have to download the Instant Client for Microsoft Windows (32-bit), because PHP for Windows works only in 32bit mode.

Oracle Instant Client

Follow the installation instructions and don't forget to correctly change your PATH variable environment.

PATH Variable

3. eZ Publish with eZ Oracle 2.x

eZ Systems provides an extension eZ Oracle to handle the Oracle database implementation. The documentation is very clean and usefull.

Be careful when you download the package. The documentation shows a link to http://projects.ez.no/ezoracle, but on this project, there is a important note ( at the bottom of the page) to go on Github.

Finally, with eZ Publish Community 2012.2 use eZ Oracle 2.3 and download it directly from Github : https://github.com/ezsystems/ezoracle

3.1 Installation

My mission was to install an new eZ Publish on this architecture.

3.1.1 Fisrt way, but is not the good one for me

The eZ Oracle setup instructions explains how to install the extension, import the eZ schema and the eZ data.

But after that, you have to continue the eZ Publish installation process manually. You can't use the standard installation process using the browser (Mail, Databases, languages, siteaccess settings etc…)
And you have to install the imported packages manually too. (ezwebin, ezflow etc...)
I first tried this method, but I canceled.

Now, I know the second method works perfectly, I advise you to use it.

3.1.2 Second way

It's more easy when you come from Linux to install a new eZ Publish on your Linux. (5-20 minutes max).
So I do a new installation on Linux, Apache, and MySQL on my Debian virtual machine.
At this time, my task wasn't to install an new eZ Publish but to migrate an existing one to Windows and Oracle. So, I just had to :

  • move the eZ Publish files from my Linux installation to the Windows DocumentRoot
  • quick install the eZ Oracle on this eZ Publish
    • unpack in extension directory
    • in override/site.ini.append.php add ActiveExtensions[]=ezoracle in ExtensionSettings section
    • regenerate the autoloads ( php bin/php/ezpgenerateautoloads.php -e)
  • migrate the MySQL database to the Oracle database.

The last step can be complicated ! But no, eZ Oracle include a script to do that perfectly !

Note: Naturally, you can do that without installing MySQL on you Windows Server. The MySQL server on your virtual machine will do the job.

3.2 Migrate from your LAMP installation

3.2.1 Files

You just have to copy all files and be careful about the rights.

3.2.2 Rewrite Rules

It's time to install the Rewrite Rule.

To do that, simply add this file : web.config into the DocumentRoot. Like a .htaccess file, IIS will read it.


 version="1.0" encoding="UTF-8"?>
>
  >
 
    >
      
      >
         value="index.php" />
         value="index.php" />
      >
    >
 
    >
      >
 
         name="Rest API" stopProcessing="true">
           url="^api/" ignoreCase="false" />
           type="Rewrite" url="index_rest.php" />
        >
 
         name="Treemenu" stopProcessing="true">
           url="^([^/]+/)?content/treemenu.*" ignoreCase="false" />
           type="Rewrite" url="index_treemenu.php" />
        >
 
         name="Direct access resources" stopProcessing="true">
           url=".*" ignoreCase="false" />
           logicalGrouping="MatchAny">
             input="{URL}" pattern="var/([^/]+/)?storage/images(-versioned)?/" ignoreCase="false" />
             input="{URL}" pattern="var/([^/]+/)?cache/(texttoimage|public)/" ignoreCase="false" />
             input="{URL}" pattern="design/[^/]+/(stylesheets|images|javascript)/" ignoreCase="false" />
             input="{URL}" pattern="share/icons/" ignoreCase="false" />
             input="{URL}" pattern="extension/[^/]+/design/[^/]+/(stylesheets|flash|images|lib|javascripts?)/" ignoreCase="false" />
             input="{URL}" pattern="packages/styles/.+/(stylesheets|images|javascript)/[^/]+/" ignoreCase="false" />
             input="{URL}" pattern="packages/styles/.+/thumbnail/" ignoreCase="false" />
             input="{URL}" pattern="var/storage/packages/" ignoreCase="false" />
          >
           type="None" />
        >
 
        
         name="Faviconrewrite" stopProcessing="true">
           url="^favicon\.ico$" ignoreCase="false" />
          
          
           type="None" />
        >
         name="Favicon" stopProcessing="true">
           url="^design/standard/images/favicon\.ico$" ignoreCase="false" />
           type="None" />
        >
 
        
         name="Robots" stopProcessing="true">
           url="^robots\.txt$" ignoreCase="false" />
           type="None" />
        >
 
        
        
 
        
         name="P3P" stopProcessing="true">
           url="^w3c/p3p\.xml$" ignoreCase="false" />
           type="None" />
        >
 
         name="Everything else">
           url=".*" ignoreCase="false" />
           type="Rewrite" url="index.php" />
        >
      >
    >
 
  >
>
3.2.3 Database

I assume you have already an Oracle database with the good eZ Oracle requirements.

The eZ Oracle documentation explains how to migrate from MySQL, I will only explain these commands :

Note: Unusually on eZ Publish, you have to run this command in the extension/ezoracle/bin/php directory.

php mysql2oracle-schema.php YOURMYSQLDB:mysqluser/mysqlpassword@YOURLAMPMySQLSERVER --drop > mydump.sql 

This command dumps your MySQL schema from your MySQL server (in my case my virtual machine).
You can now understand why we needed to install the mysqli driver at the php installation step. (Your Windows server has to connect to a MySQL server)

You have to load this file into the Oracle database. You can do that using SQLPlus or the client of your choice (like TOAD, or Navicat)

Using SQLPlus :

sqlplus oracleuser/oraclepassword@ORCL <</span> mydump.sql 

Note: In my case ORCL was ORACLESERVER_HOST/ORACLEDATABASE_NAME

When the dump is imported into your Oracle database, the last steps are very simple.

Migrate the data :

php mysql2oracle-data.php YOURMYSQLDB:mysqluser/mysqlpassword@YOURLAMPMySQLSERVER oracleuser/oraclepassword@ORACLESERVER_HOST/ORACLEDATABASE_NAME

Update the sequences :

php ora-update-seqs.php oracleuser/oraclepassword@ORACLESERVER_HOST/ORACLEDATABASE_NAME

Final steps :

  • Configure the override/settings/site.ini.append.php's DatabaseSettings section
    [DatabaseSettings]
    DatabaseImplementation=ezoracle
    User=oracleuser
    Password=oraclepassword
    Database=ORACLESERVER_HOST/ORACLEDATABASE_NAME 
    
  • Clear the cache
    php bin/php/ezcache.php --clear-all
    

Enjoy your eZ Publish !

Conclusion

This tutorial comes from my notes and I think I didn't forget anything.

Even if this installation works, my advice will always be to install eZ Publish on Linux.
I didn't make any benchmark, but I think the performances will always be better on Linux.

But, If one day you have to do this installation I hope this article will help you ;-)

Plop+

Publié par Sébastien Morel (Plopix) le

Agence Yuzu : Créer un espace privé sur eZ Publish

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.

Publié par Agence Yuzu le

Gilles Guirand : Comprendre le fonctionnement bas-niveau du cache eZ Publish : La compilation des templates (Article 2)

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

Elément de la clé de hash

Signification

Exemple de valeur

key

MD5 du chemin complet du template

md5(‘extension/ezwebin/design/ezwebin/templates/pagelayout.tpl’)

internalCharset

Le charset interne

utf-8

language

La langue définie pour le siteaccess utilisée lors de la compilation

fre-FR

useFullUrlText

En fonction de la directive UseFullUrl (layout.ini) si le template est compilé lors de l'appel d'un URL de type « layout/set/... » (module layout)

full | relative

accessText

Nom du site siteaccess utilisée lors de la compilation, avec un « - » devant

-site_admin

pageLayoutVariable

Nom du pagelayout personnalisé, si le template est compilé lors de l'appel d'un URL de type « layout/set/print » par exemple (module layout)

print_pagelayout.tpl

indexFile

La racine de l'index du site, qui peut varié selon divers paramètres, comme par exemple : le nom du siteaccess en mode « URI », ou encore la racine « layout/set/... »

site_admin | layout/set/print

extraName

Le nom du template, sans le « .tpl », avec un « - » à la fin

pagelayout-

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

NodeTreeCaching

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

Elément de la clé de hash

Signification

Exemple de valeur

key

MD5 du chemin complet du template

md5(‘extension/ezwebin/design/ezwebin/templates/pagelayout.tpl’)

language

La langue définie pour le siteaccess utilisée lors de la compilation

fre-FR

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
Publié par Gilles Guirand le