Bricks Builder en blanco después de actualizar: cómo lo resolví (y por qué no era lo que parecía)

El escenario

Una web con Bricks Builder 1.9.x. Actualización directa a la versión 2.3 saltándose todas las versiones intermedias. A partir de ahí, algunas páginas se quedan completamente en blanco al intentar editarlas. Otras cargan el panel de estructura pero el canvas no renderiza nada. El frontend, perfecto.

Adicionalmente, la web había sufrido un hackeo semanas antes y se había instalado Imunify Security para limpiarla. Dato relevante, como veremos.

Lo que fui descartando

¿Problema de migración de datos entre versiones de Bricks?

Primera hipótesis: el salto de 1.9 a 2.x cambia el formato interno de los datos. Bricks 2.0 introdujo cambios importantes en el sistema de renderizado y en la estructura de los elementos.

Revisé la base de datos. El campo _bricks_page_content_2 de las páginas problemáticas tenía los datos en formato PHP serializado (a:58:{...}), el formato de Bricks 1.9. Las páginas nuevas lo tenían en JSON ([{...).

Parecía la causa. Preparé un script para convertir todos los datos de PHP serializado a JSON:

<?php
require_once('wp-load.php');
if (!current_user_can('manage_options')) die('No autorizado');

global $wpdb;
$rows = $wpdb->get_results(
    "SELECT post_id, meta_value FROM {$wpdb->postmeta} 
     WHERE meta_key = '_bricks_page_content_2' 
     AND meta_value LIKE 'a:%'"
);

foreach ($rows as $row) {
    $data = unserialize($row->meta_value);
    if ($data === false) continue;
    $json = json_encode(array_values($data), JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
    update_post_meta($row->post_id, '_bricks_page_content_2', $json);
    echo "✅ ID {$row->post_id}: convertido<br>";
}

Lo ejecuté. Convirtió las páginas. Probé el editor. Seguía en blanco.

¿Problema con _bricks_page_settings?

Las páginas antiguas tenían una meta adicional que las nuevas no tenían: _bricks_page_settings, también en formato PHP serializado. La borré. Sin cambios.

¿Conflicto de plugins o restos del hackeo?

Revisé los logs del servidor. Apareció esto:

AH01071: Got error '; PHP message: PHP Fatal error: 
WP_HTML_Tag_Processor::apply_attributes_updates(): 
Cannot use output buffering in output buffering display handlers 
in /wp-includes/html-api/class-wp-html-tag-processor.php on line 2536'

Ese error es específico: algo está usando ob_start() con un callback dentro de un display handler, y el WP_HTML_Tag_Processor de WordPress 6.5+ no lo tolera.

Busqué en el servidor todos los archivos con ob_start fuera del core:

grep -rn "ob_start" /var/www/vhosts/tudominio.es/httpdocs/wp-content --include="*.php" | grep -v "wp-rocket" | grep -v "complianz" | grep -v "bricks"

Aparecieron cientos de resultados, todos de plugins legítimos. El más sospechoso: EWWW Image Optimizer, que usa ob_start('ewww_image_optimizer_filter_page_output') — con callback, exactamente lo que provoca el error.

La causa real: memoria insuficiente

Con WP Rocket activo y el editor de Bricks 2.x cargando, la web se quedaba sin memoria. El límite estaba configurado a 128MB — probablemente ajustado a la baja después del hackeo como medida de seguridad del servidor.

128MB era suficiente con Bricks 1.9. Bricks 2.x tiene un motor de renderizado completamente nuevo, más pesado. Combinado con el procesamiento de WP Rocket, superaba el límite disponible. El resultado era ese error críptico de output buffering que en realidad era un síntoma, no la causa.

En wp-config.php:

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Y en .htaccess o php.ini según el hosting:

php_value memory_limit 512M

Con eso, el editor cargó perfectamente con todos los plugins activos.

Resumen del diagnóstico

Hipótesis	Resultado
Datos en PHP serializado vs JSON	No era la causa principal
Meta _bricks_page_settings corrupta	No era la causa
Conflicto de plugins / malware	Descartado
Memoria PHP insuficiente (128MB)	✅ Causa real

La lección: memoria antes que base de datos

Cuando el editor de Bricks falla pero el frontend funciona, y el error en logs habla de output buffering, antes de mirar la base de datos o los plugins mira la memoria disponible. Es el tipo de problema que no da un mensaje de error claro y se disfraza de conflicto entre componentes.