El tema de WordPress rompió tu sitio: cambia a un tema predeterminado sin wp-admin

Qué está pasando realmente cuando un tema rompe WordPress

Cuando un tema rompe un sitio WordPress, rara vez es algo místico. Suele ser una falla operativa directa: PHP no puede ejecutar cierto código del que depende el tema, WordPress no puede cargar la plantilla activa, o algo en la ruta de la petición (cache, CDN, PHP-FPM, base de datos) está ocultando el error real.

Los mecanismos comunes

• Error fatal en PHP del tema (a menudo functions.php o un framework incluido): PHP se detiene y WordPress no puede renderizar ni el frontend ni el admin.
• Dependencias faltantes: el tema espera un plugin, una extensión de PHP o una característica de una versión específica de PHP.
• Desajuste en el sistema de archivos: carpeta del tema renombrada, subida parcial, permisos incorrectos o un despliegue que dejó parte antiguo/parte nuevo.
• La plantilla apunta a un tema que no está: WordPress guarda la selección activa en la base de datos; si apunta a algo inexistente, hay caos.
• La caché te miente: la caché de página sirve la versión buena anterior mientras el admin sigue muerto—o al revés, que es cómo recibes una llamada a las 02:13.

El objetivo aquí no es “arreglar el tema”. El objetivo es “restaurar el servicio rápidamente”. Una vez que estés en línea con un tema predeterminado, puedes depurar el tema problemático sin tener un incidente de producción respirándote en la nuca.

Una cita para tener a mano, especialmente cuando te tienta juguetear en producción: “Idea parafraseada” — Gene Kranz: duro y competente; mantén la disciplina bajo presión.

Broma #1: Un tema roto es como un mal corte de pelo—puedes fingir que está bien, pero tus clientes lo notarán de todas formas.

Guía rápida de diagnóstico (primeras/segundas/terceras comprobaciones)

Si tienes cinco minutos antes de que alguien escale, no divagues. Ejecuta este plan. Estás intentando responder una pregunta: ¿Es esto una falla de PHP a nivel de tema, o un cuello de botella de infraestructura que se disfraza de eso?

Primero: confirma que realmente es el tema y no la plataforma

1. Revisa los registros de error del servidor web para fatales de PHP (Nginx/Apache + PHP-FPM). Si ves un archivo del tema en la traza de pila, habrás terminado de diagnosticar.
2. Comprueba el estado HTTP y el cuerpo de la respuesta. 500 con “error crítico” o salida en blanco sugiere un fatal de PHP. 502/504 sugiere fallo upstream (PHP-FPM) o timeout, lo cual aún puede haber sido causado por el tema.
3. Comprueba el estado de PHP-FPM / slowlog. Un tema puede provocar consumo descontrolado de CPU o recursión hasta que llegues a timeouts.

Segundo: verifica la selección de tema activo

1. Consulta wp_options por template y stylesheet. Si apuntan a un directorio de tema que no existe, corrígelo primero.
2. Lista los temas instalados con WP-CLI (si está disponible). Si WP-CLI no puede bootstrapear, recurre a editar la base de datos o renombrar en el sistema de archivos.

Tercero: restaura el servicio con el método menos invasivo

1. Activar un tema predeterminado con WP-CLI (rápido, limpio, reversible).
2. Editar en la BD las dos opciones de tema (funciona incluso cuando PHP está demasiado roto para WP-CLI).
3. Renombrar en el sistema de archivos el tema roto (tosco, pero obliga a WordPress a caer en fallback).

Regla de decisión: si puedes ejecutar WP-CLI sin que falle, úsalo. Si el bootstrap de WordPress explota, ve directo a la base de datos. Si no tienes acceso a la base de datos, renombra los archivos del tema. No pases 40 minutos “intentando una cosa más” mientras el sitio está caído.

Datos y contexto interesantes (sí, los temas tienen historia)

