Pathauto, ou comment se faire bananer par les traductions...

C'est pour cette raison que pathauto dispose de plusieurs mode de mise à jour, dont un seul concrètement utilisable, consistant à ajouter le nouvel alias sans détruire les anciens. Cette approche nous permet donc de modifier les titres en toute liberté sans crainte de générer du 404 à la chaîne...

Le hic c'est que cela ne marche pas... En effet, lorsque pour l'article sur CodeMirror un contributeur m'a fait remarquer que j'avais écrit "codeminor" dans le titre, la correction a eu pour effet de perdre l'ancienne URL malgré la sélection du mode "qui va bien". Une vérification dans la base de donnée permet de valider cela :

gastonselect dst from url_alias where src='node/367';

pid | src | dst | language

------+----------+------------------------------------------------+----------

1376 | node/367 | articles/codemirror-lediteur-de-contenu-ultime | fr

Vérification des URLS pour un article

Pas cool... Et j'ai mis pas mal de temps avant de me rendre compte que le soucis ne venait en réalité pas de pathauto en lui-même, mais de sa traduction française. Plutôt qu'un long discours, je vais simplement supprimer toute traduction sur pathauto :

gastondelete from locales_target where lid in (select lid from locales_source where location like '%pathauto%');

Vérification des URLS pour un article

Notez qu'il faut impérativement vider les caches après cette suppression car les traductions de longueur inférieur à 75 caractères y sont stockées. Ceci fait, retour dans l'administration de pathauto et là surprise... comme vous le voyez sur la copie d'écran. Je tiens à préciser que le mode qui nous intéresse est à la même position dans les deux cas... Ainsi croyant sélectionner l'ajout d'alias, j'avais en réalité sélectionné pûrement et simplement son remplacement !

Une fois le bon réglage rétabli, le titre de l'article remodifié, une petite vérification en base pour vérifier que cette fois cela fonctionne :

gastonselect dst from url_alias where src='node/367';

pid | src | dst | language

------+----------+------------------------------------------------+----------

1376 | node/367 | articles/codeminor-lediteur-de-contenu-ultime | fr

1401 | node/367 | articles/codemirror-lediteur-de-contenu-ultime | fr

Vérification des URLS pour un article

C'est bon, cette fois j'ai bien deux alias pour le même article, celui de PID le plus élevé étant celui qui sera utilisé par défaut.

Conclusion

Que dire en conclusion ? Ce n'est au fond qu'un bug même si cette fois il s'agit de la traduction et que les effets peuvent être graves pour un site à forte enthropie de contenus.

Mais tout ceci me fait penser à une reflexion plus ancienne sur la notion même de paramétrage pour Drupal, et sur notre douloureuse dépendance vis à vis d'interfaces plus ou moins complexes, plus ou moins bien gaulées, avec cette très agaçante impossibilité de pouvoir visualiser, dupliquer, et déployer la configuration d'un site Drupal (et donc de ses modules)...

Peut-être est-ce mon background d'unixien qui parle ici, mais pour synthétiser, je trouve très problématique deux points en particuliers :

1. Qu'il n'y ait aucune séparation entre les réglages d'un module, les contenus gérés par un module et les données temporaire qu'il est amené à manipuler.
2. Que la configuration des modules ne soient pas de simple fichiers textes facilement manimulable, auditable, déployables, capitalisables, etc.

En somme, je pense qu'il est grand temps pour Drupal d'imposer à tous les modules une véritable API de serialisation lui permettant de lire et d'écrire ses réglages sans qu'il lui soit possible d'y déroger. C'est d'ailleurs assez choquant pour qui pratique l'architecture logiciel de laisser une telle liberté à des greffons. Maintenant, je comprend qu'il n'est pas facile de rattraper les dégâts avec plus de 3000 modules existants... Mais tant qu'à tout casser à chaque version majeur de Drupal (ce qui est aussi un vrai problème !) et ainsi obliger une quasi ré-écriture des modules, rajouter cela n'est pas la mer à boire.

De cette manière, la table variable cesserait peut-être d'être un véritable dépotoir et Drupal pourrait supprimer les réglages d'une module désinstallé. Cela implique aussi de fournir aux modules un moyen propre de gérer les données temporaires (ex. date de dernier CRON) ce qui éviterais de coller cela dans variable, une fois encore, qui fini par ressemble à la tristement célèbre registry de Windows.

Une piste de solution serait de fonctionner comme le très bien conçu gconf de Gnome. L'idée étant que toutes les applications fournissent le schema XSD de leurs réglages, et que ces réglages sont dés lors stockés au format XML. Ce ne serait le bonheur ? Vérifier les réglages d'un module d'un simple coup d'oeil ? Créer un nouveau site en répliquant les paramétrages éprouvés et testés d'un autre site par simple copier-coller ? Pouvoir stoquer toute la configuration de Drupal dans un dépôt de version comme GIT ou SVN et pouvoir déployer un site avec seulement des fichiers texte ? Et ce même sur un site existant, qui contient déjà du contenu, sans risque de perdre un article ? Un vrai déploiement quoi ! Pas une usine à gaz, à la features...

Je ne sais pas pour vous, mais moi ça me fait rêver...