Error crítico de WooCommerce tras actualizar: revertir y recuperar de forma segura

enero 9, 2026 • febrero 3, 2026 • Lectura: 29 min • Views: 8

¿Te fue útil?

Si estás leyendo esto, probablemente tu tienda acaba de protagonizar el clásico escenario: una actualización rutinaria, un refresco y de repente WordPress muestra el temido “Ha habido un error crítico en este sitio web.” Los pedidos se detienen. El pago deja de funcionar. El equipo de marketing empieza con “solo comprobando”.

Buenas noticias: la mayoría de las fallas post-actualización de WooCommerce se pueden recuperar sin pérdida de datos, y el camino más rápido de regreso no es depurar heroicamente, sino ejecutar un rollback disciplinado, leer los logs con foco y proteger la base de datos como si te pagara el sueldo. Porque lo hace.

Tabla de contenidos

Qué significa realmente “error crítico” en el mundo de WooCommerce

Ese mensaje es la envoltura educada de WordPress para un error fatal de PHP. No es un diagnóstico; es un cinturón de seguridad. WordPress captura el fatal, evita mostrar el stack trace en tu tienda y muestra la página de “error crítico”. Detrás suele haber una de estas causas:

Una actualización de un plugin introdujo una incompatibilidad (versión de PHP, versión de WordPress, otro plugin, hooks del tema).
Una actualización del tema (o código personalizado del tema) está llamando funciones de WooCommerce eliminadas.
Una actualización parcial dejó archivos desajustados: mitad código nuevo, mitad código antiguo.
El caché de opcode (OPcache) está sirviendo código obsoleto mientras el sistema de archivos ya avanzó.
Una migración de base de datos se ejecutó y falló a mitad de camino, dejando esquema u opciones inconsistentes.
Un cambio del lado servidor coincidió con la actualización: módulos PHP cambiados, permisos de archivos, disco lleno o un autoloader corrupto.

Cuando WooCommerce está involucrado hay un ángulo extra: las actualizaciones de WooCommerce a veces incluyen migraciones de base de datos. Normalmente son seguras e idempotentes, pero “normalmente” no es el contrato que quiere escuchar tu director financiero.

Una idea parafraseada de Werner Vogels (CTO de Amazon): construyes sistemas asumiendo que fallarán, luego diseñas para que el radio de impacto sea pequeño y la recuperación rutinaria.

Guía de diagnóstico rápido (qué comprobar primero/segundo/tercero)

Este es el orden que te devuelve la producción más rápido en escenarios reales. El objetivo no es entenderlo todo. El objetivo es restaurar el checkout y luego hacer la forense.

Primero: confirma que es un fatal de PHP y captura la firma

Comprueba el registro de errores del servidor web (Nginx/Apache) y el log de PHP-FPM en busca de un fatal reciente en la hora del incidente.
Busca el marco superior del stack apuntando a wp-content/plugins/ o wp-content/themes/.
Si no puedes ver logs, habilita la depuración de WordPress con logging seguro (registrar a archivo, no mostrar en pantalla).

Segundo: elimina variables deshabilitando al sospechoso más probable

Desactiva primero el/los plugins actualizados por última vez.
Si no sabes cuál cambió, desactiva todos los plugins vía WP-CLI o renombra los directorios de plugins.
Cambia a un tema por defecto (Storefront/Twenty Twenty-*) si el fatal apunta al tema.

Tercero: verifica la salud de la base de datos y si se ejecutaron migraciones

Comprueba si WooCommerce solicita actualizaciones de base de datos, si las acciones programadas están bloqueadas y si las opciones/transients están corruptos.
Confirma la conectividad de BD y el estado de replicación si aplica.
Toma una instantánea/backup antes de pulsar cualquier botón de “actualizar base de datos”.

Cuándo detenerse y restaurar desde backup

Si el sitio está caído y no puedes aislar el fatal en 15–30 minutos, restaura al último snapshot conocido bueno. Después depura en staging. Depurar heroicamente en producción es la forma de convertirte en una advertencia.

Estabilizar primero: detener la hemorragia sin empeorarla

La recuperación comienza por estabilizar el sistema, porque los sistemas rotos atraen “soluciones rápidas” que crean incidentes secundarios. Tu primera tarea es prevenir daño a los datos:

Congelar cambios: pausar despliegues, desactivar auto-actualizaciones, evitar que compañeros “ayudosos” pulsen botones.
Preservar evidencia: mantener logs, copiar trazas de stack, registrar versiones.
Proteger pedidos: si el checkout está roto pero el admin funciona, considera poner la tienda en modo mantenimiento con un banner claro, no un error 500.
Hacer backup ahora: aunque ya tengas copias, toma una instantánea fresca antes de revertir. Podrías necesitar recuperar pedidos creados durante la ventana de caída o migraciones parciales.

