Bricks acaba de soltar la 2.4 en beta y trae uno de los lanzamientos más grandes de los últimos meses: automatización con IA, gestión de componentes, portabilidad del sistema de diseño y un WooCommerce reconstruido.

⚠️ Ojo: es una beta. Está pensada para probar y reportar bugs. No la instaléis en sitios en producción. Se descarga manualmente desde vuestra cuenta en my.bricksbuilder.io.

Estos son los puntos que más nos interesan 👇

🤖 Bricks AI Abilities (esto es lo gordo)

Bricks incorpora conexión nativa con clientes MCP —Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI…— para crear y editar contenido y datos globales de Bricks directamente desde la IA. Hay una pantalla nueva Bricks > IA con controles de capacidades, configuración del cliente y estado de conexión. Cubre páginas, elementos, plantillas, componentes, sistema de diseño, query loops, WooCommerce, conversión de HTML a Bricks e import/export.

Para quienes ya trabajáis con IA sobre Bricks, este es el cambio que más va a mover la aguja.

🗂️ Builder Browser y gestor de componentes

Un panel central para administrar plantillas, componentes y post types de Bricks. La gestión de componentes crece muchísimo: búsqueda y filtros, información de uso, capturas, duplicar/exportar/eliminar y mejor manejo de dependencias al importar.

📦 Import/Export global del sistema de diseño

Ahora puedes mover tu sistema de diseño completo entre sitios con un flujo basado en ZIP: theme styles, clases y variables globales, paletas de color, breakpoints, componentes, plantillas, fuentes e iconos, query loops y ajustes. Eliges qué importar, revisas dependencias y resuelves conflictos con un resumen claro antes de aplicar nada.

🧩 Interfaz del builder a tu gusto (perfiles)

Coloca la barra de herramientas en cualquier lado del lienzo, mueve los paneles, crea layouts propios, reordena u oculta acciones y añade atajos. Todo se guarda como perfil reutilizable asignable por usuario o rol, y transferible entre sitios.

🛒 WooCommerce: asistente de configuración + elementos V2

Un nuevo asistente reúne carrito, checkout, mi cuenta, tienda y producto en un solo sitio. Los elementos experimentales Cart, Checkout y Account V2 manejan varios estados dentro de un mismo elemento (carrito lleno/vacío, checkout multipaso, login, dashboard…). Además, un Mini Cart Builder con actualizaciones AJAX.

🎨 CSS Custom ↔ controles de estilo, sincronizados

Función experimental: cambias una propiedad en el editor de CSS custom y su control de estilo se actualiza solo, y al revés. Respeta el breakpoint y la pseudoclase activos, sin tocar el CSS no relacionado. Se activa en Bricks > Ajustes > Builder > CSS Sync.

🛠️ Y muchas mejoras del día a día

Pantallas de admin renovadas y más accesibles, buscador de ajustes, paleta de color dentro del Variable Manager, papelera para variables, panel de páginas rediseñado con favoritos, copiar/mover estilos entre breakpoints, carga más rápida del builder, navegación instantánea por defecto, buscar y reemplazar en el editor de código, y la clave de licencia definible por constante (BRICKS_LICENSE_KEY), ideal para blueprints y despliegues automatizados.

📋 Changelog completo: https://bricksbuilder.io/release/bricks-2-4-beta/

👉 ¿Cuál es la que más ganas tenéis de probar? A nosotros la conexión con IA nos tiene el ojo puesto. Contadnos en comentarios 👇

El equipo de Bricks ha publicado la versión 2.3.9. Se trata de una actualización de mantenimiento que prioriza la fiabilidad: reúne 4 mejoras y 23 correcciones de errores, con especial atención a las variantes de componentes, los formularios, la integración con WooCommerce y el renderizado en el frontend.

No hay funcionalidades nuevas en esta entrega, pero sí un buen número de arreglos que afectan a flujos de trabajo habituales, por lo que la actualización es recomendable para cualquier sitio en producción.

