Hay una frase que me reconforta cada vez que la digo en voz alta: no es un bug, es una feature. El problema es que, en WordPress, muchas veces el bug somos nosotros. Llegamos con nuestras prisas, nuestro acceso root y nuestra confianza de que sabemos cómo funciona una web, y le damos la vuelta a un sistema que, en realidad, ya tenía un camino marcado. Un camino que, si lo respetas, te devuelve la cordura los lunes por la mañana.
Hace unos meses un cliente me escribió en pánico. Había cambiado de theme porque le gustaba más el azul del nuevo. De pronto, desaparecieron los custom post types, dejó de funcionar un shortcode crítico y el formulario de contacto devolvía un 404 que olía a tragedia. Abrí el código y allí estaba: tres años de funcionalidad empotrada en el functions.php del theme anterior. No era un theme. Era un cajón de sastre con CSS.
Ese día aprendí (o más bien reafirmé) que el functions.php del theme es una trampa. Es tentador. Está ahí, te mira, te dice «échame ese snippet de Stack Overflow». Pero los themes cambian. Se actualizan, se reemplazan, se borran. Si el código es importante para que el sitio funcione, no es del theme. Es del sitio. Y lo que es del sitio va en un plugin propio. O mejor, en un Must-Use plugin, esos que viven en mu-plugins y que no se desactivan ni por accidente. Es la diferencia entre pintar un mural en una pared de alquiler y colgar un cuadro con clavo.
Pero vayamos al origen. Si hay algo que define The WordPress Way, es la idea de que WordPress es un sistema, no una carpeta de archivos. Y los sistemas tienen reglas de tránsito.
Tomemos el FTP. Para mí, el FTP debería tener una etiqueta de advertencia como las cajetillas de tabaco. Subir un plugin descomprimido por SFTP a mano es técnicamente posible, pero es saltarse la aduana. Cuando subes por el instalador de WordPress (ese que parece que solo usan los novatos), el sistema valida cabeceras, comprueba compatibilidades, ejecuta hooks de activación y limpia archivos huérfanos si reemplazas una versión. Si lo haces por FTP, todo eso se salta. Es como meter mercancía por la frontera de montaña en lugar de por el puesto de control. Llega, sí, pero nadie ha revisado nada. La única excepción legítima es wp-config.php, porque ahí es donde tú le dices a WordPress quién es, y eso no puede hacerlo él solo.
Luego está el correo. Ese campo que muchos dejan con el email de prueba del instalador. La dirección de administrador de WordPress no es un detalle ornamental. Es la línea de emergencia cuando un plugin falla, cuando hay un intento de acceso sospechoso, cuando se completa una actualización crítica o cuando un usuario pide restablecer su contraseña. Si ese correo va a una bandeja que no lees, es como tener un extintor en casa pero haberle puesto un candado. Revisarlo no cuesta nada. Ignorarlo puede costarte un lunes entero.
Y la hora. Este es uno de esos errores que se ven incluso en sitios profesionales. Poner UTC+1 en los ajustes generales es como decirle a un reloj «suma una hora» en lugar de decirle «estamos en Madrid». Cuando llega el cambio de hora, UTC+1 no se entera. Se queda ahí, quieto, haciendo que tus publicaciones programadas, tus logs y tus backups aparezcan con una hora que no es. Usa Europe/Madrid. O America/Bogotá. O la zona que te corresponda. WordPress sabe leer el calendario mundial. No hace falta que se lo cuentes tú a mano.
La base de datos, por supuesto, es territorio sagrado. Entrar a phpMyAdmin para cambiar una URL o corregir un usuario es como abrir el motor de un coche con un destornillador de cocina. Funciona hasta que no funciona. Rompes la serialización de los arrays, invalidas cachés y dejas la metainformación hecha un puzzle. Para eso está WP-CLI. Para eso está $wpdb. Para eso están las API. Un wp search-replace respeta la estructura interna. Un UPDATE a mano la apuesta.
Lo mismo aplica al cron. Dejar que wp-cron.php se dispare cada vez que pasa un visitante es pedirle a la lotería que organice tu agenda. A veces funciona, a veces no, y a veces genera una tormenta de peticiones que ni siquiera ves. Desactiva el cron pseudo-síncrono y delega en el cron real del servidor. Que WordPress programe las tareas (eso es su trabajo), pero que un reloj fiable las ejecute.
Y hablando de archivos: los medios deben entrar por la puerta grande. La Biblioteca de Medios no es un mero almacén visual. Es un registro. Genera thumbnails, extrae metadatos, organiza por fechas, respeta los permisos y permite que todo el ecosistema sepa que ese archivo existe. Subir por FTP a wp-content/uploads deja un fantasma en el servidor: visible para el navegador, invisible para WordPress. Es como tener un inquilino que no figura en el contrato.
En cuanto a la seguridad, el camino de WordPress es aburrido y efectivo: mantener el core actualizado, usar contraseñas robustas, limitar los roles al mínimo necesario y no tocar lo que no se debe tocar. No hace falta un plugin que reescriba el core, añada tablas propias y te venda un escáner con hashes de hace dos años. La seguridad es una arquitectura, no una pulsera antimosquitos.
Al final, The WordPress Way no es una secta ni un manual de estilo. Es la constatación de que este CMS lleva veinte años aprendiendo a gestionarse a sí mismo. Tiene API para casi todo, hooks para el resto, y una comunidad que ha resuelto problemas que ni siquiera sabías que existían. Nuestro trabajo como quienes lo mantenemos no es demostrar que sabemos más que el sistema. Es dejar que el sistema funcione como fue diseñado.
Respetar el camino no te hace menos técnico. Te hace la persona a la que no le llaman un domingo a las ocho de la mañana porque se ha roto algo que nunca debió romperse.
Y eso, en esta profesión, es el verdadero lujo.
Deja una respuesta