Broma corta #1: Las auto-actualizaciones son como “refactors sorpresa” que no programaste—emocionantes para nadie que esté de guardia.

Logs y señales que importan (y las que engañan)

Las fallas de WordPress son ruidosas. Necesitas señales limpias.

Artefactos de alta señal

Registro de errores del servidor web: te dice si PHP murió, ocurrieron timeouts o fallaron upstreams.
Log de PHP-FPM: captura fatales, agotamientos de memoria y caídas de workers.
WordPress debug.log: puede capturar advertencias de plugins y trazas fatales si está habilitado.
Logs de estado de WooCommerce: a veces incluyen problemas de migración y fallos en REST.
Registro de errores de la base de datos: deadlocks, disco lleno, tablas corruptas.

Distracciones de baja señal

Errores de consola del navegador: útiles para checkout roto en JS, no para errores fatales de PHP.
Ratios de HIT del cache: durante una caída, las caches pueden enmascarar el radio de impacto o seguir sirviendo páginas rotas de forma fiable.
“Funciona en mi máquina”: los entornos locales rara vez coinciden con producción en extensiones PHP, límites de memoria o permisos de archivos.

Un truco recurrente: un “error crítico” que aparece solo para algunos usuarios puede ser causado por caching de página sirviendo una página de error en caché, o por pools/servidores PHP diferentes ejecutando código distinto. Trata la inconsistencia como un problema de higiene de despliegue primero.

Estrategia de rollback: plugins/tema/core sin corromper datos

Rollback no es una sola cosa. Decide qué vas a revertir y qué estado necesitas preservar.

1) Revertir un plugin (WooCommerce u otro)

Si una actualización de un plugin desencadenó el fatal, revertir solo ese plugin suele ser lo más seguro. Pero ten en cuenta este detalle: si el plugin ejecutó una migración de base de datos, revertir el código podría hacer que el código antiguo falle con el esquema nuevo. WooCommerce suele ser cuidadoso con la compatibilidad hacia atrás, pero las extensiones varían mucho.

Regla práctica: revierte el código primero para restaurar el renderizado de páginas, luego evalúa el estado de la migración de base de datos antes de volver a avanzar.

2) Cambiar el tema para aislar fatales a nivel de tema

Un tema que llama funciones de plantilla de WooCommerce eliminadas es común tras actualizaciones de WooCommerce. Cambiar a Storefront (o a un tema por defecto de WP) es una manera quirúrgica de confirmar la implicación del tema. Puedes mantener los plugins activos y recuperar el checkout mientras tu equipo de desarrollo arregla el tema.

3) Revertir WordPress core (rara vez necesario, pero posible)

Las actualizaciones de core pueden sacar a la luz incompatibilidades latentes. Revertir core es más arriesgado porque los plugins esperan avanzar. Solo lo hago si (a) el incidente empezó claramente con una actualización de core, (b) el entorno está estable, y (c) tengo un snapshot conocido bueno para restaurar.

4) Restauración completa desde snapshot

Para tiendas con tráfico significativo, “restauración completa” suele ser el camino más rápido y seguro—siempre que tengas snapshotting disciplinado. Restaura código + base de datos a un punto conocido bueno, levanta el sitio y luego reprocese los pedidos faltantes si hace falta. La clave es entender tu Objetivo de Punto de Recuperación (RPO): cuánto datos estás dispuesto a perder.

Recuperación de la base de datos: cómo evitar convertir un error PHP en un evento de ingresos

La mayoría de los “errores críticos” de WooCommerce son a nivel de código. La base de datos suele estar bien. No la conviertas en algo que no está.

Qué puede salir mal con la base de datos durante una actualización

Deriva del esquema: nuevas columnas/tablas creadas, código antiguo que no las espera (normalmente OK), o código nuevo que las espera pero no se crearon por una migración fallida.
Corrupción de opciones: una option serializada actualizada con estructura incompatible; PHP luego falla al unserializar o al acceder a arreglos.
Colapso del Action Scheduler: WooCommerce usa Action Scheduler para trabajos en segundo plano. Si se atasca (bloqueos de BD, timeouts), el sitio puede comportarse “roto” de maneras extrañas.
Sorpresas de conjunto de caracteres/collation: raro, pero las actualizaciones pueden hacer que modos SQL estrictos importen más, revelando consultas malas en extensiones.

Reglas de seguridad de BD durante la recuperación

Snapshot antes de pulsar “Ejecutar actualización de BD.” Siempre. Sin excepciones.
Prefiere consultas de diagnóstico en solo lectura primero. Verifica presencia de tablas, recuento de filas, escrituras recientes de pedidos.
No “repares tablas” por reflejo. A veces es necesario, pero también es una buena manera de destruir evidencia y crear nuevos problemas.
Entiende qué incluye tu backup. Algunas “copias” omiten tablas transitorias o tablas grandes. Los pedidos de WooCommerce viven en posts/postmeta (o tablas HPOS si están habilitadas). Asegúrate de que tu backup cubre lo que te genera ingresos.

