Miximum

Dans mon snippet précédent sur la récupération d’objets de contenu, j’utilise la fonction subTree avec une option AttributeFilter. Savez vous combien de temps j’ai passé à écrire ces 5 lignes ? 4h ! Tout ça à cause d’une stupide erreur de cache.

Pendant 4h, j’ai tout essayé pour faire fonctionner ce code : rien à faire ! Il ne me retournait aucun résultat. J’ai essayé toutes les combinaisons d’attributs possibles et imaginables, rien à faire. Le pire, c’est qu’en utilisant un autre attribut pour le test, tout se passait nickel. Rageant.

En désespoir de cause, j’ai fini par me plonger dans le code source d’eZ Publish, voici ce que j’ai découvert.

La fonction subTree d’eZ Publish fait appel à createAttributeFilterSQLStrings, qui elle même appelle classAttributeIDByIdentifier.

Cette dernière fonction permet de récupérer l’id d’un l’attribut en fonction de son identifiant de la forme ‘classe/attribut’, notation fort pratique qui évite d’avoir à utiliser directement l’id.

Pour retourner rapidement un résultat, classAttributeIDByIdentifier récupère la liste de tous les attributs existants dans la base de données, et construit un tableau d’index :

    ...
    foreach ( $identifierArray as $identifierRow )
    {
        ...
        $combinedIdentifier = $classIdentifier . '/' . $attributeIdentifier;
        $identifierHash[$combinedIdentifier] = (int)$attributeID;
    }

On a donc un tableau de la forme

$identifier_hash = array( "folder/name" => 4,
                          "folder/short_description" => 119,
                          "folder/short_name" => 155,
                          "folder/description" => 156,
                          "folder/show_children" => 158,
                          "user_group/name" => 6,
                          ...

Pour renvoyer l’id, le reste est trés simple :

    $return = $identifierHash[$identifier];

Rien de bien sorcier, non ? Sauf que ! Le problème, c’est que le tableau d’index est mis en cache, dans le fichier var/plain/cache/classattributeidentifiers_nom_de_la_base.php

Mon problème, c’était que l’attribut que je voulais filtrer n’était pas dans le cache. Après quelques recherches, j’ai compris pourquoi :

ls -l var/plain/cache/classattributeidentifiers_nom_de_la_base.php  
-rw-rw-rw-  1 root root 25750 2008-05-26 16:46 var/plain/cache/classattributeidentifiers_nom_de_la_classe.php

Le propriétaire du fichier est root ! Du coup, lorsque j’ai modifié mes classes de contenu dans la backoffice ez Publish, ce cache n’a pas été mis à jour. Comme il s’agit d’un cache interne, il n’a pas non plus été supprimé par la commande

php bin/cache/ezcache.php --clear-all

Résultat : un cache obsolète, une après-midi perdue. Moralité : même quand on supprime les caches, il reste encore des problèmes de cache.