Plugins WordPress: quelle stratégie pour les données?

WordPress est une plateforme très populaire, qui dispose d’une librairie d’extensions assez considérable (près de 4000 plugins). Ce choix est un avantage, bien sur, mais également un inconvénient: pour une fonction donnée, nous pouvons avoir plusieurs dizaines de plugins. Comment choisir?
L’un de mes critères est l’utilisation ou non des tables standards de WordPress: Pour conserver une certaine pérennité, je préfère que les plugins se basent sur la structure existante et ne créent pas de tables supplémentaires.
En développant mes propres plugins, j’ai appliqué le même principe. Mais je me pose de plus en plus de question sur la pertinence de cette stratégie. Est-elle réellement la bonne?

Lorsque l’on développe un plugin, nous avons généralement trois types de données à manipuler:

  1. les options,
  2. les objets de WordPress (articles, pages, catégories, tags, …),
  3. de nouveaux objets, ou de nouveaux attributs des objets existants.

Les deux premiers cas ne posent aucun problème: il suffit de s’appuyer sur la base de données et les fonctions de WordPress. Pour le troisième cas, nous avons deux stratégies distinctes:

  • Utiliser les tables existantes, ce que j’appelle la solution interne,
  • Créer de nouvelles tables, que j’appelle solution externe.

J’exclus la solution qui consisterait à modifier les tables existantes, les dangers étant évidents: les mises à jour de WordPress lui-même risquent de planter, ou de bloquer systématiquement les plugins concernés par les modifications.
Je vais donc comparer les méthodes interne et externe selon deux points de vue: celui des utilisateurs, puis celui des développeurs.

Le point de vue des utilisateurs

Initialement, la première solution (solution interne) me paraissait la plus adéquate, une raison principale, la pérennité: En effet, WordPress est plus perrein (me semble-t-il) que ses plugins. Ces derniers dépendent de la disponibilité de leur(s) auteur(s). Nous avons donc beaucoup de plugins qui ne sont plus maintenus, ou plus adaptés aux dernières versions de WordPress. Le cas récent de All in one SEO pack est assez significatif: si ce plugin n’était pas connu, son développement serait arrêté aujourd’hui. Dans ce contexte, il est donc important d’être le plus indépendant possible des plugins, et donc de choisir des plugins qui ne gèrent pas leurs propres données.

Imaginez qu’un plugin comme NextGen Gallery ne soit plus maintenu. A la version suivante de WordPress, il y a fort à parier que ce plugin ne fonctionnera plus. NextGen est tellement complexe, qu’il faudrait des semaines à un généreux développeur pour trouver les éléments défectueux. Et si personne ne veut reprendre le flambeaux, les utilisateurs se retrouveraient donc avec des mois, voir des années d’articles, sans galerie.

Mais la solution interne a également des inconvénients: que se passe-t-il lorsque l’on désinstalle le plugin? Je vois deux possibilités:

  • Les informations générées par le plugin ne sont simplement plus utilisées. La base de données va donc contenir des données dormantes, potentiellement gênantes vis-à-vis des performances,
  • Ces informations peuvent devenir visibles (si elles ne l’étaient pas avec le plugin), et rendre ainsi illisible le blog.

Le point de vue du développeur

Si l’on se place maintenant du côté du développeur, nous pouvons avancer deux arguments en faveur d’une solution externe: tout stocker dans les tables de WordPress peut entraîner des problèmes de performances, et que se passe-t-il si cette base évolue « brutalement ».

Le premier argument, celui des performances, m’est venu pendant le développement d’un plugin que je publierai certainement dans les semaines à venir. Ce plugin se base sur les « champs personnalisés ». En vérifiant que tout se passait bien au niveau de la base, j’ai pu constaté combien la table wp_postmeta pouvait être « encombrée » d’objets divers comme les pièces jointes, les champs personnalisés, ainsi que d’autres éléments propres au fonctionnement de WordPress. Globalement, si l’on emploi 1 ou 2 champs personnalisés et une moyenne de 3 pièces jointes, par article, nous obtiendrons assez vite, une taille de table qui, en nombre d’enregistrements, fera 6 à 8 fois la taille de la table des articles elle-même (wp_posts).