Tareas prácticas: 12+ comandos reales, salidas y decisiones

Estas tareas asumen que tienes acceso SSH al servidor y una pila Linux estándar + Nginx/Apache + PHP-FPM + MySQL/MariaDB. Ajusta rutas para tu distro. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión.

Task 1: Confirmar síntomas actuales del incidente (estado HTTP y respuesta)

cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 500
date: Fri, 27 Dec 2025 10:11:22 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: Es una falla del lado servidor, no solo un asset roto o un error JS.

Decisión: Ir directo a los logs del servidor/PHP. No pierdas tiempo en el navegador.

Task 2: Encontrar el error fatal en el log de Nginx

cr0x@server:~$ sudo tail -n 60 /var/log/nginx/error.log
2025/12/27 10:11:19 [error] 22190#22190: *8841 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_logger() in /var/www/html/wp-content/plugins/some-gateway/inc/init.php:41
Stack trace:
#0 /var/www/html/wp-settings.php(453): include_once()
#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/plugins/some-gateway/inc/init.php on line 41" while reading response header from upstream, client: 198.51.100.19, server: store.example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "store.example.com"

Qué significa: Un plugin de pasarela de pago llamó a una función de WooCommerce que no está cargada (o WooCommerce está roto/desactivado/medio actualizado).

Decisión: Desactiva ese plugin de pasarela primero. Si WooCommerce se actualizó, confirma que WooCommerce carga correctamente.

Task 3: Comprobar cambios recientes de paquetes/archivos (qué se actualizó?)

cr0x@server:~$ ls -lt /var/www/html/wp-content/plugins | head
total 92
drwxr-xr-x 10 www-data www-data 4096 Dec 27 10:02 woocommerce
drwxr-xr-x  8 www-data www-data 4096 Dec 27 10:02 some-gateway
drwxr-xr-x  7 www-data www-data 4096 Nov 18 09:40 wp-mail-smtp

Qué significa: WooCommerce y la pasarela fueron tocados al mismo tiempo—probablemente la ventana de actualización.

Decisión: Desactiva la pasarela primero (rápido), luego valida que WooCommerce cargue. Si sigue roto, revierte WooCommerce.

Task 4: Desactivar un plugin rápido renombrando su directorio

cr0x@server:~$ cd /var/www/html/wp-content/plugins
cr0x@server:~$ sudo mv some-gateway some-gateway.disabled
cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:01 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: El plugin de la pasarela causó el fatal. El sitio está sirviendo páginas de nuevo.

Decisión: Mantenerlo desactivado, luego buscar una versión compatible o un parche del proveedor antes de reactivar. Verificar específicamente el checkout.

Task 5: Validar que el endpoint de checkout devuelve 200 (no solo la home)

cr0x@server:~$ curl -I -s https://store.example.com/checkout/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:19 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: La ruta de checkout responde a nivel HTTP. No garantiza éxito de pago, pero ya estás fuera del hoyo.

Decisión: Proceder a validación funcional (añadir al carrito, cálculo de envío, disponibilidad de métodos de pago) y monitorear logs.

Task 6: Si WP-CLI está disponible, listar plugins y confirmar qué está activo

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+-------------------+--------+-----------+---------+
| name              | status | update    | version |
+-------------------+--------+-----------+---------+
| woocommerce       | active | available | 9.3.2   |
| akismet           | active | none      | 5.3     |
| wp-mail-smtp      | active | none      | 4.3.1   |
+-------------------+--------+-----------+---------+

Qué significa: El gateway problemático ya no está activo (bien). WooCommerce aparece activo, pero muestra actualización disponible, lo que puede indicar flujos de actualización parciales.

Decisión: No actualices nada más todavía. Captura el estado y decide si avanzar WooCommerce a una versión estable en staging.

Task 7: Habilitar el logging de depuración de WordPress de forma segura (sin mostrar errores)

cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_LOG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_DISPLAY false --raw
cr0x@server:~$ sudo -u www-data wp config set SCRIPT_DEBUG false --raw

Qué significa: Los errores se registrarán en wp-content/debug.log sin exponer stack traces a clientes.

Decisión: Usa esto temporalmente durante la respuesta al incidente; revierte después de estabilizar para reducir ruido y uso de disco.

Task 8: Leer el debug.log de WordPress e identificar advertencias posteriores

cr0x@server:~$ sudo tail -n 80 /var/www/html/wp-content/debug.log
[27-Dec-2025 10:13:25 UTC] PHP Warning:  Undefined array key "country" in /var/www/html/wp-content/plugins/woocommerce/includes/class-wc-countries.php on line 133
[27-Dec-2025 10:13:26 UTC] PHP Notice:  Function wpdb::prepare was called incorrectly. The query does not contain the correct number of placeholders. in /var/www/html/wp-includes/class-wpdb.php on line 1777