Mejoras destacadas

• Variantes de componentes: mejor gestión de las referencias a variantes que han sido eliminadas, evitando inconsistencias en el diseño.
• Precarga de fuentes personalizadas: documentación más clara sobre su comportamiento.
• Lightbox: las etiquetas de los botones de PhotoSwipe ahora son traducibles (localizables).
• Gestor de estilos: el control «Outline» se alinea con el orden del resto de controles de estilo base, para una edición más coherente.

Correcciones más relevantes

Entre las 23 correcciones, las que más impacto tienen en el día a día son:

• WooCommerce: solucionados problemas con las variaciones de producto y con los parámetros de búsqueda.
• Formularios: corregidos fallos en campos de ACF y en las propiedades de email personalizadas.
• Query loop: se dejaban de aplicar algunos parámetros al paginar mediante AJAX; ya funciona correctamente.
• Variantes de componentes: resueltos varios problemas de herencia de estilos y de CSS que no se generaba.
• Editor de bloques (Gutenberg): los componentes raíz provocaban redirecciones dentro de iframes.
• Seguridad en el constructor: se corrige un caso en el que las restricciones de acceso a elementos podían saltarse durante la edición en el lienzo.
• ACF: eliminadas peticiones HTTP innecesarias al mismo origen durante el «inlining» de iconos SVG.
• Vídeos de fondo de YouTube: las dimensiones no se recalculaban al redimensionar la ventana del navegador.

¿Debo actualizar?

Sí. Al ser una versión de estabilidad, no introduce cambios que rompan diseños existentes y corrige errores que afectan a formularios, tiendas WooCommerce y componentes. Como siempre, recomendamos hacer una copia de seguridad y probar primero en un entorno de staging antes de aplicarla en producción.

🔗 Notas de la versión completas: bricksbuilder.io/release/bricks-2-3-9

Release de mantenimiento de la rama 4.3, centrada en correcciones y estabilidad. Lo que más nos interesa:

Builds más estables — arreglados los cierres de Vite en HMR al borrar archivos, y el --watch de la CLI ahora se recupera y reconstruye bien.

 text-[--spacing(…)] corregido — ahora genera font-size en vez de color. Importante si atas tamaños de texto a la escala de spacing.

auto-rows-* / auto-cols-* con valores sueltos — ya puedes usar auto-rows-12 o auto-cols-16 sin corchetes.

@source más limpio — deja de escanear archivos hermanos no relacionados: builds más rápidos.

@variant dentro de addBase(…) puede usar variantes custom definidas después, y mejores sugerencias de opacidad desde los tokens --opacity.

En Flowtitude trabajamos sobre Tailwind v4, así que estas correcciones entran directas en nuestro flujo con Bricks y el FDS. Nada que reescribir: solo más estabilidad.

Esperemos que pronto quede esta version integrada en Windpress!

Acaba de salir Bricks 2.3.8. Es una release de mantenimiento: sin funciones nuevas, sobre todo correcciones.

La mayoría van a componentes con slots, query loops y bloques de Gutenberg. Y un arreglo que nos toca de cerca: el de clases globales sobrescribiendo estilos de elemento en Gutenberg.

¿Por qué con cuidado?

Porque esos arreglos caen justo en lo que más usamos: clases globales y componentes. Y la rama 2.3 viene movidita ahí — en 2.3.7 hubo un fallo en la generación de CSS de clases globales (un desajuste de índices que dejaba clases sin su CSS).

Un «fix» no siempre es neutro: si tu proyecto compensaba un comportamiento anterior, al corregirlo puede cambiar lo que veías.

Antes de actualizar en producción:

Hazlo primero en staging.

Comprueba que tus clases globales (FDS incluido) siguen generando su CSS.

Revisa los componentes con slots y los loops: que se rendericen como esperas.

Y si usas IA sobre el árbol de Bricks, valida que sigue leyendo y escribiendo bien tras el cambio.

