WordPress y Bricks

Bricks 2.4: todas las novedades explicadas con casos prácticos

Bricks 2.4 conecta agentes de IA con WordPress, importa componentes entre webs, sincroniza CSS y rehace WooCommerce. Qué aporta cada novedad en un proyecto real.

Respuesta directa

Bricks 2.4, publicada el 16 de septiembre de 2026, es la actualización más ambiciosa de Bricks en años. Lo más llamativo es que agentes de IA como Claude Code o Codex pueden trabajar directamente sobre la web, pero hay mucho más: componentes que se importan de una web a otra, sistemas de diseño completos que viajan en un ZIP, CSS sincronizado con los controles visuales y un WooCommerce bastante más editable.

Mi resumen en una frase: Bricks deja de ser solo un constructor visual y se convierte en un entorno para producir webs WordPress con sistema.

Antes de seguir, una nota práctica: el 22 de septiembre salió la 2.4.1 con correcciones importantes. Si vas a actualizar, hazlo a la última versión estable, no a la 2.4 inicial.

Qué cambia de verdad

Hasta ahora, una web profesional con Bricks se construía combinando el Builder, el escritorio de WordPress, CSS a mano, variables, componentes, varios plugins y, cada vez más, un ChatGPT o un Claude abierto en otra ventana del que copiabas y pegabas.

Bricks 2.4 junta buena parte de esas piezas. Las novedades se pueden agrupar en cinco bloques:

  1. IA dentro del proyecto, no al lado.
  2. Reutilización entre webs: componentes y sistemas de diseño que se trasladan.
  3. Código y editor visual mejor avenidos.
  4. WooCommerce mucho más editable.
  5. El Builder como centro de trabajo, con menos saltos al escritorio de WordPress.

Voy bloque por bloque, con el caso real en el que tiene sentido cada cosa.

1. AI Abilities: la IA trabaja sobre Bricks, no a su lado

Es la novedad estrella. Bricks registra una serie de acciones en la Abilities API de WordPress y las expone mediante MCP (Model Context Protocol), el estándar con el que los agentes de IA se conectan a herramientas externas. Se configura desde Bricks → AI → Configuration, que instala o detecta el adaptador MCP, genera credenciales y da la configuración para cada cliente.

Un agente conectado puede trabajar con páginas, elementos, plantillas, componentes, clases globales, variables, paletas, consultas, menús, medios, revisiones, WooCommerce e importaciones. También puede convertir HTML y CSS en elementos editables de Bricks.

La diferencia con lo de antes es grande. Antes pedías «hazme el CSS de este layout» y lo copiabas a mano. Ahora puedes pedir esto y que se ejecute sobre la web:

Analiza las clases, variables y componentes existentes. Crea una landing para un servicio de diseño web para restaurantes usando solo el sistema de diseño actual. Reutiliza componentes cuando puedas y no crees clases duplicadas.

Caso práctico: una landing que respeta el sistema de diseño

En una web bien construida ya existen variables de espaciado (--space-s, --space-m…), colores de marca, clases de botones y contenedores, y componentes como la tarjeta de servicio o el bloque de llamada a la acción.

Si al agente le pides «haz una landing», saldrá algo genérico. Si le pides que trabaje dentro de ese sistema, el resultado es coherente con el resto de la web y mantenible por cualquiera que la conozca. Esa es la gracia.

Caso práctico: cambios repartidos por toda la web

El cliente decide, con la web terminada, cambiar el radio de botones y tarjetas. Si la web usa variables y clases, es un cambio pequeño. Lo que aporta el agente es la inspección: localizar qué clases usan ese valor, qué componentes se ven afectados y qué elementos se saltan el sistema.

Caso práctico: de HTML a Bricks

Un prototipo hecho en código, una sección heredada o un diseño generado con IA se pueden convertir en elementos editables sin reconstruirlos a mano. Útil para migraciones y pruebas rápidas de layouts. Eso sí, hay que revisar el resultado: que la IA cree elementos no significa que la estructura sea buena.