Qué significa: El fatal desapareció, pero tienes advertencias de compatibilidad. Pueden convertirse en fatales bajo versiones más estrictas de PHP o en releases futuros.

Decisión: Registro estas como deuda técnica; prioriza cualquier advertencia relacionada con checkout/impuestos/envío.

Task 9: Verificar versión de PHP y módulos cargados (chequeo de compatibilidad)

cr0x@server:~$ php -v
PHP 8.1.27 (cli) (built: Nov 20 2025 12:12:11) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

Qué significa: Estás en PHP 8.1 con OPcache. Algunos plugins antiguos siguen rompiéndose aquí, especialmente por funciones deprecadas.

Decisión: Si el plugin fallido es antiguo, revertirlo puede no ayudar; podrías necesitar una versión soportada por el proveedor compatible con PHP 8.1+.

Task 10: Limpiar PHP-FPM de forma elegante para vaciar OPcache (si sospechas código obsoleto)

cr0x@server:~$ sudo systemctl reload php8.1-fpm
cr0x@server:~$ sudo systemctl status php8.1-fpm --no-pager | head -n 12
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 08:03:10 UTC; 2h 10min ago
       Docs: man:php-fpm8.1(8)

Qué significa: El reload tuvo éxito; los workers se reiniciarán de forma elegante y refrescarán el estado de OPcache.

Decisión: Si los problemas desaparecen tras el reload, tu “actualización” pudo ser un problema de coherencia de cache. Arregla el procedimiento de despliegue para recargar PHP-FPM después de cambios de código.

Task 11: Comprobar espacio en disco (las actualizaciones fallan raro cuando estás sin espacio)

cr0x@server:~$ df -h /var/www/html | tail -n 1
/dev/vda1        40G   39G  1.1G  98% /

Qué significa: Estás casi lleno. Las actualizaciones de WordPress pueden aplicarse parcialmente cuando las escrituras fallan, dejando un directorio de plugin Frankenstein.

Decisión: Libera espacio antes de intentar reactualizar o revertir. Si las marcas de tiempo de los directorios de plugin son inconsistentes, considera restaurar desde backup en lugar de confiar en el sistema de archivos.

Task 12: Confirmar propiedad y permisos de archivos (para evitar actualizaciones parciales)

cr0x@server:~$ stat -c "%U:%G %a %n" /var/www/html/wp-content/plugins/woocommerce | head -n 1
www-data:www-data 755 /var/www/html/wp-content/plugins/woocommerce

Qué significa: La propiedad coincide con el usuario web. Si ves root:root o permisos desajustados, el actualizador puede fallar al escribir archivos.

Decisión: Corrige la propiedad antes de volver a ejecutar actualizaciones; si no, te expones a repetir caídas.

Task 13: Comprobar conectividad y salud básica de MySQL

cr0x@server:~$ mysqladmin -uroot -p ping
Enter password:
mysqld is alive

Qué significa: La BD es alcanzable y responde.

Decisión: Procede con consultas dirigidas; no asumas corrupción de BD si el problema fue un fatal de PHP.

Task 14: Verificar que los pedidos recientes siguen escribiéndose (confirmación en solo lectura)

cr0x@server:~$ mysql -uroot -p -e "USE wordpress; SELECT ID, post_date, post_status FROM wp_posts WHERE post_type='shop_order' ORDER BY ID DESC LIMIT 5;"
Enter password:
+-------+---------------------+------------+
| ID    | post_date           | post_status|
+-------+---------------------+------------+
| 81231 | 2025-12-27 10:05:41 | wc-pending |
| 81230 | 2025-12-27 09:58:10 | wc-completed |
| 81229 | 2025-12-27 09:41:03 | wc-processing |
| 81228 | 2025-12-27 09:30:55 | wc-failed |
| 81227 | 2025-12-27 09:22:14 | wc-completed |
+-------+---------------------+------------+

Qué significa: Hay pedidos dentro de la ventana del incidente (pendientes/erróneos pueden ser esperables si el checkout falló a mitad de flujo).

Decisión: Coordina con soporte: identifica clientes afectados y concilia pagos. No borres pedidos “fallidos” hasta entender el comportamiento de la pasarela.

Task 15: Cambiar tema vía WP-CLI (aislamiento rápido)

cr0x@server:~$ sudo -u www-data wp theme list --status=active
+-----------+--------+---------+
| name      | status | version |
+-----------+--------+---------+
| my-theme  | active | 3.1.0   |
+-----------+--------+---------+
cr0x@server:~$ sudo -u www-data wp theme activate storefront
Success: Switched to 'Storefront' theme.

Qué significa: Puedes evitar fatales del tema sin tocar plugins.