• La elección del tema vive en la base de datos: WordPress la guarda en las opciones llamadas template y stylesheet. Por eso una carpeta faltante puede dejar el sitio inservible.
• Los temas predeterminados “Twenty *” son más que decoración: son una base compatibilidad y recuperación soportada. Son el equivalente de WordPress a una rueda de repuesto.
• WordPress introdujo una función de “protección contra errores fatales” que a veces puede desactivar un plugin/tema roto y enviar un correo al administrador. Es útil, pero no garantizado—especialmente si el correo está roto o el error ocurre demasiado pronto.
• El mecanismo de tema hijo es solo punteros de directorio: el “padre” se referencia dentro de style.css del tema hijo. Un padre faltante puede tumbar todo el tema.
• Los ecosistemas tempranos de temas fomentaban empaquetarlo todo (frameworks personalizados, maquetadores). Por eso las fallas modernas suelen parecer explosiones de dependencias.
• WP-CLI existe porque operar WordPress vía UI no escala. Ha sido básico para operaciones tipo SRE con WordPress durante años.
• Muchos hosts gestionados deshabilitan ediciones directas de archivos en el admin por seguridad. La ventaja: menos heridas autoinfligidas. La desventaja: necesitas habilidades SSH/CLI cuando algo falla.
• Las capas de caché pueden “preservar” un despliegue roto durante minutos u horas. Esto hace los incidentes confusos: algunos usuarios ven sitio sano, otros golpean el origen roto.

Antes de tocar nada: accesos, copias y líneas de seguridad

Cambiar de tema suena inofensivo hasta que te das cuenta de que puede disparar reseteos de widgets, cambios de menús, desajustes de ajustes del personalizador y regresiones de diseño. Aun así lo haces. Porque el tiempo de actividad gana a la estética. Pero lo haces con líneas de seguridad.

Qué necesitas

• Acceso SSH al servidor o contenedor que ejecuta WordPress, o al menos al shell del hosting compartido.
• Acceso a la base de datos (credenciales MySQL/MariaDB desde wp-config.php o variables de entorno).
• Un tema predeterminado conocido y bueno instalado (p. ej., twentytwentyfour, twentytwentythree). Si no está instalado y el admin está muerto, puede que necesites subirlo manualmente.
• Permisos suficientes para renombrar directorios en wp-content/themes o para ejecutar WP-CLI.

Líneas de seguridad que agradecerás

• Snapshot/copia de seguridad de la base de datos y de wp-content antes de cambios. Si no puedes hacer snapshot, al menos vuelca los dos valores de opción antes de editarlos.
• Mentalidad de solo lectura primero: confirma qué está activo, qué existe en disco, qué errores se lanzan. Luego cambia una cosa.
• Registra lo que hiciste (nota de ticket, actualización en chat o un archivo de texto local). El tú del futuro cuenta como parte interesada.

Camino A: Récupéralo con WP-CLI (mejor caso)

WP-CLI es la forma más limpia de cambiar el tema activo porque actualiza las opciones correctas y puede validar qué está instalado. La pega: WP-CLI arranca WordPress. Si el error fatal del tema ocurre durante el bootstrap, WP-CLI puede fallar también. Pruébalo igual; si falla, no te obstines—cambia de método.

Cómo se ve el “éxito”

• Puedes ejecutar wp theme list sin error fatal.
• Activaste un tema predeterminado y el sitio vuelve (aunque sea feo).
• Confirmas que tanto el frontend como /wp-admin/ cargan.

Camino B: Récupéralo editando la base de datos (phpMyAdmin o CLI)

Si WordPress no puede ejecutar suficiente PHP para que WP-CLI corra, la base de datos es tu plano de control. WordPress lee el nombre del tema activo desde wp_options (o un prefijo distinto) y luego carga el directorio correspondiente bajo wp-content/themes.

En la práctica, cambias dos opciones:

• template — el nombre del directorio del tema padre
• stylesheet — el nombre del directorio del tema activo (tema hijo si se usa)

Configura ambas a un nombre de directorio de tema predeterminado como twentytwentyfour. Si no estás seguro de lo que está instalado, lista los directorios en disco primero.

Camino C: Récupéralo moviendo archivos del tema (último recurso pero efectivo)

Si no puedes acceder a la base de datos rápidamente (o faltan credenciales en el calor del momento), puedes obligar a WordPress a dejar de cargar el tema roto renombrando su directorio. Cuando WordPress no encuentra la carpeta del tema activo, normalmente cae en otro tema instalado.

Esto no es elegante. Es efectivo. Las operaciones están llenas de estas verdades incómodas.

Particularidades de Multisite y hosting gestionado

Multisite: temas habilitados en red vs temas activados por sitio

