WooCommerce 10.5.0 y el bug que te puede romper el panel de administración

Hay actualizaciones que traen mejoras. Y hay actualizaciones que traen mejoras… y un bofetón.

WooCommerce 10.5.0 cae en esa segunda categoría para bastantes tiendas: se han reportado casos donde el dashboard de WordPress empieza a fallar, widgets que se quedan cargando, peticiones AJAX que acaban en error 500 y, en el peor escenario, un bloqueo práctico del acceso a /wp-admin.

¿El síntoma estrella? Este fatal:

“Uncaught Error: Call to a member function get_name() on false”

Y lo más irritante: no falla “en tu web”, falla en un sitio donde tú no esperas que te tumbe nada: un widget del panel, el de Recent Reviews (o “reviews” del dashboard).

Qué bug es este y por qué duele tanto

Los reportes apuntan a un fallo en el template del widget del dashboard:

/wp-content/plugins/woocommerce/templates/dashboard-widget-reviews.php

El error indica algo muy básico: WooCommerce intenta llamar a get_name() sobre un objeto que debería existir… y no existe. En PHP eso significa que la variable es false (o no es el tipo esperado) y al invocar un método sobre algo que no es un objeto, revientas.

¿Consecuencia? El dashboard puede no renderizar y WordPress puede quedarse a medias cargando widgets, metaboxes y llamadas AJAX asociadas al panel.

En un hilo de soporte se ve claro: tras actualizar a 10.5.0, aparece el fatal en esa ruta y al volver a una versión anterior “todo vuelve a la normalidad”. Es decir: regresión real, no “casualidad” ni “cosas del hosting”.

El patrón que se repite en los casos reportados

En varios reportes, el fallo se dispara cuando el widget empieza a mostrar “reviews” que no son estrictamente reviews de producto, o cuando la review está asociada a un producto inexistente (borrado, inconsistente, o un tipo de review distinto). Dicho de forma llana: hay reviews sin un producto válido detrás, y el widget no está blindado para ese escenario.

Y aquí está lo jugoso: en WooCommerce 10.5 se anunciaron mejoras de rendimiento para ese mismo widget (“Recent Reviews widget” mucho más rápido). Cuando aceleras una pieza de admin, a veces cambias la forma de consultar datos… y si no filtras bien, te cuelas en un caso borde. Y el caso borde te incendia el admin.

• Fatal PHP en el widget de reviews.
• AJAX 500 y panel incompleto o bloqueado.
• Rollback como “solución” inmediata en producción.

Lo importante: esto no es un “bug molesto”. Es un riesgo operativo

Cuando alguien te dice “hay un bug en el widget del dashboard”, suena a tontería. “Bah, el widget…”.

Hasta que ese widget te impide entrar al admin, o te deja un panel inestable, o te obliga a tocar archivos del plugin en caliente para poder gestionar pedidos. Ahí deja de ser un bug simpático y se convierte en riesgo de continuidad.

Y por eso la recomendación de “si estás a tiempo, espera a 10.5.1” es sensata: las dot releases existen precisamente para corregir regresiones que han colado en el release principal.

Qué hacer si ya has actualizado a 10.5.0 y estás sufriendo el problema

Vamos a lo práctico. Si el problema te está pasando ahora mismo, estas son las decisiones con mejor relación riesgo/beneficio:

1. No improvises en producción. Si tienes staging real, prueba allí cualquier medida.
2. Revisa el error en logs (debug.log / error_log). Si aparece la ruta del template del widget de reviews y el get_name() on false, ya lo tienes acotado.
3. Rollback a la versión anterior estable si el admin está bloqueado o la tienda queda comprometida.
4. No “parchees” editando el plugin como solución definitiva. Puede sacarte del apuro, pero se perderá en cuanto actualices y no quieres vivir en modo “cirujano de urgencias” cada semana.
5. Espera a la dot release (10.5.1) y reintenta con metodología: backup, staging, revisión de compatibilidades, y monitorización post-update.

