Recuperación Divi Tras Mala Actualización — Procedimientos de Restauración de Layout

Por qué las actualizaciones Divi son únicamente riesgosas

Divi es un tema, page builder y ecosistema de módulos todo en uno. Cuando ElegantThemes envía una actualización, puede simultáneamente cambiar templates del tema, comportamiento del builder y renderizado módulo-por-módulo. Cualquiera de esas tres capas rompiéndose puede arruinar un layout.

Peor: Divi guarda layouts como JSON serializado en wp_postmeta. Si el schema cambia entre versiones, tus datos viejos pueden no round-trip limpiamente. Los layouts se ven correctos en el builder pero renderizan rotos en front-end. O viceversa.

Este artículo es nuestro playbook de recuperación Divi — cinco procedimientos para los cinco escenarios de rotura más comunes.

Escenario 1 — Todas las secciones muestran "vacío" en front-end

Tras actualización, páginas construidas con Divi no muestran contenido. El builder las carga bien, pero front-end está en blanco.

Diagnóstico

Abre DevTools del navegador → Console en la página rota. Busca errores JS. Patrón común:

Uncaught TypeError: Cannot read property 'modules' of undefined
  at et_pb_section.js:1247

Este es el bundle de módulos de Divi fallando al encontrar datos que espera. Causa: cache manteniendo JS Divi obsoleto mientras la estructura de datos cambió.

Recuperación

# Limpia el propio cache de Divi
wp option delete et_divi_dynamic_assets_clear_time
wp option delete et_divi_cached_data

# Limpia cache de página
wp cache flush

# Regenera CSS estático
# Visita cualquier página → Divi → Theme Options → Builder → Advanced → Static CSS File → Clear

Si aún roto, fuerza a Divi a regenerar editando una página (solo ábrela y re-guarda).

Escenario 2 — Spacing/styling todo desplazado

La actualización completó. Las páginas se ven "cerca" de antes pero márgenes, paddings, tamaños de fuente están mal. Mobile responsive específicamente puede romperse.

Diagnóstico

Divi 4.x → 4.18+ cambió cómo el CSS responsive se genera. Los layouts viejos dependen de la estructura vieja de output CSS.

Recuperación

En Divi → Theme Options → General → Performance:

Deshabilita Dynamic CSS
Deshabilita Dynamic Module Framework
Deshabilita Critical CSS

Después re-habilita uno a la vez, probando el layout entre cada uno.

Algunos sitios no pueden usar Dynamic CSS con sus layouts existentes. Quédate con la generación CSS vieja (estática) hasta que puedas reconstruir layouts en el sistema nuevo.

Escenario 3 — Módulos específicos renderizan con errores

Módulos particulares (a menudo Blurb, Slider, Call to Action) muestran iconos de error en el builder o renderizan rotos en front-end.

Diagnóstico

Estos son usualmente módulos donde Divi cambió el schema de datos. Los datos serializados viejos tienen campos que el módulo nuevo no entiende, o viceversa.

-- Encuentra páginas usando módulos afectados
SELECT post_id, meta_value FROM wp_postmeta 
WHERE meta_key = '_et_pb_old_content' 
  AND meta_value LIKE '%et_pb_blurb%'
LIMIT 10;

Recuperación

Opción A: Resetea módulo a default

Abre la página en builder Divi. Encuentra el módulo roto. Clic derecho → Reset. Configura desde cero. Tedioso pero confiable.

Opción B: Guardó template del módulo antes de la actualización rota

Si tienes un backup reciente, restaura el post_content y meta de la página afectada desde ahí:

UPDATE wp_posts SET post_content = '<old content>' WHERE ID = 123;
UPDATE wp_postmeta SET meta_value = '<old serialized>' WHERE post_id = 123 AND meta_key = '_et_pb_old_content';

Opción C: Usa el import de Divi en un export de template de backup

Si exportaste layouts como Divi Library antes de la actualización (deberías hacer esto rutina), importa el JSON del layout viejo vía Divi → Divi Library → Import.

Escenario 4 — Builder no carga, overlay de "JavaScript error"

Intentas editar cualquier página con Divi. El builder muestra un overlay negro con mensaje "JavaScript error".