En multisite, los temas se “habilitan” a nivel de red, pero los sitios individuales eligen qué tema habilitado usar. El tema activo para cada sitio se guarda en la tabla de opciones de ese sitio (p. ej., wp_2_options para el sitio con ID 2) a menos que tengas un mapeo de tablas inusual.

Regla de decisión: si solo un sub-sitio está roto, estás editando las opciones del blog ID afectado, no del sitio principal. Si toda la red está rota, empieza por las opciones del sitio principal y confirma si hay un MU-plugin o una personalización a nivel de red involucrada.

Hosting gestionado: shells limitados y caché agresiva

Algunas plataformas te dan WP-CLI pero no un CLI de MySQL crudo. Otras te dan phpMyAdmin pero no SSH. Algunas están detrás de capas de caché que ignoran tus cambios hasta que purgas. Tu método depende de lo disponible. No seas sentimental con las herramientas.

Tareas prácticas (12+): comandos, salidas y qué decides después

A continuación están las tareas que realmente ejecuto en incidentes de producción. Cada una incluye: un comando, qué significa una salida típica y la decisión que tomas después. No son “agradables de tener.” Son cómo dejas de adivinar.

Task 1: Confirma que estás en el host correcto y en el directorio adecuado

cr0x@server:~$ hostname -f; pwd; ls -la
wp01.prod.example.internal
/home/cr0x
total 32
drwxr-xr-x  4 cr0x cr0x 4096 Jan 12 09:10 .
drwxr-xr-x  3 root root 4096 Jan 10 18:22 ..
drwx------  2 cr0x cr0x 4096 Jan 12 09:10 .ssh
-rw-r--r--  1 cr0x cr0x  220 Jan 10 18:22 .bash_logout
-rw-r--r--  1 cr0x cr0x 3771 Jan 10 18:22 .bashrc
-rw-r--r--  1 cr0x cr0x  807 Jan 10 18:22 .profile

Qué significa: No estás operando por error en staging o en alguna VM olvidada.

Decisión: Si el host es incorrecto, para. Si es correcto, cd al docroot de WordPress y trabaja desde ahí.

Task 2: Encuentra rápidamente la raíz de WordPress (docroot)

cr0x@server:~$ sudo find /var/www -maxdepth 3 -name wp-config.php -print
/var/www/html/wp-config.php

Qué significa: Encontraste el config de WordPress. Ese directorio suele ser la raíz.

Decisión: cd /var/www/html y trabaja desde ahí.

Task 3: Verifica que las carpetas de tema activas existen en disco

cr0x@server:~$ cd /var/www/html && ls -1 wp-content/themes
broken-agency-theme
twentytwentythree
twentytwentyfour

Qué significa: Tienes al menos un tema predeterminado instalado. Bien—la recuperación no requerirá subidas.

Decisión: Si no existe un tema predeterminado, puede que necesites subir o instalar uno vía WP-CLI (si es posible) antes de cambiar.

Task 4: Comprueba la respuesta del sitio y el código de estado desde el origen

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Sat, 27 Dec 2025 10:42:18 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Qué significa: Es una falla en origen, no solo un fallo del CDN. 500 sugiere un fatal de PHP o error de la aplicación.

Decisión: Ve a los logs para encontrar el fatal y confirmar que está relacionado con el tema.

Task 5: Lee el log de errores del servidor web para encontrar la bala humeante

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 10:42:17 [error] 22140#22140: *1047 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19" while reading response header from upstream, client: 10.0.4.12, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Qué significa: El tema activo se está ejecutando antes de que WordPress esté completamente cargado o está haciendo algo fundamentalmente mal. La traza apunta al tema.

Decisión: Cambia a un tema predeterminado. No depures el tema mientras el sitio esté caído.

Task 6: Confirma que PHP-FPM está vivo (evita diagnosticar mal una caída de plataforma)

cr0x@server:~$ systemctl status php8.2-fpm --no-pager | sed -n '1,12p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:50:11 UTC; 52min ago
       Docs: man:php-fpm8.2(8)
   Main PID: 1183 (php-fpm8.2)
     Status: "Processes active: 2, idle: 6, Requests: 14321, slow: 0, Traffic: 0req/sec"

Qué significa: PHP-FPM está en ejecución. El 500 probablemente es a nivel de aplicación, no un backend muerto.

Decisión: Procede con el cambio de tema en lugar de reiniciar servicios a ciegas.