Después, a producción.

¿Ya has actualizado a 2.3.8? ¿Has notado algo raro con clases globales o componentes? 👇

Bricks Builder acaba de lanzar la versión 2.3.7, una actualización centrada principalmente en pulir la experiencia del builder, corregir comportamientos inesperados y mejorar la estabilidad en escenarios reales de trabajo.

No es una versión de grandes funciones nuevas, sino de esas que se agradecen en el día a día: menos fricción, menos errores visuales y mejor comportamiento en componentes, loops, filtros y WooCommerce.

Entre las novedades más destacadas encontramos mejoras en la gestión de fuentes personalizadas y ajustes en el elemento Form, especialmente en cómo se comportan ciertos iconos dentro de campos de contraseña.

La parte más importante de esta versión está en las correcciones. Bricks 2.3.7 soluciona problemas en el editor visual, el panel de estructura, los componentes, los slots, los Query Loops, la paginación AJAX, el scroll infinito y los filtros de consulta. También corrige varios detalles relacionados con WooCommerce, Gutenberg, SVGs con parallax, sliders dentro de acordeones y accesibilidad en Google Maps.

En resumen: Bricks 2.3.7 es una actualización de mantenimiento que conviene instalar, sobre todo si trabajas con componentes, filtros dinámicos, loops avanzados o tiendas WooCommerce. Como siempre, lo recomendable es probar primero en staging antes de actualizar en producción.

Fuente: changelog oficial de Bricks 2.3.7

Cerramos la serie con tres frentes que no son técnicos al uso pero marcan la dirección de WordPress los próximos meses: el nuevo sistema editorial de Notes que sí ha entrado en 7.0, el experimento Content Types que sigue su curso, y lo que se ha quedado fuera del release —empezando por la novedad más ruidosa, la colaboración en tiempo real—.

Notes a nivel de bloque: el sistema editorial que sí ha entrado

Aunque la colaboración en tiempo real se ha pospuesto, 7.0 sí trae un sistema editorial nuevo que cubre buena parte del caso real: Notes a nivel de bloque. Comentarios atados directamente a un bloque concreto —o incluso a una selección de texto dentro de un bloque— con tres capacidades:

• @mentions que notifican al usuario referenciado.
• Propuestas de cambio que preservan el texto original hasta que el autor las acepte o rechace explícitamente.
• Hilos de discusión asociados al bloque, no al post entero.

Para flujos editoriales multiusuario —agencias, sitios de medios, intranets con revisores y autores— esto reemplaza varios plugins de tercero (Editorial Comments, PublishPress, Edit Flow Comments) en su funcionalidad básica. Si has integrado alguno de ellos en proyectos de cliente, evalúa si los necesitas tras actualizar.

El punto técnico para developers: las Notes viven en una meta nueva y exponen hooks para extender el comportamiento. No es solo UI; hay API.

Content Types: el experimento que sigue su curso

El experimento Content Types sigue siendo eso, un experimento, en 7.0. No esperes API estable ni que lo encuentres en producción sin activar flags. Pero la dirección es clara: WordPress avanza hacia un sistema de tipos de contenido más estructurado que el actual de CPTs + taxonomías + metaboxes, con esquemas declarativos y relaciones nativas.

Si trabajas con estructuras de contenido complejas o mantienes plugins tipo ACF, JetEngine o Pods, este es el experimento a vigilar de cerca. Mi apuesta práctica: en 7.2-7.3 empezará a haber piezas estables y plugins que aprovechen la nueva API. Los proyectos arrancados en 2026-2027 con modelos de datos sofisticados pueden beneficiarse de planificar el modelo con esta dirección en mente, incluso si todavía se construye sobre CPTs tradicionales.

Lo que se ha quedado fuera

Colaboración en tiempo real (RTC), pospuesta a 7.1

La gran ausencia. El equipo retiró RTC del release final por problemas de:

• Superficie de ataque ampliada (sincronización constante, websockets expuestos).
• Condiciones de carrera detectadas en fuzzing.
• Carga de servidor difícil de acotar en hostings compartidos.
• Eficiencia de memoria en sesiones largas con muchos colaboradores.

Buena decisión. Meter RTC roto en core habría sido un desastre que se arrastra durante años. RTC vuelve en WordPress 7.1, prevista para agosto de 2026. Mientras tanto, Notes cubre el caso editorial más urgente sin necesidad del stack completo de tiempo real.

Bloque Playlist, retirado

El bloque Playlist se ha retirado del release. Si lo usabas, queda en plugins de la comunidad. Caso de uso minoritario y mantenimiento alto, decisión razonable de limpieza.

Qué significa esto para Flowtitude

Recapitulo los tres frentes que nos tocan directamente, condensados de los cuatro posts anteriores:

Higiene técnica. PHP 7.4 mínimo, Block API v3 obligatoria para editor iframed, html5 script support eliminado. Es trabajo de saneamiento que conviene meter en el siguiente ciclo de mantenimiento de plugins y temas custom, antes de que un cliente con hosting antiguo o un bloque legacy reporte algo raro.

Productividad nueva. autoRegister para bloques solo PHP, pattern overrides para bloques custom, Interactivity API con watch(), @wordpress/boot para páginas del site editor, pseudo-elementos en core/button desde theme.json. Son atajos serios que reducen boilerplate y centralizan código que antes vivía disperso. Si arrancas un proyecto la próxima semana, estas son las primeras herramientas a aprender.

Connectors API y AI Client. El día que un cliente pida «que el formulario genere un resumen», «que las imágenes saquen alt text solas» o «que sugiera categorías a posts nuevos», el camino correcto ya no es integrar OpenAI a pelo. Es consumir el AI Client del core: credenciales centralizadas, manejo estandarizado de errores, provider-agnostic. La diferencia entre cinco días de trabajo y uno.

WordPress 7.0 no es revolucionario en una sola línea —ningún release serio lo es—, pero es probablemente el más denso para developers desde 5.0. La capa de cambios bajo la superficie merece tanta atención como los titulares.

Si una tecnología está redefiniendo cómo construimos interfaces este año, es Tailwind CSS. Ha dejado de ser «un framework de estilos» para convertirse en el idioma común entre desarrolladores, asistentes de IA y page builders. En Dev.to, los posts con #tailwindcss dominan las conversaciones sobre UI, dashboards y productividad frontend. No es casualidad: es hacia dónde va la industria.

🔑 El hallazgo que lo explica todo
Pranav Chandra lo contó en Dev.to (28 may): intentó que su AI builder escribiera CSS responsive desde cero y en desktop el resultado era siempre mediocre. La solución no fue afinar el prompt, sino cambiar la tarea: en vez de pedirle CSS, le pidió clases de Tailwind. El salto fue brutal. Las utility classes son algo que los LLMs han visto millones de veces, así que las generan con consistencia. Moraleja: si construyes con IA, no necesitas más prompt engineering, necesitas darle primitivas que el modelo ya domina. Tailwind es hoy el formato nativo del diseño generado por IA.

📈 La comunidad ya lo ha adoptado
Lo confirma la oleada de dashboards y plantillas gratis: Steven publicó un AI Dashboard UI Template 100% libre, UI Junkie un tutorial para montar un admin dashboard desde cero, y Rails Designer cómo crear themes editables por el usuario con el mismo stack. Tailwind ya es el estándar de facto, para prototipar y para producción.

🧱 Y aquí entra Kodavio
En WordPress, controlar el sitio desde un asistente de IA ya es real — y es justo lo que hace Kodavio, nuestro servidor MCP para WordPress. Expone el sitio bajo /wp-json/mcp/kodavio y deja que cualquier asistente compatible con MCP —Claude Code, Cursor, Windsurf, Hermes— trabaje sobre Bricks, Elementor y Gutenberg: construir páginas, convertir una página de un builder a otro, gestionar ACF/JetEngine, mantener la memoria de diseño del proyecto y administrar el sitio de forma segura (con dry-run y confirmación para operaciones sensibles). Crear una landing, editar el hero o migrar de builder… sin salir del asistente.