Decisión: Si el sitio vuelve con Storefront, tu tema es el problema. Mantén Storefront temporalmente y arregla tu tema en un despliegue controlado.

Task 16: Si WP-CLI no está disponible, desactiva todos los plugins renombrando el directorio de plugins

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ sudo mv plugins plugins.off
cr0x@server:~$ sudo mkdir plugins
cr0x@server:~$ sudo chown www-data:www-data plugins

Qué significa: WordPress tratará los plugins como ausentes. Es la herramienta contundente que recupera la UI de administración.

Decisión: Úsalo cuando no puedas identificar al culpable con rapidez. Levanta el sitio y luego reintroduce plugins uno a uno (o en lotes) para encontrar al culpable.

Task 17: Validar el estado de actualización de la BD de WooCommerce (pista de backlog de Action Scheduler)

cr0x@server:~$ sudo -u www-data wp option get woocommerce_db_version
9.3.2
cr0x@server:~$ sudo -u www-data wp option get woocommerce_version
9.3.2

Qué significa: La versión de código y la versión de la BD coinciden. Eso reduce la probabilidad de que estés en un estado de migración parcial.

Decisión: Enfócate en compatibilidad de extensiones en lugar de recuperación de BD—a menos que veas tablas faltantes o trabajos en segundo plano atascados.

Tres microhistorias corporativas desde el frente

Microhistoria 1: La caída causada por una suposición equivocada

La compañía: un minorista mediano con una tienda WooCommerce que maneja volumen diario constante y picos estacionales. Tenían un proveedor de hosting decente y un equipo competente. No era un shop de “moverse rápido y romper cosas”. Más bien “moverse con cuidado y aun así romper cosas, pero con reuniones”.

Un ingeniero actualizó WooCommerce y varias extensiones durante un día tranquilo. La suposición: “Si la pantalla de actualización dice que es compatible con nuestra versión de WordPress, es compatible con nuestro entorno.” Esa suposición es la semilla de muchas caídas.

En su entorno, PHP había sido actualizado recientemente por el host de 7.4 a 8.1. Nadie lo relacionó con la tienda, porque el sitio había estado “bien” durante semanas. La actualización del plugin de la pasarela introdujo un camino de código que usaba un comportamiento deprecado que PHP 8.1 trató con más rigor. No todas las páginas lo golpeaban. El checkout sí, bajo condiciones específicas del carrito.

El equipo persiguió plantillas de WooCommerce, luego caching, luego “tal vez Stripe está caído.” Mientras tanto, los clientes podían navegar pero no pagar, que es el tipo de “casi arriba” más caro. La solución eventual fue embarazosamente simple: revertir el plugin de la pasarela y fijarlo a una versión soportada por el proveedor.

Lo que cambiaron después fue más importante que la reparación: añadieron un informe de entorno pre-actualización (versión de PHP, extensiones, límite de memoria) y dejaron de confiar en banners de compatibilidad como sustituto de pruebas. Los banners de compatibilidad son marketing, no contratos.

Microhistoria 2: La optimización que salió mal

Otra compañía, pila similar. Su consultor de rendimiento ajustó caching agresivamente: caché de página completa en el edge, object cache en Redis, OPcache afinado y un proceso de despliegue que “solo cambia lo necesario.” Traducción: las actualizaciones de código no reiniciaban PHP-FPM porque “es más rápido”.

Actualizaron WooCommerce. Los archivos cambiaron. El edge cache purgó correctamente. Pero OPcache siguió sirviendo bytecode antiguo para algunos archivos mientras que existían archivos nuevos en disco para otros. Un clásico split-brain entre “lo que dice el sistema de archivos” y “lo que PHP realmente ejecuta.” El resultado fue un fatal por métodos de clase faltantes que existían en el código nuevo, no en el bytecode cacheado.

Intentaron revertir el plugin copiando archivos antiguos de vuelta. Eso empeoró la situación porque OPcache ahora tenía una mezcla caótica de bytecode viejo y nuevo. Cada refresco era una sorpresa distinta. El equipo lo describió como “embrujado.” Yo lo describí como “predecible, solo que no para ti.”

La solución fue recargar PHP-FPM, limpiar OPcache coherentemente y luego desplegar usando un patrón de lanzamiento atómico (nuevo directorio, conmutador de symlink) emparejado con un reload controlado. El rendimiento siguió bien. Y ahora las actualizaciones no requieren rituales de sesión.

Aprendieron a la fuerza: las optimizaciones que saltan reinicios están bien hasta que no lo están. Entonces se convierten en multiplicadores de tiempo de inactividad.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Esta es menos dramática, que es el punto. Un vendedor B2B ejecutaba WooCommerce con un conjunto pequeño de extensiones seleccionadas cuidadosamente. Tenían un entorno de staging que reproducía producción: misma versión de PHP, mismo object cache, mismo tema y una copia depurada de la BD de producción refrescada semanalmente.

