Ne polluez pas le tableau des options de WordPress
Je suis un adepte des cycles de sortie courts. Selon le projet, la durée du cycle variera, mais pour de nombreux types de projets sur lesquels je travaille, je vise à avoir des cycles de publication de deux semaines.
De plus, il y a des moments où je travaille sur un projet pour quelqu’un où des variables environnementales sont nécessaires pour que le code sache s’il est en cours de développement, de mise en scène ou de production.
Et cela peut être réalisé de manière différente selon les besoins du projet. Parfois, un fichier de configuration fonctionnera, parfois des variables de chaîne de requête peuvent fonctionner, et d’autres fois, je pense qu’il est raisonnable de stocker un paramètre dans la base de données.
Mais, en ce qui concerne WordPress, je pense que nous raccourcissons les meilleures décisions de conception et jetons des informations dans la base de données, en particulier la table des options, lorsque les alternatives peuvent être mieux adaptées.
Le tableau des options de WordPress
Je veux être clair: je ne pense pas que le tableau des options doive servir de dépotoir pour les réglages quand on n’a nulle part ailleurs où mettre les informations. Et c’est l’essentiel de tout ce post.
Au lieu de cela, vous pouvez utiliser :
- un fichier de configuration,
- données de session (le cas échéant),
- une table de base de données personnalisée,
- ou autre chose.
Alors pourquoi voyons-nous cela se produire si fréquemment? Ce n’est pas qu’il n’y a pas de moments où il est logique de l’utiliser. Je pense juste qu’on en abuse. Mais il y a des raisons pour lesquelles.
Le WordPress Codex définit des options comme ceci :
Les options sont des éléments de données que WordPress utilise pour stocker diverses préférences et paramètres de configuration.
Avec une définition comme celle-ci, il est facile de comprendre pourquoi tant de gens l’utiliseront comme un endroit pour stocker tout ce qui ne rentre nulle part ailleurs.
Au lieu de cela, je pense qu’il est important de poser la question:
Pour quel type de stockage [ces données] sont-elles les plus pertinentes ?
Autrement dit, s’il est lié à des publications, pourquoi ne pas le stocker dans la méta-table des publications ? Idem pour les métadonnées de terme ou les commentaires ou toute autre chose.
Le point est ceci:
Trouvez l’endroit le plus logique pour stocker les données et placez-les là.
En d’autres termes, ne jetez pas de données dans le tableau des options de WordPress car elles ne rentrent nulle part ailleurs. Cela le pollue. Au lieu de cela, trouvez – ou créez – l’endroit le plus logique pour cela. C’est probablement la preuve d’une odeur de code et ce serait une bonne raison de réévaluer l’architecture de votre code et la manière dont les informations sont représentées.
Mais à quoi cela pourrait-il ressembler? Autrement dit, comment prendrions-nous un morceau de code donné et changerions-nous la façon dont il est représenté dans la base de données.
Malheureusement, il est difficile de fournir une solution prescriptive à cette question lorsqu’il existe autant de variantes de l’implémentation d’un problème. Alors peut-être qu’une simple directive s’impose :
Si les données sont liées aux types de données (ou tables) préexistants, utilisez-les ; sinon, envisagez un fichier de configuration ou une table de base de données personnalisée correspondant à votre travail.
Je suis sûr qu’il existe d’autres facteurs directeurs, mais c’est un meilleur point de départ que de simplement polluer le tableau des options de WordPress.