¿Algo más ligero para el día a día? Bricks QuickNav (de deckerweb) añade un navegador rápido a la Admin Bar para saltar a templates, headers, footers y páginas. Mínimo y sin pantalla de ajustes: solo unas constantes en wp-config.php.

💸 Tailwind + IA + coste cero
El caso redondo lo cuenta Mark en Dev.to (1 jun): quería un directorio de 150+ herramientas web, sin registros, sin ads y sin coste de servidor. Stack: Next.js 15 con output: 'export', React 18, TypeScript y Tailwind, desplegado en Cloudflare Pages por 0 €/mes. Resultado: utlkit.com — todo client-side, los datos nunca salen del navegador. La clave: output: 'export' genera HTML/CSS/JS estático que corre en cualquier host sin Node. Filosofía: client-side, privacy by design, coste cero.

Para la comunidad Flowtitude, las señales convergen: en 2026 la interfaz se construye con Tailwind, se potencia con IA y se despliega sin servidores. Da igual si montas un dashboard, un theme editable o un sitio de herramientas: Tailwind es el puente entre la intención y el resultado. Y con piezas como Kodavio, gestionar esos diseños desde un asistente de IA ya no es un experimento: es workflow listo para producción.

👉 ¿Qué parte de tu flujo de diseño dejarías en manos de un asistente de IA? ¿Ya usas Tailwind en algún proyecto donde la IA participe? Cuéntanoslo 👇

Esta cuarta entrega es la más densa para quienes hacemos temas. WordPress 7.0 trae una colección de mejoras y correcciones en bloques, theme.json y comportamiento del editor que cambian flujos cotidianos y resuelven bugs arrastrados durante meses. Las repaso ordenadas por impacto real.

Pseudo-elementos en core/button desde theme.json

La mejora técnica más útil para temas: core/button soporta declarativamente :hover, :focus, :focus-visible y :active desde estilos globales. Hasta ahora, para personalizar el estado hover de un botón en un tema tocaba inyectar CSS custom vía wp_enqueue_style() o additional_css en theme.json. Ahora se hace así:

{
  "styles": {
    "blocks": {
      "core/button": {
        "color": { "background": "var(--brand)" },
        "elements": {
          "link": {
            ":hover": {
              "color": { "background": "var(--brand-dark)" }
            },
            ":focus-visible": {
              "outline": { "color": "var(--brand)", "width": "2px" }
            }
          }
        }
      }
    }
  }
}

Esto abre la puerta a que otros bloques sigan el mismo camino en próximas versiones. Si mantienes un design system en theme.json, este es el sitio para empezar a centralizar estados del botón.

Layout classnames al wrapper interno

Cambio silencioso que puede romper estilos puntuales: las clases de layout (is-layout-flow, is-layout-constrained, is-layout-flex, etc.) se aplican ahora al contenedor de bloques internos, no a sus hermanos. Si tu tema dependía de targetear esas clases con CSS custom esperando que estuvieran en el padre, comprueba que sigues alcanzando los elementos correctos.

El patrón roto típico:

/* Antes funcionaba; ahora puede no alcanzar */
.wp-block-group.is-layout-flow > .my-custom-class { ... }

Revisa con DevTools el árbol real tras actualizar antes de declarar la migración hecha.

Bloque Tabs: patrón ARIA, duplicación, estilos clásicos

El bloque Tabs acumula varias mejoras de calidad:

• Patrón ARIA Tabs. Renombrado del marcado para seguir el patrón ARIA Authoring Practices —importante el matiz: WCAG son las pautas, ARIA APG es el patrón concreto—. La accesibilidad real con lectores de pantalla mejora sin tocar tu código.
• Duplicación de tabs implementada en el editor, evita el copia y pega manual.
• Estilos para temas clásicos que evitan que los estilos heredados de core/button se filtren en los tabs. Problema que rompía bastantes temas legacy con botones muy estilizados.