Antes de actualizaciones, ejecutaban una lista de verificación: snapshot de producción, actualizar staging, ejecutar un pequeño suite de pruebas (login, añadir al carrito, checkout con pasarela de test, edición de pedidos en admin), luego programar las actualizaciones en producción en ventana de bajo tráfico. Nada sofisticado. Solo consistencia.

Una actualización aún salió mal: una actualización de extensión de envío introdujo un fatal cuando se ingresaban ciertos formatos de dirección. Pero staging lo detectó. Pausaron esa actualización de extensión, actualizaron todo lo demás y desplegaron producción de forma segura.

El “ahorro” no solo fue evitar tiempo de inactividad. Fue evitar el impuesto al pánico: reuniones de emergencia, restauraciones nocturnas y la lenta erosión de la confianza del cliente. Su práctica era aburrida y funcionó. La mayoría de la fiabilidad es aburrida. Por eso es rara.

Hechos interesantes y contexto histórico

Un poco de contexto te ayuda a predecir modos de fallo en vez de solo reaccionar.

WooCommerce nació como un plugin creado por WooThemes y más tarde pasó a formar parte del ecosistema de Automattic, lo que influyó en su cadencia de lanzamientos e integraciones.
WordPress introdujo la pantalla de “error crítico” para reducir la divulgación de información de fatales y guiar a los administradores mediante enlaces de recuperación por email, cambiando la resolución de “pantalla blanca” a una recuperación registrada.
La era clásica del “White Screen of Death” no fue solo drama—a menudo eran fatales de PHP con display_errors apagado, forzando a los admins a aprender flujos de trabajo orientados a logs.
WooCommerce usa Action Scheduler (usado también por otros plugins) para procesamiento en segundo plano; cuando se atasca, los síntomas parecen “WooCommerce está roto” aunque el frontend renderice.
PHP 8.x endureció comportamientos sobre notices y patrones deprecados, por lo que plugins que “funcionaban durante años” pueden fallar tras una actualización del servidor incluso sin cambiar el código.
Las actualizaciones de WordPress suelen ser atómicas a nivel de paquete, no del sistema de archivos; si el disco se llena a mitad de actualización puedes acabar con directorios parciales y archivos faltantes.
OPcache fue creado para acelerar PHP dramáticamente, pero introdujo una nueva clase de fallo: bytecode obsoleto tras despliegues si no recargas workers.
WooCommerce ha evolucionado su modelo de almacenamiento de datos con el tiempo (incluyendo almacenamiento de pedidos de alto rendimiento opcional); las migraciones pueden ser seguras pero aún requieren planes de rollback.

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

Esta sección es intencionadamente específica. El consejo genérico es la forma de repetir incidentes.

1) Síntoma: “Error crítico” inmediatamente después de actualizar una extensión de pago/envío

Causa raíz: La extensión llama funciones de WooCommerce antes de que WooCommerce cargue, o depende de una API de WooCommerce más nueva que la que tienes, o falla en tu versión de PHP.

Solución: Desactiva la extensión renombrando su directorio. Restaura el sitio. Luego instala una versión compatible en staging y vuelve a habilitar.

2) Síntoma: El sitio funciona en un servidor pero no en otro (detrás de un load balancer)

Causa raíz: Despliegue parcial entre nodos, archivos de plugin desajustados o estado PHP-FPM/OPcache diferente.

Solución: Verifica versiones de release en todos los nodos y recarga PHP-FPM en todos. Usa despliegues atómicos e invalidación consistente de cache.

3) Síntoma: El admin funciona, el frontend devuelve 500

Causa raíz: Fatal a nivel de tema (override de plantilla, hook eliminado) o un plugin que solo se ejecuta en peticiones frontend.

Solución: Cambia a Storefront; si se arregla, parchea las overrides del tema. Si no, desactiva primero plugins pesados de frontend (caching, optimización, constructores de página).

4) Síntoma: “Error crítico” aparece y desaparece después de unos minutos

Causa raíz: Inconsistencia de cache transitoria, OPcache limpiándose lentamente, trabajo en segundo plano que termina o reinicios por fases.

Solución: No declares victoria. Recarga PHP-FPM, limpia caches coherentemente y monitorea logs por fatales recurrentes. Intermitente sigue siendo roto; solo que mejor oculto.

5) Síntoma: La pantalla de actualización se queda colgada; después el sitio está roto con archivos faltantes

Causa raíz: Disco lleno, permisos equivocados o interrupción de red a mitad de actualización que produjo archivos incompletos de plugin/core.

Solución: Libera espacio y restaura desde un snapshot conocido bueno. No intentes “parchar” archivos faltantes manualmente a menos que disfrutes de arqueología bajo presión.

6) Síntoma: El checkout carga pero los pagos fallan o los pedidos quedan pendientes

