Bug Flattr et WordPress
Problème
Flattr était en carafe cette nuit… et donc mon blog WordPress ne marchait plus !
Une fois trouvée l’origine du problème, il était temps d’y remédier : j’allais donc logiquement désactiver le plugin Flattr de mon blog. Oui mais voilà, pour le désactiver encore fallait-il que j’ai accès à… mon blog ! puisque l’administration se fait par une interface web intégrée.
Ne pouvant donc appliquer cette méthode, je me connectais à mon serveur par SSH, à la recherche de l’option du fichier de configuration me permettant de désactiver un plugin. Option introuvable puisque n’existant pas, l’état d’activité d’un plugin étant en fait stocké dans la base de données MySQL du blog.
Solution
Il existe donc deux manières de s’en sortir :
- Le hack rapide et efficace : supprimer le répertoire “flattr” du répertoire “wp-content/plugins” (ou plutôt le copier ailleurs).
- La méthode canonique : faire les requêtes adéquates dans la base de données du blog, ce qui est beaucoup plus compliqué, mais aussi beaucoup plus propre.
Bilan d’ingénierie logicielle
Le plugin de Flattr pour WordPress est merdique, car il n’est pas capable de vérifier ce qu’il faut pour ne pas bloquer un blog en cas de problème sur les serveurs de Flattr. Ceci n’est pas si grave, dans le sens où ce n’est qu’un plugin, et où les modifications nécessaires sont sûrement faciles à faire.
WordPress est mal conçu, car il ne permet pas de configurer simplement une chose aussi fondamentale que l’activation ou la désactivation d’un plugin. C’est beaucoup plus grave car WordPress est actuellement une plateforme structurante du web et l’un des plus importants logiciels libres.
La première chose à faire est d’arrêter de stocker tout et n’importe quoi dans des bases de données. Les base de données sont là pour stocker les contenus, et les fichiers de configurations en texte pur, quel qu’en soit le format, sont le seul endroit légitime où stocker les données de configuration.
C’est le concept même d’Unix, le texte comme garant de simplicité et d’interopérabilité. La mode récente d’utiliser SQLite pour la configuration d’applications est donc bien une hérésie. Pour WordPress cela signifie qu’il faudrait se réarchitecturer proprement sur ce point, ce qui est techniquement facile, mais pose des problèmes de compatibilité énormes.
Une autre solution intéressante pourrait être d’avoir une interface de configuration de secours très minimaliste, moins intégrée dans le reste du blog, mais beaucoup plus résistante à toutes sortes de bugs collatéraux !