Si has hecho workarounds en CSS para estos tres puntos, retíralos tras actualizar.

Bloque Imagen: aspectRatio y scale preservados al cambiar alineación

Al cambiar la alineación a wide o full, los valores de aspectRatio y scale ahora se preservan. Antes se reseteaban, lo que provocaba cambios de layout inesperados al mover una imagen entre alineaciones. Si tienes documentación, guías o vídeos enseñando «no toques la alineación después de ajustar el ratio», quedan obsoletos.

Bloque Búsqueda: dos correcciones que importan

Dos fixes en el bloque Búsqueda que merece la pena anotar:

• La configuración de color se aplica correctamente al input cuando el botón está deshabilitado.
• Se resuelve el conflicto entre estilos globales definidos vía theme.json y los controles locales del inspector para bordes y colores.

Si has tenido reportes de «el borde no se aplica», «el color del placeholder se ignora» o «se sobrescribe lo del Personalizador», probablemente este era el bug.

Bloque Cover con vídeo de fondo

core/cover ahora acepta vídeo como fondo, no solo imagen. Antes había que apilar bloques o usar un plugin de tercero. Patrón importante para landings con hero animado. Si has metido vídeos de fondo con core/video + posicionamiento absoluto + capa de oscurecido manual, retira el apaño.

Bloque Gallery con lightbox y slideshow

Soporte de lightbox con opción de slideshow integrado. El visitante hace clic en una imagen y pasa entre ellas sin salir de la página. Antes esto requería un plugin externo, con sus conflictos de inicialización, dependencias de scripts y problemas de compatibilidad con bloques iframed. Ahora viene de fábrica.

Nuevos bloques: Breadcrumbs, Icons, Headings unificado

Tres entradas al catálogo core:

• Breadcrumbs. Refleja la jerarquía de navegación automáticamente, con filtros developer para personalizar separador y lógica.
• Icons. Catálogo de iconos SVG nativos, sin depender de fuentes de icono externas o plugins.
• Headings unificado. Ya no hay un bloque por cada nivel jerárquico. Es un solo bloque Headings con variaciones y selector rápido en la sidebar para cambiar entre h1-h6. Reduce el ruido del inserter.

Si tu plugin proveía Breadcrumbs o Icons, evalúa si lo retiras y dependes del core o si tu valor añadido justifica mantenerlo.

REST API: campo de fecha en Templates y Template Parts

Los endpoints REST de Templates y Template Parts incluyen ahora un campo de fecha que permite ordenar y filtrar por fecha de creación o modificación. Útil para vistas administrativas custom, auditoría de cambios en estructura del sitio o sincronización con sistemas externos.

Otras correcciones menores que conviene saber

• Estilos globales con pseudo selectores (:hover, :focus, etc.) en el editor estaban rotos cuando se aplicaban vía Estilos Globales. Arreglado.
• Site Identity en panel de Diseño. El bloque aparece directamente en el panel de Diseño del editor de sitio, evitando un salto al Personalizador o a Ajustes Generales.
• Acordeón con controles de dimensión. Acerca el bloque a la paridad con core/group, aunque sigue sin tener todos los supports.

Resumen accionable

1. Migra los estados hover/focus/active de tus botones de CSS custom a theme.json.
2. Revisa selectores CSS que dependían de las clases is-layout-* en el padre. Ajusta a la nueva ubicación en el wrapper interno.
3. Retira workarounds CSS en Tabs, Búsqueda e Imagen relacionados con los bugs arreglados.
4. Evalúa si tus plugins de breadcrumbs o iconos siguen aportando valor frente a los bloques core.