Causa raíz: Plugin de pasarela desactivado/revertido, endpoints de webhook cambiados o backlog de Action Scheduler impidiendo tareas de finalización de pedidos.

Solución: Verifica estado del plugin de pasarela y logs de webhooks; revisa colas de Action Scheduler; concilia pedidos pendientes con el proveedor de pagos.

7) Síntoma: Después del rollback, WooCommerce pide ejecutar actualizaciones de base de datos otra vez

Causa raíz: Desajuste código/BD; el rollback devolvió el código pero la versión de BD quedó avanzada, o la actualización no terminó.

Solución: Restaura el snapshot de BD que coincida con el código, o mueve el código hacia adelante para coincidir con la BD. No sigas cambiando versiones de un lado a otro; elige un par consistente.

Listas de verificación / plan paso a paso (seguro para producción)

Lista de respuesta a incidentes (primeros 30 minutos)

Confirmar impacto: homepage + checkout + admin. Captura estado HTTP.
Congelar cambios: pausar auto-actualizaciones y despliegues hasta estabilizar.
Agarrar la firma del fatal: web server + PHP-FPM logs alrededor del momento del incidente.
Instantánea ahora: filesystem + snapshot/backup de base de datos, incluso si planeas revertir.
Desactivar el plugin cambiado recientemente: renombrar directorio; volver a probar.
Si no está claro: desactivar todos los plugins; volver a probar; luego restaurarlos selectivamente.
Si sospechas del tema: cambiar a Storefront; volver a probar el checkout.
Limpiar coherentemente: recargar PHP-FPM (OPcache), purgar cache de página completa con cuidado.
Validar pedidos: asegurar que la creación de pedidos funciona; identificar estados atascados.
Comunicar: página de estado/comunicaciones internas: qué se rompió, qué se mitigó, siguientes pasos.

Lista de rollback seguro (enfocada en plugins)

Registrar la versión del plugin antes del rollback (desde readme del directorio o WP-CLI).
Confirmar que espacio en disco y permisos están normales.
Desactivar el plugin (renombrar directorio) para restaurar el servicio rápido.
Restaurar una versión anterior del plugin desde tu repositorio de artefactos/backup (no desde copias aleatorias).
Recargar PHP-FPM para evitar OPcache obsoleto.
Reactivar el plugin y probar flujos críticos de forma controlada.
Monitorear logs durante 15–30 minutos tras la restauración.

Lista de restauración segura (restauración completa desde snapshot)

Identificar el último punto de restauración conocido bueno y la hora de inicio de la caída.
Decidir el RPO: ¿aceptas perder pedidos entre el punto de restauración y ahora?
Exportar pedidos creados después del punto de restauración si es posible (o planear conciliación manual).
Restaurar snapshot de base de datos primero (o en par consistente con snapshot de filesystem).
Restaurar filesystem (wp-content, y core si lo incluiste en el snapshot) que coincida con esa BD.
Recargar PHP-FPM y el servidor web.
Validar checkout end-to-end con transacciones de prueba.
Conciliar pedidos/pagos de la ventana faltante.

Broma corta #2: Lo único peor que no tener backup es descubrir que tu “backup” es un póster motivacional con un icono ZIP.

Prevención: evita que las actualizaciones te tumben otra vez

Una vez recuperado, la tentación es respirar hondo y seguir. Resiste. Recuperarte sin prevención es solo programar tu próxima caída.

1) Ejecuta actualizaciones en staging que realmente coincida con producción

Un staging que corre PHP 7.4 mientras producción corre 8.1 no es staging. Es teatro. Coincide en:

Versión de PHP y extensiones
Motor/version de base de datos y modo SQL
Comportamiento del object cache (Redis/Memcached)
Configuraciones de OPcache
Tema y plugins must-use

2) Trata las actualizaciones de WooCommerce como “releases de aplicación”

WooCommerce no es un plugin de formulario de contacto. Es tu motor de ingresos. Eso significa:

Ventanas de mantenimiento para actualizaciones mayores
Revisión de changelogs como notas de release, no como newsletter
Planes de rollback y roll-forward documentados
Scripts de verificación post-actualización (smoke tests) ejecutados siempre

3) Controla la deriva de versiones y quita la ruleta de plugins

Demasiadas tiendas ejecutan un “mercado de plugins” en producción: 40+ plugins, cada uno con su calendario de releases y calidad de soporte variable. La tasa de fallos es predecible. Redúcela:

Elimina plugins que no necesitas absolutamente.
Prefiere proveedores bien mantenidos con declaraciones claras de compatibilidad.
Fija versiones y actualiza en lotes con combinaciones conocidas buenas.

4) Haz despliegues atómicos y conscientes del cache

Si actualizas código, debes controlar:

