WordPress
WooCommerce 11 con Divi: error 500 en la API REST de WordPress
Activas WooCommerce en un sitio con Divi y de pronto la API REST devuelve «error
crítico» en todo: wp/v2, divi/v1, los plugins ya no se
pueden instalar ni desactivar por API. Pero la tienda funciona, el sitio público se
ve bien y las rutas de wc/* responden sin problema. Esa mezcla de
síntomas es la que hace perder horas buscando en el lugar equivocado.
Lo que sigue es un caso real de octubre de 2026, con las versiones exactas, por qué pasa y cómo salir sin tumbar la tienda.
Los síntomas, que son contradictorios a propósito
El caso: tienda nueva, WooCommerce 11.2.1 activado sobre un sitio con Divi 5.13 y PHP 8.3.
- El sitio público no se cayó. Portada, páginas y tienda cargan normal.
-
wp/v2devuelve 500 con «Se ha producido un error crítico en esta web». Todas las rutas del núcleo. divi/v1también cae, y con ellawp-abilities/v1.-
wc/v3responde perfecto. Con una Application Password,wc/v3/system_statusdevuelve el estado completo sin un error. - Ya no se pueden instalar ni desactivar plugins por REST, que es justo lo que necesitarías para desactivar el que lo rompió.
Esa última es la que convierte un problema en una trampa: la vía por la que administras el sitio es la que dejó de funcionar.
Por qué pasa: no es «WooCommerce roto»
Es tentador culpar a la versión nueva de WooCommerce y quedarse ahí, pero el patrón que vimos en dos sitios distintos apunta a otra cosa: la combinación de WooCommerce 11, Divi y un límite de memoria de PHP demasiado justo.
WooCommerce 11 y Divi son los dos plugins más pesados que puede tener un WordPress. Cada petición a la API REST del núcleo carga todo el entorno: WordPress completo, más Divi, más WooCommerce con sus tablas propias y su sistema de acciones programadas. Si el tope de memoria no alcanza, PHP muere a mitad de la petición y WordPress contesta su «error crítico» genérico, que no dice nada útil.
Las rutas de wc/* sobreviven porque WooCommerce registra su propio
controlador y carga menos cosas por el camino. Por eso el síntoma engaña: parece que
WooCommerce está bien y WordPress está mal, cuando es lo contrario de lo que
intuyes.
En el sitio del caso, WP_MEMORY_LIMIT estaba en 128 MB.
Es el valor que trae media hosting compartido en Chile y alcanza de sobra para un
WordPress normal — pero no para WordPress con Divi y WooCommerce 11 a la vez.
Lo mismo con otra cara: en otro sitio con Divi 4 y WooCommerce 11, lo que se cayó fue el frontal público en vez de la API. Mismo origen, distinto síntoma según qué petición agote la memoria primero.
Cómo salir
En este orden. Los dos primeros pasos son los que resuelven la mayoría de los casos.
1. Encuentra el error de verdad, que está escondido
«Se ha producido un error crítico» no sirve. El fatal real sí está registrado, y acá
hay un detalle que cuesta encontrar: WooCommerce guarda sus propios registros
en wp-content/uploads/wc-logs/, con nombres de archivo que llevan un
hash, así que no los vas a adivinar por FTP. Se ven desde el panel en
WooCommerce → Estado → Registros.
Si no tienes acceso al panel, activa el registro del núcleo en
wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
El fatal aparece en wp-content/debug.log con el archivo y la línea. Si
dice «Allowed memory size of … bytes exhausted», ya tienes el diagnóstico y el paso 2
lo arregla.
2. Sube el límite de memoria
En wp-config.php, antes de la línea que carga wp-settings.php:
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Ojo con algo que engaña: WordPress no puede subir el límite por encima del
que fija PHP. Si tu memory_limit de PHP está en 128 MB, poner
512 en wp-config.php no hace nada. Hay que subirlo también en el panel
del hosting (en cPanel está en MultiPHP INI Editor; en DirectAdmin, en la
configuración de PHP del dominio) o pedírselo al proveedor.
Comprueba el valor real, no el que crees tener: en Herramientas → Salud del
sitio → Información → Servidor aparece el memory_limit efectivo.
3. Si no puedes subir la memoria, desactiva por base de datos
Cuando no hay panel y la REST está caída, queda la vía directa. El listado de
plugins activos vive en una sola fila de la tabla de opciones, en
active_plugins. Con acceso a phpMyAdmin o a la línea de comandos:
wp plugin deactivate woocommerce --skip-plugins --skip-themes
Los dos --skip son importantes: sin ellos WP-CLI carga los plugins para
poder desactivarlos, agota la memoria otra vez y muere antes de hacer nada.
Sin WP-CLI, renombrar la carpeta del plugin por FTP —de woocommerce a
woocommerce-off— logra lo mismo: WordPress no lo encuentra y lo
desactiva solo. Es brusco pero no borra datos.
4. Y mientras lo arreglas, administra por donde sí responde
Si necesitas seguir trabajando, wc/v3 sigue vivo con una Application
Password. No te deja tocar plugins, pero sí productos, pedidos, categorías y el
estado del sistema. Es suficiente para no detener la tienda.
Cómo evitarlo la próxima vez
Comprueba la memoria antes de activar, no después. Si vas a poner WooCommerce en un sitio con Divi, Elementor o cualquier constructor visual pesado, 512 MB es el punto de partida razonable. 128 MB va a fallar, y va a fallar de forma confusa.
No actives plugins pesados por API en producción. Es cómodo hasta que la activación rompe la propia API y te quedas sin la herramienta con la que entraste. Si no hay alternativa, ten preparado el acceso por SSH o a la base de datos antes de pulsar.
Y mide el problema antes de cambiar de plugin. El reflejo cuando la REST se cae es sospechar de incompatibilidades entre versiones y empezar a probar combinaciones. En los dos casos que vimos, la causa de fondo era un número en un archivo de configuración.
Si tienes una tienda con este síntoma y no quieres arriesgar los pedidos probando cosas, lo podemos revisar: lo normal es que se resuelva el mismo día, porque el diagnóstico ya está hecho.
Dudas frecuentes
¿Por qué la API de WooCommerce funciona y la de WordPress no?
Porque cargan distinto. Una petición a wp/v2 levanta todo el entorno —WordPress, el tema, Divi y WooCommerce con sus tablas y sus acciones programadas— mientras que wc/v3 usa el controlador propio de WooCommerce y carga menos por el camino. Si el límite de memoria de PHP es justo, la primera muere y la segunda sobrevive. El síntoma engaña: parece que WooCommerce está bien y WordPress mal, cuando el problema es el entorno completo.
¿Cuánta memoria necesita WordPress con WooCommerce y Divi?
512 MB es un punto de partida razonable cuando conviven un constructor visual pesado y WooCommerce. Los 128 MB que trae por defecto buena parte del hosting compartido en Chile alcanzan para un WordPress normal, pero no para esa combinación. Y conviene comprobar el valor efectivo en Herramientas → Salud del sitio → Información → Servidor, porque WordPress no puede superar el límite que fija PHP por mucho que lo declares en wp-config.php.
¿Dónde quedan registrados los errores fatales de WooCommerce?
En wp-content/uploads/wc-logs/, con nombres de archivo que incluyen un hash, así que por FTP no los vas a encontrar buscando por nombre. Se consultan desde el panel en WooCommerce → Estado → Registros. Si no tienes panel, activa WP_DEBUG_LOG en wp-config.php y el fatal del núcleo aparecerá en wp-content/debug.log con archivo y línea.
¿Cómo desactivo un plugin si no tengo acceso al panel ni a la API?
Dos vías. Con WP-CLI: wp plugin deactivate woocommerce --skip-plugins --skip-themes — los dos skip son imprescindibles, porque sin ellos WP-CLI carga los plugins para desactivarlos y agota la memoria otra vez. Sin WP-CLI, renombrar la carpeta del plugin por FTP hace que WordPress no lo encuentre y lo desactive solo. Ninguna de las dos borra datos.
¿Se pierden los pedidos o los productos con este error?
No. Es un fallo al ejecutar, no de datos: nada se borra ni se corrompe. En el caso que documentamos la tienda y el sitio público siguieron funcionando con normalidad mientras la API estaba caída. Lo que se pierde es la capacidad de administrar por API hasta que se resuelva el límite de memoria.