Skills: enseñar a la IA cómo se trabaja

Bricks añade también Skills, que no dan permisos nuevos: son instrucciones sobre cómo trabajar. Revisar primero el sistema de diseño, no duplicar clases, reutilizar variables, comprobar antes de guardar.

Para mí esta parte es casi tan importante como las propias Abilities. El futuro no es decirle a una IA «hazme una web». Es decirle «trabaja siguiendo estas reglas». Y esas reglas las define quien sabe cómo debe estar construida una web.

Lo que no haría: darle a la IA acceso de administrador

El agente actúa con los permisos del usuario de WordPress con el que se conecta. Bricks recomienda empezar en local o en staging, usar un usuario específico para el agente, desactivar las capacidades que no hagan falta y revisar las acciones destructivas antes de aprobarlas.

Estoy de acuerdo, y lo llevaría más lejos: nunca sobre la web en producción de un cliente mientras la función sea experimental, y con especial cuidado con cualquier capacidad que genere o ejecute PHP. Dar acceso total a un agente porque es cómodo es la forma más rápida de tener un problema.

2. Remote Components y Global Import & Export: tu propia biblioteca

Si trabajas con varias webs, esta es probablemente la novedad que más tiempo te va a ahorrar.

Remote Components permite importar componentes desde otra instalación de Bricks directamente en el Component Manager. Y no se trae solo el elemento: también sus dependencias, como componentes anidados, clases globales, variables, paletas e imágenes. Antes de importar comprueba los conflictos de nombres.

Global Import & Export va un paso más allá: exporta en un ZIP el sistema completo de un proyecto. Theme Styles, clases y sus categorías, variables, paletas, breakpoints, componentes, plantillas, fuentes, iconos, consultas globales y configuración del Builder. Al importar eliges qué entra, revisas dependencias y resuelves conflictos.

Caso práctico: el arranque de una web nueva

Mantienes una instalación que hace de biblioteca con tu cabecera, pie, hero, tarjetas, preguntas frecuentes, formularios y bloques de precios. Y un sistema base con variables, colores, clases y breakpoints.

Al empezar un proyecto importas el sistema base, traes los componentes que necesitas y adaptas marca, tipografías y espaciado:

--primary: #1f4d3a;
--secondary: #f2b705;
--font-heading: 'Fraunces', serif;
--font-body: 'Inter', sans-serif;

Toda la web se adapta. Desde el primer minuto tienes una base coherente.

Por qué esto importa también al cliente

La ventaja no es solo la velocidad. Uno de los grandes problemas de WordPress es que cada web está construida de una forma distinta, y el siguiente que la toca tarda semanas en entenderla. Con una arquitectura estándar, cualquier desarrollador sabe dónde está cada cosa, los errores se corrigen antes y la web sigue siendo mantenible dentro de dos años.

Un detalle bien resuelto: el componente importado es una copia local. No queda conectado a la biblioteca, así que un cambio accidental allí no rompe cincuenta webs de golpe.

3. Component Manager: saber qué componentes existen y dónde se usan

El nuevo gestor permite buscar y filtrar componentes, ver cuáles se usan en la página actual o en el resto del sitio, detectar los que no se usan, generar capturas, duplicar, exportar y eliminar.

Caso práctico: limpiar después de un rediseño

Tras meses de trabajo es habitual encontrar «Tarjeta servicio», «Tarjeta servicio v2», «Tarjeta servicio final» y tres versiones del bloque de llamada a la acción. Con el filtro de uso ves cuáles están vivos y borras el resto. Menos confusión y menos riesgo de editar el componente equivocado.

4. Builder Browser y Pages Panel: menos saltos al escritorio de WordPress

Builder Browser reúne en el propio constructor páginas y demás tipos de contenido, plantillas, componentes y medios. El Pages Panel se rediseña con búsqueda, favoritos y metadatos, y recuerda tus preferencias entre sesiones.