Atomicidad del sistema de archivos: desplegar en un directorio nuevo y luego cambiar un symlink, o evitar estados parciales de archivos.
Consistencia de OPcache: recargar PHP-FPM después del despliegue, o usar un mecanismo seguro de invalidez de cache.
Purgas del cache edge/página completa: purgar después del despliegue, no antes, y evitar cachear respuestas de error.

5) Monitorea lo correcto

Si solo monitorizas “HTTP 200 en la homepage”, te perderás fallos costosos. Monitorea:

Tasa de éxito del endpoint de checkout
Tasa de creación de pedidos y tasa de finalización de pagos
Cuenta de fatales de PHP en logs (alerta por picos)
Deadlocks/timeouts de la base de datos
Backlogs de colas (Action Scheduler)

FAQ

1) ¿Debo revertir WooCommerce o la extensión que se actualizó?

Revierte (o desactiva) la extensión primero si el stack trace fatal apunta a ella. WooCommerce es la plataforma; las extensiones son los ofensores habituales. Si el fatal está dentro de archivos core de WooCommerce, entonces considera revertir WooCommerce o restaurar desde snapshot.

2) ¿Puedo arreglar el “error crítico” desactivando todos los plugins?

Sí, y a menudo es el método de aislamiento más rápido. Es disruptivo, pero te devuelve una UI de administración funcional. Luego vuelve a activar plugins por lotes hasta encontrar al culpable. Hazlo metódicamente, no emocionalmente.

3) ¿Por qué la actualización en el dashboard tuvo éxito pero el sitio se rompió?

El flujo de actualización del dashboard puede completarse incluso si algunos archivos no se escribieron correctamente, especialmente con poco espacio en disco o problemas de permisos. Además, un plugin puede instalarse correctamente pero ser incompatible con tu versión de PHP u otro plugin. “Instalado” no es lo mismo que “funciona”.

4) ¿Necesito ejecutar actualizaciones de base de datos de WooCommerce tras una actualización?

A veces sí. Pero haz un snapshot primero. Si ya revertiste código, no ejecutes migraciones hacia adelante en una base de código revertida. Mantén código y BD alineados.

5) ¿Y si no puedo acceder a wp-admin para desactivar plugins?

Renombra el directorio de plugins por SSH (wp-content/plugins → plugins.off) o renombra la carpeta del plugin sospechoso. Eso fuerza a WordPress a tratar los plugins como inactivos sin acceder a wp-admin.

6) ¿Puede el caching causar un “error crítico”?

El caching normalmente no causa el fatal, pero puede amplificarlo (sirviendo páginas de error en caché) o hacerlo intermitente (servidores diferentes, estado OPcache distinto). Limpia caches coherentemente y recarga PHP-FPM después de cambios de código.

7) Después de desactivar el plugin roto, el checkout funciona pero los pagos no. ¿Qué hago?

Es esperable si el plugin de pasarela es el que estaba roto. Restaura el servicio primero (incluso si es solo “solo navegación”), luego elige una versión de pasarela compatible y valida webhooks. Mientras tanto, concilia pedidos pendientes con los logs del proveedor de pagos.

8) ¿Es seguro restaurar solo archivos y no la base de datos?

A veces. Si estás seguro de que no se ejecutó ninguna migración de BD y los pedidos fluyen, un rollback de código puede ser seguro. Si WooCommerce o una extensión pudieron cambiar esquema/opciones, restaura código y BD como par consistente o acepta que estás haciendo un experimento de ciencia.

9) ¿Cuál es la forma más rápida de identificar el plugin culpable?

El stack trace fatal normalmente lo nombra. Busca rutas bajo wp-content/plugins/ en los logs. Si no hay logs, desactiva todos los plugins y vuelve a activarlos hasta que el error regrese. Es tosca, pero fiable.

10) ¿Dejo WP_DEBUG activado después de arreglarlo?

No. Apágalo (o al menos desactiva el logging) una vez estable, a menos que tengas rotación de logs y una razón. Los debug logs crecen y los discos se llenan. Discos llenos es la forma en que “advertencias menores” se vuelven “caídas mayores”.

Conclusión: pasos siguientes que puedes hacer hoy

Si tu tienda WooCommerce mostró un error crítico tras una actualización, la jugada ganadora es aburrida y repetible:

Consigue la firma del fatal desde los logs del servidor/PHP. No adivines.
Desactiva al culpable (normalmente una extensión) para restaurar el servicio rápido.
Recarga PHP-FPM para evitar rarezas de OPcache tras cambios de código.
Valida checkout y escrituras de pedidos, no solo la homepage.
Sólo entonces haz el trabajo más profundo: reproducir en staging, fijar versiones y prevenir.

Y mañana—cuando nadie esté gritando—construye rieles de seguridad: staging parecido a producción, snapshots antes de actualizaciones, despliegues atómicos y monitoreo que entienda tu negocio (pedidos) no solo tus servidores (pings). Así las actualizaciones de WooCommerce vuelven a ser aburridas.