Aprender a depurar un error de WordPress

Una pantalla en blanco o una respuesta 500 no identifica por sí sola la causa: el fallo puede proceder de PHP, WordPress, el servidor web o una dependencia. Empieza por el registro asociado a la petición y a la hora exacta del error, sin atribuirlo todavía a un plugin o a un cambio reciente.

Realiza la prueba preferiblemente en una copia de staging. Si debes reproducirla en producción, mantén display_errors desactivado y envía los errores a un registro privado fuera de public_html, siguiendo la guía para depurar errores en WordPress.

Si WordPress muestra el mensaje de error crítico, revisa antes el correo de la cuenta administradora. Desde WordPress 5.2, el enlace de Modo de recuperación permite acceder con el plugin o tema problemático pausado para esa sesión.

Reproduce únicamente la operación que falla y consulta inmediatamente el registro. En este ejemplo aparece el siguiente error fatal:

Fatal error: require(): Failed opening required 
'/home/user/public_html/wp-content/plugins/woocommerce/src/Packages.php' 
(include_path='.:/opt/alt/php74/usr/share/pear') 
in /home/user/public_html/wp-content/plugins/woocommerce/woocommerce.php on line 25

El mensaje demuestra que require no pudo abrir este fichero:

public_html/wp-content/plugins/woocommerce/src/Packages.php

y que la llamada se realizó desde la línea 25 de:

public_html/wp-content/plugins/woocommerce/woocommerce.php

Esto sitúa el fallo durante la carga de WooCommerce, pero no demuestra por sí solo que el plugin esté dañado ni por qué no pudo abrirse el fichero. Revisa también el aviso anterior a Failed opening required, que suele indicar si el fichero no existe, no es legible o está bloqueado por una restricción de ruta. Comprueba su existencia, mayúsculas y minúsculas, permisos, propietario y correspondencia con la versión instalada.

Si el fichero realmente falta y el error apareció durante una actualización, una instalación incompleta es una hipótesis compatible con la evidencia. Para recuperar temporalmente el acceso, usa primero el Modo de recuperación o renombra wp-content/plugins/woocommerce; no elimines el directorio antes de conservar una copia para el análisis.

Después puedes reinstalar la misma versión o una versión compatible desde una fuente oficial. Restaura el directorio desde una copia de seguridad solo si la copia es anterior al fallo, se considera limpia y es compatible con el estado actual de la base de datos.

Recuperar la tienda y comprobar el pedido completo

La traza es un ejemplo histórico: la ruta php74 no recomienda utilizar PHP 7.4. Usa la versión compatible y mantenida que corresponda a tu WooCommerce actual.

Mientras WooCommerce esté pausado, la tienda puede perder funciones de compra. Conserva pedidos recientes y evita restaurar una base antigua solo para recuperar un archivo del plugin. Tras reparar los archivos, verifica catálogo, carrito, inicio de compra y notificación de pago en un entorno de prueba. Si instalas una versión que migra la base, planifica también la compatibilidad de la reversión; copiar una carpeta antigua después no deshace esa migración.