En los reportes de soporte se mencionan workarounds como desactivar el widget o incluso eliminar parte del template para que el dashboard cargue, pero eso es exactamente lo que es: un workaround, no una solución para un negocio que factura.

El Impacto Real de este bug en la Cuenta de Resultados

Vamos a decirlo sin anestesia: si tu eCommerce depende de WooCommerce, cada actualización mal gestionada es una partida de ruleta rusa con tu margen.

Primero, por coste directo. Cuando el admin se rompe, lo que se rompe no es “el panel”: se rompe la operación. Atención al cliente, gestión de pedidos, ajustes de catálogo, facturación, devoluciones, logística… todo vive ahí. Un bloqueo parcial puede significar horas sin capacidad real de operar, y eso se traduce en dinero o en reputación (que es dinero más lento).

Segundo, por coste de oportunidad. El tiempo que inviertes apagando fuegos no lo inviertes en crecer: campañas, CRO, mejoras de ficha, automatizaciones, integraciones con ERP, segmentación, upsells… Cada “incidente de plugin” te roba foco estratégico.

Tercero, por riesgo acumulado. Porque este bug no aparece de la nada: suele aparecer en tiendas donde hay más complejidad (plugins de reviews de tienda, datos históricos, productos eliminados, integraciones). Y cuanto más crece tu tienda, más fácil es que existan “datos imperfectos”. La complejidad no se perdona, se gestiona.

Cuarto, por asimetría de daño: el beneficio de actualizar “ya” es pequeño (novedades, mejoras). El daño potencial de actualizar “mal” es enorme (caídas, bloqueos, incidentes). En términos de negocio, la decisión correcta casi siempre es: actualizar rápido en staging, actualizar estable en producción. No al revés.

Nuestro Enfoque como Partner Digital: La Aplicación Zonsai

Cuando en Zonsai gestionamos tiendas WooCommerce, no tratamos las actualizaciones como “un clic”. Las tratamos como lo que son: cambios en un sistema de producción que factura.

¿Qué haríamos con un caso como este? Primero, un procedimiento: staging real, snapshot/backup verificable, actualización controlada, revisión de logs y monitorización de endpoints clave (admin-ajax, checkout, add-to-cart, APIs). Si algo rompe, se detecta en staging, no cuando el cliente te escribe “no puedo ver pedidos”.

Segundo, blindaje por arquitectura. Este tipo de bug (get_name() sobre false) suele emerger donde hay datos inconsistentes: productos eliminados, reseñas huérfanas, tipos de comentario mezclados por plugins. Nosotros analizamos el origen (qué “review” está entrando al widget, de dónde viene, qué plugin la genera, qué relación tiene con producto) y definimos una estrategia: o se normaliza el dato, o se ajusta el plugin responsable, o se aplica una mitigación temporal hasta el fix oficial.

Tercero, gobernanza de cambios. Si tu eCommerce depende de esto para vender, necesitas un ciclo de releases propio (aunque uses WordPress): calendario, ventanas de mantenimiento, criterio de actualización por criticidad, y un plan de rollback limpio. Lo contrario es vivir siempre al borde del incidente.

Conclusión: WooCommerce no “falló”. Falló el proceso de actualización

WooCommerce 10.5.0 trae mejoras y también ha dejado un bug muy concreto que, en ciertas tiendas, es suficiente para bloquear el admin por culpa del widget de reviews. Si estás a tiempo, esperar a 10.5.1 es prudente. Y si ya te ha golpeado, la salida profesional es rollback + análisis + actualización controlada cuando exista corrección. Si tu tienda es un canal serio de ventas, esto no se gestiona con “a ver si se arregla”: se gestiona con metodología y con una arquitectura que aguante el crecimiento. Justo ahí es donde un servicio como eCommerce conectado marca la diferencia: menos sustos, más control y una tienda pensada para operar, no para sobrevivir.

Este artículo se ha elaborado apoyándonos en automatización editorial con AI Feed Writer by Zonsai – Auto Feeds, Smart Content & AI.