Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/wp-includes/post-template.php on line 284

eZPublish et surcharge de datatype

Au cours de certains développements sous eZPublish, je me suis souvent dit : « Raahhh, ce serait tellement bien si ce datatype pouvait faire ça ou ça … » et ce serait si simple de modifier, un tout petit peu, un ou deux fichiers.

Mais, malheureusement, je m’impose pour règle de ne jamais modifier les fichiers originels d’eZ, et donc,de ne jamais modifier le noyau, pour faciliter, par exemple, le versionnement, ainsi que les mises à jour du noyau.

Du coup, à coup d’extensions, je ne voyais pas comment faire pour modifier le comportement des datatypes.

Jusqu’à ce que je trouve LE Saint Graal, LE post qui allait sauver ma vie à plusieurs moments sur le projet :

http://share.ez.no/forums/developer/override-kernel-classes

En effet, il est possible de redéfinir une classe de datatype dans une extension ! Et c’est relativement simple en plus.

Etape 1 : Créer une extension

En règle générale, j’essaye de tout mettre dans le dossier extensions : design, modules, siteaccess, surcharge de noyau, … Cela permet de savoir, à coup sûr, où se trouve l’ensemble des modifications.

Au minimum, l’extension devra avoir cette arborescence :

[code lang= »text »]/extensions/mon_extension
|- kernel
|    ` classes
|        ` datatypes
` settings
[/code]

Etape 2 : Préparer le fichier de configuration

Pour cette étape, il est juste nécessaire de préparer un fichier de configuration qui surchargera celui par défautCréer un fichier /extensions/mon_extension/settings/content.ini.append.php

Etape 3 : Déclarer la surcharge

Il est maintenant temps d’indiquer à notre instance d’eZPublish ce que nous nous préparons à faire. Pour cela, dans notre fichier content.ini.append.php, nous allons ajouter notre répertoire de datatypes :

[code lang= »ini »]
[DataTypeSettings]
RepositoryDirectories []
RepositoryDirectories []=extension/mon_extension/kernel/classes/datatypes
[/code]

Etape 4 : Démarrer le développement

Il est maintenant temps de mettre en œuvre ce que l’on voulait faire dans notre datatype.

Quelques idées par exemple :

  • Ajouter une fonction fromString à la classe eZEnum
  • Faciliter la gestion des relations d’objets
  • Redéfinir le fonctionnement d’une date pour qu’elle n’utilise plus le timestamp, mais attention, cela peut entraîner beaucoup d’autres modifications (workflows, …)

Pour cela, il faut copier le fichier de classe initial (ex: ezenumtype.php) dans le répertoires /extensions/mon_extension/kernel/classes/datatypes et le modifier en fonction de votre idée.

Etape 5 : Autoriser la surcharge du noyau eZPublish

Afin d’optimiser les performances d’eZPublish, il existe un petit fichier config.php à la racine. Celui-ci permet d’activer ou de désactiver certaines fonctionnalités.

On peut d’ailleurs y retrouver la vérification des modifications des fichiers ini (à désactiver en production) ou le mode de chargement des classes eZComponents.

Bref, ce fameux fichier permet aussi d’autoriser, ou non, la surcharge des classes  du noyau eZPublish.

Pour cela, il suffit de modifier la ligne :

[code lang= »php »]
define( ‘EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE’, false );
[/code]

par

[code lang= »php »]
define( ‘EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE’, true );
[/code]

Etape 6 : Notifier eZ du changement

Bien sûr, une fois cela fait, vous aurez certainement à vider les caches. Plus précisément, ce sont les caches des fichiers ini qui sont à vider puisque nous avons ajouter une surcharge à content.ini .

Ensuite, il faut demander à eZPublih de prendre nos classes de datatypes plutôt que les siennes. Ben oui, les notres sont mieux 😉

Il faut alors exécuter la commande suivante :
[code lang= »bash »]
php bin/php/ezpgenerateautoloads.php -o (Attention : droits sur le fichier ezpoverride.php)
[/code]

Elle permet de générer un fichier ezpoverride.php recensant les datatypes « custom ». Il faudra bien évidemment que l’utilisateur qui exécute la commande aient les droits d’écriture sur ce fichier et dans ce dossier.

Enfin l’exercice se termine par une régénération de l’ensemble des autoloads, par précaution :
[code lang= »ini »]
php bin/php/ezpgenerateautoloads.php
[/code]

Pour conclure, oui, j’en conviens, ce n’est pas l’idéal. A chaque mise à jour, il faut aussi mettre à jour le fichier surchargé. Ensuite, à chaque « régénération des autoloads », un warning de conflit apparaît, qui n’est pas logique d’ailleurs, puisque le conflit n’a pas lieu d’être.

Mais ca peut être tellement pratique. Je l’ai mis en place, par exemple, pour écrire une fonction fromString dans le datatype eZEnum (certes déprécié), et pour pouvoir gérer plus simplement une mise à jour d’une relation d’objets…

Vous aimerez aussi...

6 réponses

  1. Damien dit :

    Salut,

    très bon article ! Mais je crois qu’il manque une étape. Il faut en effet autoriser explicitement les « kernel override » en définisant la constante EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE à true dans config.php (voir config.php-RECOMMENDED)

  2. Xavier Langlois dit :

    Merci, exactement ce que je cherchais !
    Bonne continuation 😉

  3. Pierre dit :

    Bonjour,

    Je tente de surcharger la classe ezUser afin de permettre une authentification CAS. J’avais commencé en modifiant les fichiers du noyau (le mal :$) puis je suis tombé sur ton blog.
    Seulement voilà, au moment de la dernière étape j’obtiens ce message d’erreur :

    Warning:
    Class eZUser in file extension/ezCAS/kernel/classes/datatypes/ezuser/ezuser.php is already defined in:
    kernel/classes/datatypes/ezuser/ezuser.php (autoload/ezp_kernel.php)
    This class was not added to the autoload array.

    J’ai bien décommenté et autorisé la surcharge du noyau dans config.php-RECOMMENDED.
    As-tu une idée de l’erreur que j’ai pu faire ?

    Merci d’avance.

Laisser un commentaire

%d blogueurs aiment cette page :