En el último post de la serie cerramos con Notes a nivel de bloque —el sistema editorial que sí ha entrado—, el estado del experimento Content Types, lo que se quedó fuera (RTC, bloque Playlist), y la reflexión sobre qué frentes nos tocan más directamente desde Flowtitude.

MiniMax acaba de lanzar M3 (3.0), su nuevo modelo principal. Si trabajáis con textos largos, programación o asistentes que encadenan muchas tareas, los cambios os van a interesar. Os lo resumo en claro.

Qué mejora frente a la versión anterior (M2.7)

• Mucho más rápido cuando hay mucho texto de por medio. Donde antes el modelo se ralentizaba al manejar documentos enormes o conversaciones muy largas, M3 responde con soltura. Según MiniMax, varias veces más rápido en esos casos (son cifras suyas, conviene comprobarlas en uso real).
• Mucho más barato en esas tareas largas. Procesar contextos muy grandes cuesta una fracción de lo que costaba antes.
• Ahora entiende imágenes y vídeo, no solo texto. La versión anterior solo trabajaba con texto.
• Memoria de trabajo enorme: puede tener en cuenta el equivalente a varios libros a la vez sin perder el hilo.

Cómo queda frente a la competencia

• Precio muy competitivo. Cuesta bastante menos que los modelos de primera línea de OpenAI, Google o Anthropic, ofreciendo un nivel parecido.
• Programación a buen nivel. En las pruebas de programación se coloca por encima de los modelos equivalentes de OpenAI y Google, y se acerca al mejor de Anthropic, pagando mucho menos.

Mi lectura práctica

• Donde de verdad destaca es en trabajos con mucha información acumulada: proyectos de código completos, documentos largos o asistentes que arrastran un historial grande. Eso, que antes salía caro y lento, ahora es ágil y económico.
• Con cautela: las cifras de velocidad las da el propio fabricante, así que lo suyo es medirlo en cada caso antes de fiarse del todo.
• Para quien combina varios modelos según la tarea, M3 entra como una opción muy seria para todo lo que sea largo o repetitivo, donde antes tocaba tirar de un modelo caro. Voy a probarlo y os cuento qué tal.

En resumen: M3 no busca ser "el más listo de todos", sino casi igual de capaz, más rápido con tareas largas y mucho más barato. En el día a día, esa combinación suele ganar.

¿Alguien lo ha probado ya? Me interesan vuestras impresiones reales. 👇

La integración de IA nativa es el titular del release. Pero detrás del titular hay una infraestructura técnica concreta que cambia cómo deberíamos integrar funciones de IA en plugins y proyectos personalizados a partir de ahora. Esta entrega va de eso: por qué consumir el AI Client del core sustituye —y mejora— los envoltorios artesanales que llevamos años escribiendo.

El problema antes de 7.0

Si has metido IA en un proyecto WordPress en los últimos dos años, probablemente has hecho alguna versión de esto:

• Pedir al cliente una API key de OpenAI o Anthropic.
• Guardarla en wp_options con tu propia capa de cifrado o sin ella.
• Envolver wp_remote_post() para llamar al endpoint del proveedor.
• Implementar tu propio manejo de errores, rate limits, retries y timeouts.
• Resignarte a que, si otro plugin del mismo sitio hace lo mismo, hay dos claves distintas, dos sistemas de cifrado distintos y dos formas de fallar.

Multiplica eso por dos o tres proyectos al año y tienes un mantenimiento que se acumula: cada breaking change del proveedor te toca a ti, cada migración de modelo te toca a ti, cada auditoría de seguridad te encuentra una clave en claro que olvidaste hace seis meses.

Lo que aporta 7.0

WordPress 7.0 introduce tres piezas que resuelven la fragmentación:

Connectors API. Un hub central en Ajustes > Connectors donde el administrador del sitio configura credenciales una vez por proveedor —OpenAI, Anthropic Claude, Google Gemini de fábrica— con métodos de autenticación estandarizados (api_key, none). Las claves viven en un único sitio, con interfaz nativa y permisos controlados por capacidades.