En una web con 40 servicios, 80 localidades y cientos de artículos solo trabajas activamente con unas pocas páginas. Marcarlas como favoritas y saltar entre ellas sin salir del Builder parece poca cosa, hasta que pasas ocho horas al día dentro.

5. CSS Sync: el CSS y los controles visuales, por fin sincronizados

Función experimental que se activa en Bricks → Settings → Builder → CSS Sync. Sincroniza en ambos sentidos el Custom CSS y los controles visuales, respetando el breakpoint y el pseudoestado activos.

Escribes esto en el CSS del elemento:

%root% {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: var(--space-m);
}

Y los controles de rejilla y espaciado reflejan esos valores. Si los cambias desde el control, se actualiza el CSS.

Hasta ahora había una frontera incómoda entre lo que configurabas visualmente y lo que escribías a mano, y era fácil acabar con estilos duplicados que se pisaban. CSS Sync permite trabajar de forma híbrida: controles cuando es más rápido, código cuando lo es el código.

Como es experimental, no montaría todavía un sistema de producción apoyado en ella sin probarla antes. De hecho, la 2.4.1 ya corrige un fallo con reglas de descendientes.

Relacionado: ahora se pueden copiar, mover y resetear estilos entre breakpoints con más precisión, incluidos selectores y pseudoclases. Adiós a esos estilos responsive que se acumulan y nadie recuerda por qué están ahí.

6. Perfiles de interfaz: cada usuario ve el Bricks que necesita

Se puede mover la barra de herramientas, cambiar paneles de sitio, reorganizar y fijar controles, ocultar acciones y crear accesos directos. Todo se guarda en perfiles asignables a usuarios o roles, e importables y exportables.

Caso práctico: entregar la web al cliente

El desarrollador necesita estructura, CSS, clases y variables. El cliente que edita su web solo necesita cambiar textos, imágenes y algún componente. Darle un perfil simplificado reduce errores y le quita el miedo a tocar la web. Es de las mejoras que más se van a notar en el día a día de quien tiene una web con Bricks sin ser desarrollador.

7. Media Browser y Media Health: imágenes bajo control

El nuevo navegador de medios trabaja sobre la biblioteca de WordPress de siempre, pero desde el Builder: búsqueda, filtros, subida, edición de metadatos, selección múltiple y acciones en lote.

Dentro está Media Health, que detecta imágenes sin texto alternativo, archivos rotos, tamaños inexistentes, archivos demasiado pesados (por defecto avisa a partir de 1 MB) y formatos obsoletos.

Antes de entregar una web, una revisión así puede sacar «12 imágenes sin ALT, 3 de más de 1 MB y una rota». Corregirlo antes de que llegue al cliente es accesibilidad, SEO y velocidad a la vez. Las imágenes pesadas siguen siendo la primera causa de un WordPress lento.

También mejora la integración con Unsplash: eliges el tamaño de descarga (de 640 px al original) en lugar de bajarte una foto de 6000 píxeles para mostrarla a 800.

8. Formularios más inteligentes

Acciones condicionales. Cada acción del formulario puede ejecutarse solo si se cumplen condiciones (es, no es, contiene, está vacío…), combinables con AND u OR. Probablemente sea de las funciones más útiles de la versión y de las que menos ruido harán.

El caso más claro es el consentimiento comercial:

  • Enviar el correo al negocio: siempre.
  • Guardar el registro: siempre.
  • Añadir a la lista de marketing: solo si la casilla de consentimiento está marcada.

Es lo correcto, también desde el punto de vista de protección de datos. Y otro caso: según el servicio que elija el usuario, activar una integración u otra, sin código a medida.

Además, la acción Create Post puede asignar o crear taxonomías desde un campo de texto (útil para directorios o portales colaborativos, con moderación), y Cloudflare Turnstile puede cargarse de forma diferida para no penalizar la carga de páginas con formulario.