Task 7: Prueba el bootstrap de WP-CLI (chequeo rápido de salud)

cr0x@server:~$ cd /var/www/html && wp core version
Error: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-cli.php(134): require_once('...')
#4 /usr/local/bin/wp(4): include('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19

Qué significa: WP-CLI no puede ejecutarse porque el bootstrap de WordPress carga el tema roto lo suficientemente temprano como para provocar el fallo.

Decisión: Omite WP-CLI para el cambio. Usa edición de base de datos o renombrado en el sistema de archivos.

Task 8: Extrae credenciales de BD desde wp-config.php (sin filtrarlas en el historial)

cr0x@server:~$ cd /var/www/html && sudo sed -n "1,140p" wp-config.php | sed -n 's/.*DB_.*//p'

Qué significa: Intencionalmente no imprimiste secretos. Bien. Ahora extráelos con más cuidado.

Decisión: Usa un enfoque más seguro: lee el archivo localmente en un editor de confianza, o usa grep con alcance limitado y mantén la salida privada.

Task 9: Lee el prefijo de tabla para no editar la tabla equivocada

cr0x@server:~$ cd /var/www/html && grep -n "table_prefix" wp-config.php
78:$table_prefix = 'wp_';

Qué significa: Tu tabla de opciones probablemente es wp_options. Si es distinta, ajusta todas las consultas.

Decisión: Usa el nombre de tabla correcto. Adivinar es cómo “arreglas” nada y pierdes una hora.

Task 10: Consulta el tema activo actual desde la base de datos (solo lectura primero)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+----------------------+
| option_name | option_value         |
+-------------+----------------------+
| template    | broken-agency-theme  |
| stylesheet  | broken-agency-theme  |
+-------------+----------------------+

Qué significa: WordPress está configurado explícitamente para usar el tema roto.

Decisión: Cambia ambos valores a un nombre de carpeta de tema predeterminado conocido.

Task 11: Actualiza el tema activo a uno predeterminado (la solución real)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Qué significa: La base de datos ahora apunta a twentytwentyfour.

Decisión: Vuelve a probar el sitio desde el origen. Si sigue fallando, el tema no era el único problema.

Task 12: Vuelve a probar frontend y wp-admin desde el origen

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 27 Dec 2025 10:45:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Qué significa: El sitio está de vuelta. No has terminado, pero ya no estás en llamas.

Decisión: Revisa /wp-admin/. Luego purga cachés para que los usuarios dejen de ver errores obsoletos.

Task 13: Purga/limpia cachés comunes (ejemplo de caché de página del servidor)