Globalement, dans la base de WordPress, un développeur n’a pas énormément de possibilités de stockage: nous avons la table wp_postmeta, dont les enregistrements sont liés uniquement aux articles, et nous avons les tables wp_terms, wp_terms_taxonomy et wp_terms_relationships, qui donne plus de souplesse dans
la création d’objets, qui restent malgré tout principalement liés aux articles. Les problèmes potentiels soulevés précédemment pour la table wp_postmeta, sont les mêmes pour les tables wp_term ....

Utiliser des tables spécifiques (solution externe) permettrait de limiter les impacts sur les performances, en optimisant la base par rapport à l’utilisation que l’on veut en faire.

Le second argument en faveur d’une solution externe, est paradoxalement la pérennité: Utiliser des tables spécifiques permet d’être indépendant des changements de WordPress. En théorie cette base évolue par étape, et il est recommandé de ne requêter la base qu’à travers des fonctions dédiées. De cette façon les évolutions de base sont transparentes.
Dans les faits, rien n’exclut des modifications brutales comme celles intervenues entre les versions 1.5 et 2.0, et dans beaucoup de cas les fonctions fournies par WordPress ne sont pas suffisantes et nous obligent à accéder directement à la base.

Interne ou Externe?

Cette petite étude montre que chaque méthode a ses avantages et ses inconvénients. Je suis maintenant moins radicale vis-à-vis de la méthode interne que je ne l’étais auparavant.

Mais comment choisir? Interne / externe, Externe / interne?

Pour répondre à cette question, je pense qu’il faut se placer d’un point de vue de l’utilisateur, et étudier l’impact du plugin sur l’utilisation du blog:

  • Le blog fonctionne-t-il correctement après désinstallation,
  • Les informations traitées par le plugin sont-elles toujours accessibles, affichées lisiblement?
  • Ces informations polluent-elles l’affichage du blog?

La bonne solution est celle dont l’impact est le plus faible.

Si l’on prend le cas de NextGen Gallery, une désinstallation du plugin ne conduit pas à un arrêt du blog, mais tous les articles n’afficheront que [ nggallery ...] à la place des images attendues. L’utilisateur a donc perdu toutes ses galeries.

Pour limiter l’impact de son plugin, l’auteur aurait pu:

  • Stocker une partie des informations dans les tables standards wp_postmeta dans notre cas, et le reste des informations dans des tables dédiées, de façon a ce que le shortcode [ gallery] standard de WordPress continue de fonctionner après désinstallation,
  • Ou fournir le nécessaire au bon fonctionnement des shortcodes NGG, de façon à permettre une désinstallation sans conséquence sur la partie publique du blog. Tous les articles existants fonctionneraient comme avant, l’utilisateur étant libre d’installer une autre solution pour les futures articles.

Le cas de ce plugin, et les solutions proposées ne sont que des exemples / illustrations.

Si l’on prend le cas des plugins permettant le multilinguisme, le raisonnement est inverse. Un plugin de la famille de Polyglot, qui s’intègre complètement à la base de WordPress, rend un blog complètement inutilisable après désinstallation. Les visiteurs verront toutes les traductions des articles sur la même page. Inversement, la désinstallation de plugins comme QTranslate ou ZDMultilang, qui utilise des tables externes, n’aura pour conséquence que la disparition des traductions. Dans le cas du second plugin ces traductions sont accessibles facilement dans une table unique (à condition que l’auteur ait les compétences pour aller les chercher).

Cette démarche qui tend à permettre, voir à faciliter la désinstallation du plugin ou la migration vers un autre, est à l’opposé d’une démarche « marketing » standard. Elle correspond plus ou moins à ma conception du logiciel « libre ».

Conclusion

A la question Faut-il ou ne faut-il pas créer des tables supplémentaires pour mon plugin?, je n’ai pas de réponse absolue. Mais j’ai maintenant un moyen, une approche pour répondre au cas par cas: la méthode choisie doit être celle qui minimisera les conséquences d’une désinstallation du plugin développé.

2 thoughts on “Plugins WordPress: quelle stratégie pour les données?”

  1. I think there is another component to the argument, or limitation in your thinking.

    Plugins for blogging purposes would likely lean more toward using existing tables, however if the plugin needs to store data that’s not associated with a post (think of a store plugin for example) much of it’s data would need to be stored in external/custom tables.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.