No contamine la tabla de opciones de WordPress
Soy fanático de los ciclos cortos de liberación. Dependiendo del proyecto, la duración del ciclo variará, pero para muchos de los tipos de proyectos en los que trabajo, pretendo tener ciclos de publicación de dos semanas.
Además, hay ocasiones en las que estoy trabajando en un proyecto para alguien en el que las variables ambientales son necesarias para que el código sepa si se está ejecutando en desarrollo, ensayo o producción.
Y esto se puede lograr de diferente manera dependiendo de las necesidades del proyecto. A veces, un archivo de configuración funcionará, a veces las variables de cadena de consulta pueden funcionar y otras veces creo que es razonable almacenar una configuración en la base de datos.
Pero, en lo que respecta a WordPress, creo que acortamos mejores decisiones de diseño y arrojamos información en la base de datos, específicamente la tabla de opciones, cuando las alternativas pueden ser más adecuadas.
La tabla de opciones de WordPress
Quiero ser claro: no creo que la tabla de opciones deba servir como un basurero para la configuración cuando no tienes otro lugar donde poner información. Y esa es la esencia de todo este post.
En su lugar, puede utilizar:
- un archivo de configuración,
- datos de la sesión (cuando corresponda),
- una tabla de base de datos personalizada,
- o algo mas.
Entonces, ¿por qué vemos que esto sucede con tanta frecuencia? No es que no haya momentos en los que tenga sentido usarlo. Solo creo que abusamos de eso. Pero hay razones por las cuales.
El Codex de WordPress define opciones como esta:
Las opciones son piezas de datos que WordPress utiliza para almacenar varias preferencias y ajustes de configuración.
Con una definición como esta, es fácil ver por qué tantos lo usarán como un lugar para almacenar cualquier cosa que no encaje en ningún otro lugar.
En cambio, creo que es importante hacer la pregunta:
¿Para qué tipo de almacenamiento son [estos datos] más relevantes?
Es decir, si está relacionado con publicaciones, ¿por qué no almacenarlo en la metatabla de publicaciones? Lo mismo para metadatos de términos o comentarios o cualquier otra cosa.
El punto es este:
Encuentre el lugar más lógico para almacenar los datos y colóquelos allí.
En otras palabras, no arroje datos en la tabla de opciones de WordPress porque no encaja en ningún otro lugar. Eso lo contamina. En su lugar, encuentre, o cree, el lugar más lógico para ello. Probablemente sea evidencia de un olor a código y sería una buena razón para volver a evaluar la arquitectura de su código y cómo se representa la información.
Pero, ¿cómo podría ser esto? Es decir, cómo tomaríamos un fragmento de código determinado y cambiaríamos la forma en que se representa en la base de datos.
Desafortunadamente, es difícil proporcionar una solución prescriptiva a esta pregunta cuando existen tantas variaciones en la implementación de un problema. Entonces, tal vez sea necesaria una guía simple:
Si los datos están relacionados con los tipos de datos (o tablas) preexistentes, utilícelos; de lo contrario, considere un archivo de configuración o una tabla de base de datos personalizada que se asigne a su trabajo.
Estoy seguro de que hay otros factores rectores, pero este es un mejor lugar para comenzar que simplemente contaminar la tabla de opciones de WordPress.