eZ Publish : où placer les siteaccess ?
En voulant corriger un bug sur la prévisualisation des contenus en back-office, j’ai également appris une chose sur la configuration des siteaccess : il est nécessaire de les placer en dehors de l’extension, dans /settings/.
J’ai toujours pensé que c’était une question de « best practice », mais si le répertoire siteaccess se trouve dans /extension/mon_extension/settings/, la prévisualisation ne fonctionne pas.
Il y a d’ailleurs un bug datant de 2006, patché récemment : http://issues.ez.no/IssueView.php?Id=9903
Ce patch ne fonctionne qu’à moitié, on va bien chercher le siteaccess du front-office pour la prévisualisation, mais l’affichage ne prend en compte que le template générique full.tpl, sans passer par les règles du fichier override.ini.append.php.
A savoir donc.
De manière plus générale, certains settings ne sont pas correctement pris en compte lorsque les siteaccess ne sont pas placés dans le répertoire /settings/siteaccess.
Merci pour ce billet de rappel !
Pour plus d’infos sur les siteaccess en général, les cas d’utilisation et la pratique :
http://share.ez.no/tutorials/ez-publish/lots-of-websites-one-ez-publish-installation-adding-siteaccesses-in-ez-publish
En fait, il est tout à fait possible d’avoir une Prévisualisation avec des siteaccess dans une extension. Il suffit juste de rajouter le design prinpal dans AvailableDesignList dans site.ini (même si on l’a déjà défini en design principal). Cela dit, la Prévisualisation n’est pas toujours correcte.
A quand des settings fiables dans les extensions ? Y a-t-il une liste de fonctionnalités concernées par ce problème ?
Très bonne remarque sur les best practices. On pourrait étendre la question aux designs. Dans une extension ou dans le dossier design ?
Pour le répertoire design, c’est nécessairement dans une extension, le répertoire design à la racine n’est pas à toucher, il fait partie du « noyau » d’eZ Publish.
Le répertoire « extensions » fait aussi partie du noyau d’ez et pourtant, on y ajoute bien des extensions…
Le principal avantage du design dans une extension est qu’il peut alors surcharger d’autres extensions (ezwebin par exemple). Mais je crois me souvenir qu’il y avait d’autres problèmes avec cette méthode.
Le répertoire « extension » est créé par défaut avec des extensions livrées avec eZ Publish, mais ne fait pas partie du noyau à proprement parler du CMS.
Le répertoire « design », tout comme les modules, etc, sont nécessairement ajoutés dans une extension, le répertoire design à la racine étant écrasé lors des mises à jour de version eZ Publish.
Clarifions un peu…
La best practice au niveau design est de le mettre dans une extension (possible depuis la 3.6 il me semble). Il n’est pas interdit de mettre son design dans le répertoire design/ à la racine, mais il s’agit de l’ancienne façon de faire, pas très propre car on se retrouve avec des bouts de développement un peu partout…
Il est tout à fait possible de mettre à jour eZ Publish sans écraser un design du répertoire design/ ;-)
Par contre, au niveau des settings, il y a encore des progrès à faire !
Tout à fait, c’est au niveau des settings que le design dans une extension pose problème. Par exemple, les règles d’override à mettre en place pour le design ne peuvent pas être déclarées dans l’extension, sinon elles agissent sur tous les siteaccess.
Donc, au final, on ne peut pas mettre « tout » ce qui concerne un design dans une extension. Ou alors je ne sais pas comment faire…