Cuando trabajamos con sitios multilingües en WordPress, una combinación común es Bricks Builder junto con Polylang. Funciona muy bien… hasta que una actualización cambia las reglas del juego.
En mi caso, todo el proyecto que había configurado para un cliente dejó de funcionar tras actualizar a Bricks 2.0: los headers y footers no se mostraban en ninguno de los idiomas y las plantillas globales parecían “desaparecidas”.
Investigando en el foro oficial de Bricks y en su documentación, descubrí que el problema no era un bug aislado, sino un cambio importante en cómo Bricks gestiona las plantillas cuando Polylang está activo. En este artículo te cuento qué pasó, por qué ocurre y dos formas de solucionarlo: configurando condiciones o aplicando un filtro de código.
Qué cambió en Bricks 2.0 y rompió la compatibilidad
Hasta la versión 1.12.4, Bricks soportaba dos escenarios:
- Plantillas administradas por Polylang: si activabas “Mis plantillas” en Polylang, podías traducirlas y Bricks funcionaba bien.
- Plantillas no administradas por Polylang: si no querías que Polylang gestionara esas plantillas, Bricks igualmente las usaba sin problema.
Con la llegada de Bricks 2.0, este comportamiento cambió:
- El tipo de publicación bricks_template ahora siempre es gestionado por Polylang.
- No hay opción para excluir las plantillas de la traducción.
- Esto rompe los sitios que usaban plantillas globales sin traducción (headers, footers, plantillas de archivo, etc.).
En otras palabras, Bricks asume que todas las plantillas deben estar localizadas, y si no lo están, simplemente no se cargan. 🥴
Cómo identifiqué el problema
- Tras la actualización, las plantillas dejaron de mostrarse en el front-end.
- En el panel de Polylang, noté que ya no podía controlar el tipo de publicación “Mis plantillas”.
- En el foro de Bricks encontré usuarios reportando lo mismo y explicando que era un cambio deliberado en la versión 2.0.
Solución 1: Configurar condiciones manualmente (recomendado por Bricks)
Bricks ahora permite definir condiciones por idioma en cada plantilla. Esto es ideal si realmente quieres traducir y gestionar plantillas para cada idioma.
Pasos:
- Ve a Bricks → Plantillas en tu panel de WordPress.
- Abre tu header, footer u otras plantillas globales.
- En la pestaña Condiciones, añade manualmente la condición “Idioma = Español” o “Idioma = Inglés”, según corresponda.
- Duplica plantillas si necesitas versiones separadas para cada idioma.
- Guarda y prueba el front-end.
Este método es ideal si quieres trabajar con traducciones y tener control granular sobre cada plantilla.
Solución 2: Usar un filtro (para volver al comportamiento anterior 👌🏻)
Si tu flujo de trabajo no necesita traducir plantillas y prefieres que todas se apliquen globalmente, puedes excluir bricks_template del control de Polylang usando este filtro:
add_filter('pll_get_post_types', function( $post_types, $is_settings ) {
unset( $post_types['bricks_template'] );
return $post_types;
}, 99, 2);
Dónde colocarlo:
- En el archivo functions.php de tu tema hijo
- En un plugin personalizado de funciones.
- O en code snippets
Esto hace que Bricks vuelva a manejar las plantillas como antes de la versión 2.0 (sin localización obligatoria).
Qué método elegir
- Si necesitas traducir plantillas: usa la solución 1 con condiciones manuales.
- Si no necesitas traducción en plantillas: usa la solución 2 con el filtro en functions.php. (que fue la que yo use en el proyecto de mi cliente).
Consejos para prevenir futuros problemas
- Prueba las actualizaciones en un entorno de staging antes de aplicarlas en producción.
- Revisa siempre los changelogs de Bricks y las notas de compatibilidad de Polylang.
- Documenta tu configuración multilingüe para restaurarla fácilmente si algo falla.
La incompatibilidad entre Polylang y Bricks 2.0 con las plantillas del constructor no es un bug como tal, sino un cambio en cómo Bricks maneja la localización de plantillas. Conociendo el nuevo comportamiento, puedes adaptar tu flujo de trabajo configurando condiciones o aplicando el filtro que excluye bricks_template de Polylang.
A mí me salvó este ajuste y pude restaurar el sitio de mi cliente sin perder tiempo rehaciendo plantillas. Si te ha pasado lo mismo, prueba estas soluciones y cuéntame en los comentarios qué resultado te dieron.