WP AI Client. Una interfaz provider-agnostic que cualquier plugin o tema puede consumir para hablar con modelos generativos sin saber de qué proveedor se trata. Si el usuario cambia de OpenAI a Anthropic en Connectors, tu plugin sigue funcionando sin tocar una línea.

Abilities API y Client-Side Abilities API. El modelo de «capacidades» que el sitio expone a la IA. En lugar de pedirle al modelo «haz X» y rezar, declaras las acciones disponibles (publicar un draft, etiquetar un post, generar alt text) y la IA elige cuál ejecutar. Es la pieza que permite asistentes con superficie controlada.

Cómo se ve en código

El cambio de paradigma es claro. Pasamos de esto:

$response = wp_remote_post( 'https://api.openai.com/v1/chat/completions', array(
    'headers' => array(
        'Authorization' => 'Bearer ' . MYPLUGIN_OPENAI_KEY,
        'Content-Type'  => 'application/json',
    ),
    'body'    => wp_json_encode( array(
        'model'    => 'gpt-4',
        'messages' => array( /* ... */ ),
    ) ),
    'timeout' => 30,
) );
// + parseo del JSON, manejo de errores específicos del proveedor, retries...

A consumir el cliente del core:

$ai = wp_ai_client();

$result = $ai->generate( array(
    'prompt'  => 'Resume este post en 280 caracteres: ' . $post_content,
    'purpose' => 'summary',
) );

if ( is_wp_error( $result ) ) {
    return $result;
}

return $result->get_text();

El plugin deja de saber qué proveedor está detrás. Si el sitio tiene OpenAI configurado, va por ahí. Si tiene Claude, va por ahí. Las credenciales no las toca tu código. Los errores vienen como WP_Error normalizados.

Casos de uso típicos en proyectos cliente

Tres patrones que vas a montar pronto si trabajas con clientes:

Generación automática de alt text en imágenes. Al subir una imagen, una ability registrada llama al AI Client con la imagen y rellena el campo alt. El cliente no pega claves en ningún sitio: se ha configurado una vez en Connectors.

Resumen de posts largos para meta description o redes sociales. Un metabox en la edición del post con un botón «sugerir resumen» que consume el AI Client. Compatible con cualquier proveedor configurado.

Sugerencia de categorías o etiquetas según contenido. En autosave o al pulsar un botón, una ability analiza el contenido y propone taxonomías existentes. El editor acepta o descarta.

En los tres casos, el código del plugin no menciona a OpenAI ni a Anthropic. Solo consume wp_ai_client().

Cuándo no usarlo

El AI Client cubre el caso general: generación de texto, embeddings, clasificación. Si necesitas algo muy específico de un proveedor —streaming en tiempo real con un protocolo concreto, function calling con un esquema propietario, modelos fine-tuned privados— sigue siendo razonable mantener una integración directa para esa pieza. El AI Client no pretende cubrir el 100% de la API de cada proveedor, sino el 80% común.

La regla práctica: si tu feature puede describirse como «pídele esto al modelo y devuélveme el resultado», AI Client. Si necesitas tocar la API del proveedor con detalle, integración directa.

Resumen accionable

1. En el próximo proyecto que requiera IA, no propongas «integro OpenAI». Propón «consumo el AI Client de WordPress 7.0».
2. Si mantienes un plugin con integración directa a un proveedor, planifica una versión que ofrezca el AI Client como vía recomendada y la integración directa como fallback.
3. Estudia la Abilities API. Es la diferencia entre «un plugin que llama a la IA» y «un plugin que expone capacidades a un asistente».
4. Documenta a tus clientes que las claves van en Ajustes > Connectors, no en cada plugin.

En el próximo post: los cambios en bloques, theme.json y editor que afectan a quienes hacemos temas. Mejoras en Tabs, Imagen, Búsqueda, pseudo-elementos en core/button, Cover con vídeo, Gallery con lightbox, y los dos bloques nuevos del release.