9. WooCommerce: el gran salto para tiendas

Es el área que más cambia.

Woo Setup Wizard revisa tienda, ficha de producto, carrito, checkout y Mi cuenta, muestra el estado de cada zona y puede crear o reparar la estructura, tanto clásica como v2. Resuelve la eterna pregunta de «¿esto se edita en la página, en una plantilla o en un shortcode?». En una tienda existente, lee con calma el resumen antes de aplicar nada: puede sustituir contenido o pasar a borrador plantillas que choquen.

Cart v2, Checkout v2 y My Account v2 (experimentales) permiten diseñar desde Bricks los distintos estados:

  • Carrito con productos y carrito vacío, este último con productos recomendados en lugar del típico mensaje triste.
  • Checkout, pago, página de gracias y recibo del pedido, con datos dinámicos: «Gracias, Marta. Tu pedido #1234 está confirmado», con resumen, instrucciones y siguiente paso.
  • Checkout por pasos (datos, envío, revisión, pago) manteniendo el flujo nativo de WooCommerce. Útil en reservas, productos personalizados o pedidos B2B. Pero no asumiría que convierte mejor: eso se prueba en cada tienda.
  • Mi cuenta integrada con la estética del resto de la web.

Sincronización de campos del checkout. Si un plugin añade NIF/CIF o campos fiscales, Checkout v2 detecta campos nuevos, inexistentes, duplicados o con etiquetas cambiadas. Muy relevante en tiendas españolas con clientes de empresa.

Mini Cart Builder y Dynamic Fragment. Un minicarrito editable por AJAX, y un elemento que se vuelve a pintar cuando cambia el carrito. El ejemplo clásico: una barra que dice «te falta poco para el envío gratis» y cambia a «ya tienes envío gratis» al añadir un producto, sin recargar.

Completan el bloque un filtro de stock que tiene en cuenta las variaciones, cantidades de variaciones dentro de listados (muy útil para pedidos mayoristas) y la etiqueta dinámica {woo_product_gtin}.

10. Otras novedades que merece la pena conocer

Novedad Para qué sirve
Elemento File Mostrar o descargar archivos, con vista previa de PDF (la carta de un restaurante, temarios)
Countdown con datos dinámicos Una cuenta atrás distinta para cada evento desde un campo personalizado
Query Loop por autores Listados como «Artículos de María» sin código
Submit Filter y Search con redirección Buscadores que aplican filtros al pulsar un botón o llevan a una página de resultados
Viewport con porcentaje visible Animaciones que arrancan cuando se ve, por ejemplo, el 60 % del bloque
Offcanvas responsive Panel lateral en escritorio y desde abajo en móvil
Menú con etiquetas por dispositivo «Solicitar presupuesto» en escritorio, «Presupuesto» en móvil
Paletas sincronizadas con Gutenberg El cliente escribe en el editor de bloques con los colores de marca, no con colores al azar
Theme Styles en el panel de controles Buscar y filtrar solo los valores modificados para encontrar ese estilo global que lo cambia todo
CSS desde Class Manager Editar el CSS de una clase sin buscar antes un elemento que la use
Componentes en Command Palette Insertar componentes sin rebuscar en paneles
Licencia por constante PHP BRICKS_LICENSE_KEY para instalaciones clonadas y despliegues automatizados

Una advertencia sobre la firma automática de código en desarrollo: viene desactivada, está pensada para entornos locales y sus constantes empiezan por BRICKS_DANGEROUSLY_. El nombre ya lo dice todo. No la activaría en producción para ahorrarme un clic.

¿Merece la pena actualizar a Bricks 2.4?

Sí, pero no a lo loco. En una web nueva o en desarrollo, tiene sentido empezar ya con AI Abilities, Builder Browser, Remote Components, Global Import & Export y los perfiles.