Diagnóstico

Esto es casi siempre un conflicto de plugin o tema. El builder de Divi es sensible a: - Cambios de orden de carga jQuery - Otros plugins enqueueando versiones de React conflictivas - Plugins de caching sirviendo JS Divi obsoleto

Recuperación

Deshabilita todos los plugins excepto Divi
Cambia a un tema default (Twenty Twenty-Four) — solo si tienes un child theme al cual volver
Prueba el builder
Si funciona, reactiva plugins uno por uno
El primer plugin que rompe el builder es tu culpable

Workaround para caching

# Fuerza limpieza de todas las capas de caching
wp cache flush
wp transient delete --all

# Si usas un CDN, purgálo
# Si usas un cache de hosting (WP Engine, Kinsta), usa su dashboard para purgar

# Añade un query string para forzar refresh del navegador
# Visita yoursite.com/wp-admin/post.php?post=123&action=edit&et_fb=1&forceversion=1

Escenario 5 — Headers/footers faltan completamente

Usas Divi Theme Builder para crear headers/footers custom. Tras actualización, no aparecen; el template default del tema carga.

Diagnóstico

wp option get et_theme_builder

Si esto devuelve nada o muestra templates vacíos, los datos de Theme Builder se perdieron.

Recuperación

Si tienes un backup de antes de la actualización:

# Restaura la opción del backup
wp db import partial-restore.sql --tables=wp_options

Si no hay backup:

Ve a Divi → Theme Builder
Da clic en "Import & Export"
Si exportaste templates antes, impórtalos
De lo contrario, reconstruye los templates (header, footer, single, archive)

Hacia adelante: siempre exporta templates de Theme Builder como JSON antes de cualquier actualización Divi. Esta es una tarea de 30 segundos que ahorra horas de trabajo de recuperación.

Setup de prevención

Tras recuperación, previene futuros desastres de actualización Divi:

# Cron: export semanal de templates Divi y library
0 3 * * 1 cd /var/www/yoursite && wp eval 'do_action("et_theme_builder_export_templates_cron");'

# Cron: backup diario de base de datos
0 2 * * * cd /var/www/yoursite && wp db export /backups/db-$(date +\%Y\%m\%d).sql && find /backups -mtime +30 -delete

Procedimiento manual antes de cualquier actualización Divi:

Exporta templates Theme Builder (Divi → Theme Builder → Import & Export)
Exporta Divi Library (Divi → Divi Library → Import & Export)
Backup completo de base de datos
Prueba actualización en staging
Prueba 5+ páginas con todos los tipos mayores de módulos
Solo entonces actualiza producción

Eligiendo si quedarse o migrar

Si tu sitio ha tenido 2+ incidentes de actualización Divi, considera migración:

Por qué la gente deja Divi - Los datos de layout están atrapados en formato serializado (difícil de exportar a otra cosa) - El riesgo de actualización concentra muchos modos de fallo en un vendor - Overhead de rendimiento vs. builders más ligeros (Bricks, Gutenberg)

Por qué la gente se queda - Inversión existente en layouts custom - Familiaridad del equipo - Módulos Divi específicos sin equivalente

Si te quedas, sigue este playbook estrictamente. Si migras, planea un proyecto de 2-4 semanas incluyendo extracción de contenido, reconstrucción en sistema nuevo, mapeo de redirects.

Errores comunes durante recuperación Divi

Restaurar de backup sin identificar qué se rompió — repetirás la actualización y se romperá igual
Deshabilitar Dynamic Assets permanentemente — arregla problema inmediato, pero acepta una penalidad permanente de perf
Editar JSON serializado manualmente — casi garantizado corromper; usa las herramientas de Divi en su lugar
Saltar staging porque "las actualizaciones Divi raramente rompen" — cuando rompen, rompen dramáticamente

Cuándo llamar a un especialista

Hemos recuperado sitios Divi con 1000+ páginas de layout roto. La recuperación es metódica: identifica qué tipo de rotura, aplica el procedimiento que coincide, verifica por página. Tiempo típico 4-12 horas.

Recuperación Divi para problemas del builder. Para trabajo más amplio de plugins ve reparación de conflictos de plugin.