cr0x@server:~$ sudo rm -rf /var/cache/nginx/*

Qué significa: Limpiaste la caché de Nginx si la usas. Tu entorno puede diferir.

Decisión: Si estás detrás de un proxy inverso o CDN, también purga allí usando las herramientas de la plataforma.

Task 14: Si debes usar renombrado en el sistema de archivos (sin acceso a BD)

cr0x@server:~$ cd /var/www/html/wp-content/themes && sudo mv broken-agency-theme broken-agency-theme.disabled

Qué significa: WordPress ya no puede cargar esa carpeta de tema.

Decisión: Recarga el sitio. Si vuelve, configura inmediatamente un tema predeterminado válido vía BD/WP-CLI para no depender del comportamiento implícito de fallback.

Task 15: Confirma qué tema cree WordPress que está activo (después de la recuperación)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Qué significa: Tienes una configuración explícita y estable.

Decisión: Ahora puedes depurar el tema roto offline o en staging.

Task 16: Activa el registro de depuración (brevemente) para capturar errores restantes

cr0x@server:~$ cd /var/www/html && sudo grep -n "WP_DEBUG" wp-config.php
91:define('WP_DEBUG', false);
92:define('WP_DEBUG_LOG', false);
93:define('WP_DEBUG_DISPLAY', false);

Qué significa: La depuración está apagada, lo cual es normal en producción.

Decisión: Si todavía ves problemas tras el cambio de tema, activa WP_DEBUG_LOG temporalmente y sigue wp-content/debug.log. No actives la visualización en producción.

Broma #2: Activar WP_DEBUG_DISPLAY en producción es una estrategia audaz—sobre todo para quienes disfrutan compartir trazas de pila con desconocidos.

Listas de verificación / plan paso a paso

Checklist de restauración de emergencia (objetivo: 5–15 minutos)

1. Confirma el síntoma: frontend caído, admin caído, códigos de estado.
2. Revisa los logs de error buscando un archivo de tema en la traza de pila.
3. Lista los temas instalados en disco; confirma que existe un predeterminado.
4. Intenta WP-CLI (wp theme list). Si funciona, activa el tema predeterminado vía WP-CLI.
5. Si WP-CLI falla, edita las opciones en la BD: establece template y stylesheet al directorio del tema predeterminado.
6. Vuelve a probar desde el origen con curl: espera 200.
7. Vuelve a probar wp-admin (o al menos la página de login).
8. Purga cachés que podrían seguir sirviendo errores.
9. Comunica el estado: “Servicio restaurado con tema de fallback; investigando la causa raíz.”

Estabilizar tras la restauración (objetivo: 30–90 minutos)

1. Identifica exactamente qué cambió (actualización de tema, actualización de PHP, plugin actualizado, artefacto de despliegue).
2. Captura la traza del error fatal y guárdala en el ticket del incidente.
3. Reproduce en staging usando la misma versión de PHP y conjunto de plugins.
4. Decide: arreglar el tema, revertir el tema o reemplazarlo.
5. Añade una comprobación previa al despliegue: ¿puede WordPress renderizar /wp-login.php y la página de inicio tras los cambios de tema?

Controles preventivos (aburridos, efectivos)

1. Mantén al menos un tema Twenty predeterminado instalado en todo momento.
2. Automatiza copias de seguridad de BD y verifica que la restauración funciona.
3. Usa un entorno de staging que coincida con la versión de PHP de producción.
4. Ejecuta comandos de salud de WP-CLI en CI/CD (o al menos en hosts de despliegue).
5. Registra cambios de tema y plugin como código: changelog, aprobaciones y plan de rollback.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: página en blanco (frontend y admin)

Causa raíz: Error fatal de PHP con display de errores apagado; el código del tema se cae temprano.

Solución: Revisa logs de Nginx/Apache + PHP-FPM. Cambia el tema vía BD o WP-CLI. Luego inspecciona el fatal en los logs.

2) Síntoma: “There has been a critical error on this website”

Causa raíz: Excepción no manejada/fatal; el modo de recuperación de WordPress puede no activarse o falla el envío de correo.

Solución: No esperes el correo de recuperación. Fuerza el tema predeterminado; luego verifica el correo y el modo de recuperación más tarde.

3) Síntoma: 502/504 desde el proxy, disponibilidad intermitente

Causa raíz: El tema provoca ejecución lenta (bucle infinito, consultas pesadas), agotando los workers de PHP-FPM.

Solución: Cambia a un tema predeterminado y observa cómo PHP-FPM se estabiliza. Luego perfila el tema en staging; considera el slowlog.

4) Síntoma: el frontend funciona pero /wp-admin/ está roto

Causa raíz: El admin carga rutas de código diferentes; el tema engancha en admin o carga assets rotos.

Solución: Aun así cambia el tema. Si el admin sigue roto, deshabilita MU-plugins o sospecha un conflicto de plugins, no solo del tema.

5) Síntoma: después de cambiar, el sitio carga pero el diseño está destrozado

Causa raíz: Widgets/ajustes del personalizador y shortcodes específicos del tema no se traducen al tema predeterminado.

Solución: Acéptalo temporalmente. Tu objetivo es restaurar el servicio. Programa un rollback controlado del tema o un arreglo.

6) Síntoma: actualizaste template/stylesheet pero nada cambió

Causa raíz: Prefijo de tabla incorrecto, base de datos equivocada, mismatch de blog ID en multisite, o caché de objetos sirviendo opciones obsoletas.

Solución: Confirma table_prefix, confirma el nombre de la BD y en multisite confirma wp_<blogid>_options. Vacía el caché de objetos si se usa.

7) Síntoma: el directorio del tema existe pero WordPress dice que falta

Causa raíz: Permisos/propiedad, diferencia de mayúsculas/minúsculas, o un artefacto de despliegue/symlink.

Solución: Revisa permisos y nombres reales de directorio. Normaliza mayúsculas y propiedad; asegúrate de que el usuario PHP pueda leer.

8) Síntoma: cambiar de tema provoca bucles de redirección inmediatos

Causa raíz: El tema o un plugin fuerza URLs canónicas o HTTPS incorrectamente; las cachés lo amplifican.

Solución: Verifica las opciones siteurl y home, revisa encabezados de proxy y purga caches. El cambio de tema es necesario pero puede no ser suficiente.

Tres micro-historias corporativas desde el frente

Incidente causado por una suposición errónea: “Es solo un tema, ¿qué puede hacer?”

Una empresa mediana gestionaba un sitio marketing en una pila bastante estándar: Nginx, PHP-FPM, MariaDB. El equipo de marketing compró un tema premium y desplegó una “actualización menor” justo antes del lanzamiento de una campaña. Nadie esperaba drama porque, en su mente, los temas eran “CSS y algunas plantillas”.

La actualización incluía una nueva librería PHP y empezó a llamar funciones que solo estaban disponibles en una versión menor más reciente de PHP. Producción iba una versión por detrás porque el equipo de operaciones coordinaba una ventana de actualización mayor con varias apps no relacionadas. El tema no falló con gracia; lanzó un fatal durante la inicialización y tumbó tanto el frontend como wp-admin.

La primera respuesta fue clásica: reiniciar PHP-FPM, reiniciar Nginx, purgar cache. Hizo que las cosas fluctuaran pero no solucionó nada. El sitio volvió brevemente porque páginas cacheadas se servían, luego se volvió a caer cuando URLs no cacheadas llamaron a PHP. Siguió la confusión, porque distintas personas veían comportamientos diferentes según la página que cargaran.

La solución eventual fue simple: editar wp_options para activar un tema Twenty predeterminado. El servicio volvió de inmediato. Solo entonces el equipo notó que la actualización del tema también había incluido una característica de auto-actualización que había reescrito algunos assets empaquetados durante el despliegue, dejando la release medio actualizada.

Después cambiaron el proceso: las actualizaciones de tema requerirán validación en staging contra la versión de PHP actual en producción, no contra lo que el proveedor de temas probó la semana pasada. También: el tema predeterminado queda instalado para siempre. La causa raíz no fue “tema malo.” Fue la suposición equivocada de que los temas son inofensivos.

Optimización que salió mal: la caché que ocultó la verdad

Un sitio empresarial tenía una caché agresiva: proxy inverso, plugin de caché y CDN. Era rápido y todos se llevaban el crédito. Luego una versión de un tema personalizado introdujo un error fatal en una plantilla específica usada por la homepage.

Para algunos usuarios, el sitio se veía bien porque el CDN aún tenía la homepage en caché. Para otros, especialmente quienes golpearon un edge frío o una ruta de localización diferente, el origen fue consultado y devolvió un 500. Internamente, los ingenieros se dividieron en dos bandos: “está bien” y “está caído”, lo que es una gran forma de perder una hora.

Mientras tanto, el monitoreo era engañoso porque el endpoint de salud era una URL estática que permanecía cacheada. El panel se mantenía en verde mientras las métricas de ingresos se torcían. La caché no causó el bug, pero hizo el incidente más duro de ver, reproducir y confiar.

La solución de nuevo fue la aburrida: cambiar a un tema predeterminado vía BD, purgar cachés en el orden correcto (origen primero, luego CDN) y ajustar temporalmente el monitoreo para evitar la caché. Después, cambiaron los checks de salud para incluir una petición no cacheada con headers que rompen la caché y validar la accesibilidad del admin por separado.

La caché no es la villana. Pero si tu caché puede dejarte ciego, no es una optimización; es una responsabilidad con badge de rendimiento.

Práctica aburrida pero correcta que salvó el día: tema predeterminado + rollback ensayado

Una organización global corría WordPress como parte de una plataforma de contenidos más amplia. Nada sofisticado: hosts endurecidos, gestión de configuración, releases predecibles. Su runbook para cambios de tema parecía casi cómicamente estricto para “un sitio CMS”.

Siempre mantenían dos temas Twenty instalados. Siempre tenían WP-CLI disponible en el host. Tenían un snippet SQL preescrito en el runbook para cambiar template y stylesheet. Y una política: los despliegues de temas ocurrían en horario laboral con una persona on-call que podía SSHear y realizar rollback.

Un día un tema hijo falló porque el nombre del directorio del tema padre cambió en una refactorización de despliegue. Fue el tipo de error que duele admitir y es fácil de cometer durante una limpieza. El admin murió instantáneamente. El frontend devolvía 500s en páginas no cacheadas.

El ingeniero on-call siguió el runbook: confirmó el fatal, puso ambas opciones a twentytwentyfour, purgó la caché del proxy y anunció servicio restaurado. La disrupción total fue corta. El postmortem fue igualmente aburrido: añadir una comprobación en despliegue que verifique que el directorio del tema activo existe y que el padre del tema hijo está presente.

No fueron heroicidades. Fue repetición. En operaciones, lo aburrido suele ser la forma más alta de competencia.

Preguntas frecuentes

1) ¿Qué valores en la base de datos controlan realmente el tema activo?

template y stylesheet en la tabla de opciones. Normalmente wp_options, a menos que el prefijo de tabla difiera o estés en multisite.

2) ¿A qué debo poner template y stylesheet?

Pon ambos al nombre de directorio de un tema conocido y bueno bajo wp-content/themes, como twentytwentyfour. Nombre del directorio, no el nombre visible del tema.

3) ¿Puedo arreglar esto borrando el tema?

Puedes, pero renombrar es más seguro. Borrar destruye evidencia y hace el rollback más difícil. Renombra el directorio a theme-name.disabled y cambia explícitamente vía BD después.

4) WP-CLI falla con un error fatal. ¿Es WP-CLI inútil acá?

WP-CLI depende del bootstrap de WordPress. Si el tema activo falla durante el bootstrap, WP-CLI puede caerse también. Ahí es cuando las ediciones en la BD brillan.

5) Cambié temas en la BD pero el sitio sigue mostrando la página rota. ¿Por qué?

Caché. Purga la caché del servidor, la del plugin, el proxy inverso y el CDN según corresponda. También considera caché de objetos (Redis/Memcached) que podría mantener opciones obsoletas.

6) ¿Cambiar a un tema predeterminado borrará mi contenido?

No. Entradas y páginas permanecen en la base de datos. Pero la presentación puede cambiar drásticamente: menús, widgets y opciones del tema pueden no mapear bien.

7) ¿Qué pasa si no hay un tema Twenty instalado y el admin está caído?

Sube un tema predeterminado al directorio wp-content/themes desde una fuente de confianza via SCP/SFTP o tu mecanismo de despliegue. Luego ajusta template/stylesheet a ese nombre de directorio.

8) ¿Cómo funciona esto en multisite?

Cada sitio tiene su propia tabla de opciones (p. ej., wp_2_options). Cambia las opciones de tema para el blog ID afectado. Asegúrate también de que el tema objetivo esté habilitado en la red.

9) ¿Podría ser un plugin el verdadero problema en lugar del tema?

Sí. Pero si los logs apuntan a archivos de tema, cambia el tema primero para restaurar el servicio. Si el problema persiste tras cambiar el tema, empieza a deshabilitar plugins (idealmente via WP-CLI o BD) de forma sistemática.

10) ¿Necesito actualizar también las opciones theme_mods_*?

Por lo general no para la recuperación. Esas guardan ajustes del personalizador para un tema específico. Déjalas hasta estar estable e investigar la limpieza de datos o la reconfiguración.

Conclusión: siguientes pasos para evitar la repetición

La forma más rápida de salir de una caída por tema roto es dejar de intentar “arreglar el tema” mientras tus usuarios ven la página de error. Cambia a un tema predeterminado. Restaura el servicio. Luego depura con la cabeza fría.

Haz esto a continuación, en orden

1. Fija la recuperación: verifica que template/stylesheet apunten a un tema predeterminado y que el directorio exista en disco.
2. Captura evidencia: guarda la traza del error fatal y la versión exacta del tema que lo provocó.
3. Reproduce de forma segura: prueba el tema roto en staging con la misma versión de PHP y conjunto de plugins.
4. Decide la acción a largo plazo: revertir el tema, parchearlo o reemplazarlo. No negocies con un tema que sigue intentando tomar como rehén la producción.
5. Añade prevención: mantén un tema predeterminado instalado, añade una comprobación de despliegue para existencia de directorio del tema y crea checks de salud conscientes de caché.

Si no haces otra cosa, haz esto: mantén instalado para siempre al menos un tema Twenty predeterminado. Es un seguro barato y, a diferencia de la mayoría de los seguros, realmente funciona.