En una web en producción, y sobre todo si tiene WooCommerce, mucho CSS personalizado, formularios complejos o complementos de terceros para Bricks, el procedimiento es el de siempre:

copia de seguridad → staging → actualización → pruebas → producción

En una tienda comprobaría carrito, checkout, todos los métodos de pago, variaciones y correos de pedido antes de dar nada por bueno. Y actualizaría directamente a la última versión estable de la rama 2.4, que ya incluye las primeras correcciones.

Si tu web está hecha con Bricks y no tienes claro cómo hacer esto sin riesgo, es justo lo que cubre un mantenimiento web bien hecho: actualizar probando antes, no cruzando los dedos.

¿La IA va a sustituir al desarrollador de Bricks?

No lo creo. Más bien lo contrario.

Cuanto más pueda construir la IA, más importa que exista una buena arquitectura sobre la que trabajar: clases, variables, componentes, permisos, convenciones, responsive, accesibilidad y rendimiento. Pedirle a una IA «hazme una web» seguirá dando resultados mediocres, con los mismos errores de siempre. Darle un sistema de diseño, componentes bien hechos, reglas y permisos controlados es otra cosa.

Bricks 2.4 no hace que deje de ser necesario saber construir buenas webs. Hace que sea todavía más importante saber cómo deben estar construidas.

Qué significa para ti

Si tienes una web con Bricks, puedes aprovechar muchas de estas mejoras sin rehacer nada: perfiles para editar tú sin miedo, Media Health para limpiar imágenes, formularios condicionales. Lo que no conviene es actualizar a ciegas.

Si tu web está hecha con Elementor y va lenta o es imposible de mantener, Bricks 2.4 amplía la distancia. Te cuento cuándo compensa migrar de Elementor a Bricks y cuándo no.

Si eres una agencia y quieres montar tu biblioteca de componentes, un sistema base o probar AI Abilities en proyectos reales sin dedicarle tus propias horas, es el tipo de trabajo que hago en colaboración con agencias, también en marca blanca.

En los próximos meses voy a probar a fondo la combinación de Bricks con Claude y Codex en proyectos reales. Lo interesante no será pedirle a una IA que haga una web, sino conseguir que trabaje respetando un sistema de diseño bien construido.

Siguiente paso

Si quieres una web con WordPress y Bricks montada con sistema desde el principio, o actualizar la que tienes sin romper nada, cuéntamelo en el estudio de proyecto y lo vemos.

Preguntas frecuentes

¿Cuándo salió Bricks 2.4?

El 16 de septiembre de 2026. Seis días después, el 22 de septiembre, salió la 2.4.1 con correcciones en CSS Sync, WooCommerce, plantillas remotas y permisos. Si vas a actualizar ahora, instala la última versión estable de la rama 2.4, no la 2.4 inicial.

¿Puedo conectar Claude o Codex con Bricks?

Sí. Bricks 2.4 incorpora AI Abilities, que permiten a clientes compatibles con MCP, como Claude Code o Codex, consultar y modificar páginas, componentes, clases, variables y otras partes de la web. Es una función experimental y conviene probarla primero en local o en staging.

¿Los Remote Components se actualizan solos?

No. Al importar un componente se crea una copia local. Bricks guarda de dónde viene para detectar cambios si lo vuelves a importar, pero no hay sincronización permanente. Es lo sensato: un error en la biblioteca central no rompe todas las webs a la vez.

¿Puedo usar Checkout v2 en una tienda que ya factura?

Se puede, pero no directamente en producción. Los elementos WooCommerce v2 están marcados como experimentales. Lo probaría en staging con pedidos reales de prueba, todos los métodos de pago y los correos de pedido antes de cambiar nada en la tienda.

¿Tengo que rehacer mi web para aprovechar Bricks 2.4?

No. La web sigue funcionando igual después de actualizar. Las novedades se aprovechan poco a poco, y las que más rinden, como la IA o los componentes remotos, dependen de que la web ya tenga clases, variables y componentes bien organizados.