Hace unos días abrí cuatro incidencias en el repositorio de sugerencias de Crocoblock. Ninguna era una petición de función nueva: eran cosas que me encontré de frente reconstruyendo mi propia web sobre CrocoBuilder.

Dos ya están cerradas en la 1.0.0-beta.21.

La primera era que no había manera de usar etiquetas semánticas en línea. Ni strong, ni em, ni small. Suena a detalle de purista y no lo es: son las que el lector de pantalla entiende como énfasis, las que hacen que una hoja de estilos que ya tienes escrita siga sirviendo, y las que te dejan destacar una palabra dentro de un párrafo sin partirlo en tres nodos. La respuesta del equipo fue de una línea: «more tags added in 1.0.0-beta.21 update».

La segunda era del renderizador. El esquema decía que un encabezado podía llevar hijos, y al pintarlo los descartaba: salía la etiqueta vacía. Y de paso, cualquier nodo sin contenido desaparecía por el camino, así que un fondo decorativo o una barra de progreso no llegaban nunca al HTML. «Fixed in 1.0.0-beta.21 update».

Las otras dos siguen abiertas, y no me extraña, porque son las más profundas: el saneado de nombres de clase que rompe Tailwind en silencio —la que conté aquí hace unos días— y un error de clave duplicada al activar sobre una instalación limpia.

Pero lo que me parece más interesante no es la noticia. Es de dónde salieron las cuatro. Ninguna apareció probando la herramienta: aparecieron reconstruyendo una web que ya existía, con sus encabezados de dos líneas, su énfasis dentro de los párrafos y sus clases de utilidad.

Un equipo que hace un builder lo prueba bien y lo prueba mucho. Pero lo prueba construyendo cosas nuevas, que es el escenario amable. Los bordes salen cuando alguien de fuera intenta replicar algo que ya funcionaba y se encuentra con que falta una pieza que nadie había echado en falta, porque nadie había ido por ahí. Eso no se ve desde dentro.

Así que si estáis en la beta y os habéis topado con algo que os hizo parar —aunque parezca menor, aunque penséis que ya lo sabrán—, reportadlo. Cuatro de cuatro se leyeron y dos están arregladas en días. Ese es el porcentaje real, no la sensación de que escribir en un repositorio no sirve de nada.

Hace unos dias conté aquí que el builder se comía mis clases de Tailwind al guardar. Hoy la web de mi agencia está montada encima de los dos, con variantes, opacidades y valores arbitrarios funcionando. Entre una cosa y otra hay cuatro arreglos, y ninguno estaba donde yo lo buscaba.

Uno. El saneador no se arregla por dentro.
Me pasé un rato leyendo el código del builder buscando un filtro donde engancharme. No lo hay: el método es privado y no dispara nada. La salida estaba fuera — sanitize_html_class es un filtro global de WordPress. Un add_filter de doce líneas y las variantes vuelven intactas. La lección, que me la aplico a mí: cuando no encuentres el gancho dentro de un plugin, mira si lo que hace por
dentro es en realidad una función de WordPress.

Dos. Que la clase sobreviva no significa que exista.
Con el saneador arreglado, la página seguía saliendo a medio estilar. WindPress trae diecisiete integraciones —Bricks, Oxygen, Elementor, Gutenberg…— y ninguna es CrocoBuilder. El compilador buscaba clases donde el builder no guarda nada: CrocoBuilder no escribe en post_content, reparte en un meta y dos tablas propias. Sin decirle dónde mirar, compilaba un CSS impecable y vacío.

Tres. El que gana no es el más específico, es el que no está en una capa.
Este me tuvo un rato. El builder emite esto:

:where(.crocoblocks-document .cb-el) { box-sizing: border-box; max-width: 100% }

Especificidad cero, escrito a propósito para no estorbar. Y aun así se llevaba por delante cualquier max-w-* y hasta el contenedor de mi design system. Porque las utilidades de Tailwind viven en @layer utilities, y en la cascada lo que no está en ninguna capa gana siempre a lo que sí lo está, da igual la especificidad. La solución no es pelear con selectores: es meter la hoja del builder en su propia capa y ponerla la primera.

Cuatro. Recompilar al guardar no es un hook de PHP.
Buscando cómo automatizarlo descubrí que la función existe para media docena de builders y no es lo que yo pensaba: la página del builder publica un mensaje en un BroadcastChannel y la app de WindPress lo recoge y compila. Treinta líneas para replicarlo. El compilador es JavaScript y corre en el navegador, así que sigue haciendo falta tener WindPress abierto — pero eso vale igual para todos los demás.

Y una propina que no buscaba.
Mirando por qué se me caían la mitad de los modificadores del sistema de diseño, encontré esto: los identificadores de las clases globales se generan con random_int, y la consulta que las lee no lleva ORDER BY. O sea que el orden en que salen al CSS es, literalmente, aleatorio. Un modificador BEM funciona o no funciona según qué número le tocó al crearlo. En mi sistema había quince muertos. Reportado, con reproducción.

Lo que me llevo, y es lo que quería contaros: ninguno de los cuatro fallos está dentro de CrocoBuilder ni dentro de WindPress. Los dos son buenos y hacen bien lo suyo. Los fallos están en la frontera — el saneado al guardar, dónde busca el compilador, en qué capa cae el CSS, cómo se avisan entre sí. Y en la frontera no mira nadie, porque no es de nadie.

Por eso creo que este trabajo vale la pena aunque sea tedioso: las integraciones no se rompen por el centro, se rompen por los bordes, y los bordes solo se ven cuando alguien pone las dos herramientas juntas en un sitio de verdad y aguanta hasta el final.

WordPress 7.0 trae una pantalla nueva que igual no has abierto: Ajustes → Conectores. Una tarjeta por proveedor, la clave se guarda una vez y la comparten todos los plugins. Se acabó pegar la misma API key en cinco ajustes distintos.

El problema es lo corta que se queda la lista: Anthropic, Google y OpenAI. Tres tarjetas y a correr.

Y yo, como muchos de vosotros, ya estoy pagando IA que no está en esa lista. DeepSeek. Kimi. OpenRouter. Y encima tengo modelos corriendo en mi propio portátil con Ollama y LM Studio, que no me cuestan nada y para la mitad de las tareas van sobrados.

Así que me he montado el conector que faltaba: pones nombre, la URL del endpoint y la clave, y te aparece como una tarjeta más, exactamente igual que las otras tres, con su botón, su estado de conectado y su clave compartida con el resto de plugins. Vale para cualquier servicio que hable el formato de OpenAI, que hoy es prácticamente todo el que no es Anthropic ni Google. Los modelos te los detecta él solo preguntándole al endpoint; no hace falta que te sepas el identificador de memoria.

Antes de que llegue la pregunta: la suscripción de la app web no vale. Tu ChatGPT Plus o tu Claude Pro no dan endpoint; se paga aparte por API. Lo que sí enchufas aquí es lo que ya tiene clave de API —DeepSeek, Kimi, OpenRouter, MiniMax, el endpoint de tu empresa— o lo que corre en tu máquina, que es gratis. Prefiero decirlo yo antes de que alguien pierda media tarde buscando su clave de ChatGPT Plus.

Y va la parte que os sirve montéis lo que montéis. Si apuntáis WordPress a un modelo de vuestra propia máquina, os vais a encontrar con esto:

WordPress hace las llamadas de IA con wp_safe_remote_request(), que valida la URL antes de salir y rechaza dos cosas: los hosts que resuelven a una IP local o privada, y cualquier puerto que no sea 80, 443 u 8080. Ollama escucha en el 11434. LM Studio, en el 1234. Los dos caen.

Lo bueno sería que el error lo dijera. Lo que devuelve es:

A valid URL was not provided

Ni "puerto no permitido", ni "host local bloqueado". Con ese mensaje delante te pasas un buen rato revisando tu endpoint, que está perfectamente. Se abre con dos filtros del propio core (http_request_host_is_external y http_allowed_safe_ports), y lo suyo es abrirlos solo para las URLs que has dado de alta, no en general.

Y un segundo detalle, más de fondo: registrar el proveedor no basta. El plugin oficial de IA de WordPress no le pregunta al AI Client si hay credenciales — mira la opción concreta que el core genera para cada conector. Yo guardaba la clave en la mía, y tenía una conexión que funcionaba llamándola por código y que el plugin oficial daba por no configurada. Cambiar dónde vive la clave lo arregló entero.

Que es la moraleja de siempre: en cuanto hay un estándar, el trabajo deja de ser hacer que funcione lo tuyo y pasa a ser encajar con lo que ya está. Menos vistoso, y es lo que decide si tu plugin sirve para algo dentro de un año.

Tecnología con sentido. Menos humo. Más criterio.

¿Estáis pagando alguna IA que hoy no podéis usar dentro de WordPress, sí o no?

Nueva versión, y esta corría prisa.

Si estás probando la beta de Bricks 2.4 y WindPress ha desaparecido del editor, no es cosa tuya ni se te ha desconfigurado nada.

En 2.4 la barra de herramientas se puede mover de sitio y, por eso, ha dejado de tener un id fijo: lo que antes era #bricks-toolbar ahora es una clase, y el id lleva la posición. WindPress la sigue buscando por el id de siempre, no la encuentra y revienta al arrancar sus módulos.

Y como los carga en cadena, el primer fallo se lleva por delante a todos los demás. Por eso no desaparece una cosa: desaparecen todas a la vez.

• la caja de plain classes
• el icono de WindPress en la barra
• el autocompletado de clases

Sin ningún aviso en pantalla, que es lo que más despista. El único rastro estaba en la consola del navegador.

Qué trae la 1.5.0

Fix 7 — Bricks 2.4. El parche ensancha el selector en vez de sustituirlo, así que el mismo archivo funciona igual en Bricks 2.3 y en 2.4:

#bricks-toolbar  →  :is(#bricks-toolbar,.bricks-toolbar)

Se aplica solo, guarda copia de los archivos originales antes de tocarlos y se vuelve a aplicar cuando actualices WindPress. Y como no sustituye el selector, lo puedes tener puesto ya aunque sigas en 2.3. Si prefieres revertirlo, tienes el botón en Herramientas > WindPress Fix, junto al estado y a la versión de Bricks que detecta.

Verificado contra la beta 2.4-beta2, conduciendo el builder de verdad: sin el parche la consola muere en el primer módulo; con él cargan los cinco y el icono vuelve a su sitio en la barra.

Fix 6 — CrocoBuilder. El saneador de clases de WordPress se llevaba por delante las variantes, los valores arbitrarios y los decimales de Tailwind. Va arreglado en esta misma versión y solo se activa si tienes CrocoBuilder instalado; el caso entero, con lo que me encontré al reconstruir la web sobre Croco, os lo cuento esta semana.

Cómo actualizar

Desde Plugins, si tienes la actualización automática activada, o descargando la versión nueva y subiéndola encima. No hay que tocar nada más: los dos fixes se activan solos.

Los dos están reportados a sus autores. Esto es un puente hasta que lo arreglen ellos, no un sustituto.

Tecnología con sentido. Menos humo. Más criterio.

¿Ya has dado el salto a Bricks 2.4 o lo estás esperando a que salga de beta?

Os contaba en el post anterior que estoy rehaciendo la web de mi agencia dentro de CrocoBuilder, y que me había chocado con el asunto de las clases de Tailwind.

Han caído unas cuantas horas más encima. Así que aquí va el parte completo: lo que cumple, lo que frena, y los cuatro issues que he abierto con su enlace. Sin adornos en ninguna de las dos direcciones.

Lo que cumple

El DOM es lo que promete. Un elemento del builder, un nodo. Sin envoltorios fantasma. Después de años limpiando div que nadie pidió, esto se nota al primer vistazo al inspector.

Las clases son CSS de verdad. Nombres reales, utilizables fuera del builder. No hay formato propietario del que luego no puedas salir.

El MCP funciona. Es la razón por la que Kodavio le dio soporte en su día, y en la práctica se comporta.

Lo que frena hoy — los cuatro issues que he abierto

Los cuatro están reportados en el repositorio público de Crocoblock, con entorno, reproducción y traza. Os dejo el enlace de cada uno por si os habéis chocado con alguno y queréis sumar vuestro caso.

1. El saneado de nombres de clase se carga Tailwind. (#8513) Este ya os lo conté: hover:bg-black/50 acaba guardado como hoverbg-black50, convertido en una clase que no existe. Lo que he averiguado después es que el saneado no está solo al guardar — corre también al leer el documento y al renombrar clases, así que arreglar una sola vía no bastaría. Y que el validador del propio builder da el documento por bueno, sin un solo aviso.

2. No hay ni una etiqueta inline semántica. (#8514) Ni strong, ni em, ni i, ni small. Todo texto en línea acaba siendo un span. Eso son dos cosas a la vez: un lector de pantalla deja de saber qué está enfatizado, y cualquier hoja de estilos que use selectores de elemento deja de aplicar. Lo vi portando una página real: de diez selectores descendentes que tenía, tres apuntaban a strong y a i. Tuve que inventar alias de clase para reproducir un diseño que ya funcionaba.

3. El renderizador se come hijos que el esquema dice que acepta. (#8515) Un heading declara en su propio esquema que admite hijos. Le pones hijos y salen por el otro lado convertidos en un <h1> vacío. Otra vez sin error y con el validador diciendo que todo bien.

4. Error de base de datos en cada activación limpia. (#8516) El plugin intenta crear el mismo índice dos veces y suelta un Duplicate key name. No rompe nada, activa igual, pero llena el log. Estaba en la beta.18 y sigue en la beta.20, con dos releases de por medio.

Si os fijáis, tres de los cuatro comparten patrón: el builder da por bueno lo que acaba de romper. Ese es, para mí, el hilo del que conviene tirar — más que cada fallo por separado.

Y dos cosas más que no he reportado

Porque no son fallos, son decisiones de diseño con las que hay que contar:

• El CSS del builder no va en capa. Sus estilos salen fuera de @layer y las utilidades de Tailwind viven dentro. Lo que está fuera gana siempre, tenga la especificidad que tenga. Traducido: la propiedad que toques en el panel, Tailwind ya no la cambia. Hay que elegir dueño para cada propiedad.
• La cabecera del tema se captura con una expresión regular. Si tu header.php no escribe la etiqueta <head> literal —porque la sacaste a un partial—, no captura nada y la página sale sin charset ni viewport. Funciona, pero es frágil de una forma que nadie va a sospechar.

Dónde estamos nosotros

Como ya os dije, nuestro lado está resuelto: el proveedor de WindPress para CrocoBuilder funciona y Tailwind ya sabe qué clases usas. El circuito está entero, y lo único que lo bloquea es el punto 1.

Los cuatro issues van con entorno, reproducción y traza, porque un fallo bien explicado se arregla rápido y uno mal explicado se cierra. CrocoBuilder está en beta precisamente para esto.

Y me reafirmo en lo de antes: la dirección del producto me sigue pareciendo la correcta. DOM limpio, CSS que sobrevive fuera del builder y MCP de serie es exactamente donde quiero que vaya esto. Por eso me tomo la molestia de escribir el parte en vez de cerrar la pestaña.

¿Alguno estáis probando ya la beta? Si os habéis chocado con alguno de estos cuatro, decídmelo y lo mando con vuestro caso: dos reproducciones pesan más que una.

La única forma honesta de probar un builder no es montar una landing de ejemplo. Es coger algo que ya tienes en producción y rehacerlo entero.

Así que estoy replicando la web de mi agencia —hoy hecha con Kodavio y plantillas .php— dentro de CrocoBuilder. Detalles menores han ido cayendo sin drama. Pero hay uno que no es menor.

CrocoBuilder y Tailwind no se hablan. Y el motivo es de tres caracteres.

Cuando guardas un documento, el builder pasa cada nombre de clase por el saneador de clases de WordPress. Ese saneador borra todo lo que no sea letra, número, guion o guion bajo. Y Tailwind vive justo de lo que borra: los dos puntos de las variantes, la barra de las opacidades, los corchetes de los valores arbitrarios.

El resultado no es que la clase desaparezca. Es peor:

hover:bg-black/50   →   hoverbg-black50

Sigue ahí. Parece puesta. Se ve en el inspector. Y no existe. No hay error, no hay aviso, no hay nada que te diga que tu variante se ha quedado por el camino — solo un elemento que no cambia al pasar el ratón y una tarde buscando dónde te has equivocado tú.

Y lo que me fastidia de verdad es que la parte difícil ya está hecha. La integración con WindPress la tenemos lista: el escáner ya lee las páginas de CrocoBuilder, así que Tailwind sabe qué clases estás usando y las compila. Todo el circuito funciona. Lo que lo bloquea es una limpieza de cadena en el guardado.

Se lo voy a hacer saber al equipo, junto con otra cosa que me he encontrado: al activar el plugin sobre una instalación limpia, intenta crear el mismo índice de base de datos dos veces y suelta un error de duplicado. No rompe nada, pero lo detecté en la beta.18 y sigue igual en la beta.20, con dos releases de por medio.

Nada de esto es un «no lo uséis». Es una beta, la dirección del producto me sigue pareciendo la correcta —DOM limpio, CSS que sobrevive fuera, MCP de serie— y estas cosas se arreglan si alguien se molesta en encontrarlas y contarlas bien. A ver si hay suerte.

Pero sí me deja una idea que me llevo puesta: una integración no está probada hasta que reconstruyes con ella algo que ya funcionaba. En una página nueva no te enteras. En una que ya conoces al dedillo, el fallo te salta a los diez minutos.

Sé que esto lleva un tiempo callado. No voy a vender que era estrategia: es que lo que estaba haciendo no se puede enseñar en una captura bonita.

Bricks 2.4 no es una actualización más. Cambia el suelo sobre el que se apoyan FlowKit y Kodavio, y cuando cambia el suelo tienes dos opciones: salir corriendo a anunciar compatibilidad, o sentarte a comprobarla. He estado en lo segundo.

Kodavio. La 2.4 publica 142 abilities nativas, y están muy bien hechas. Así que Kodavio no las reimplementa: delega en ellas y se queda con lo que Bricks no cubre, que es todo el WordPress de alrededor. Eso lo he verificado sobre un WordPress real con la 2.4 puesta, no leyendo el changelog.

Probar de verdad tiene estas cosas: me encontré quince tests escritos que nunca llegaban a ejecutarse. Estaban ahí. En verde. Sin correr.

FlowKit. Vamos por 13 de 27 elementos de WooCommerce con controles de estilo nativos en el panel. Los 14 que faltan pensaba que eran mecánicos y no lo son: once arrastran un apaño que lee las clases con una expresión regular y las reinyecta más abajo, y tres directamente no escriben ninguna clase estable.

Esos tres son el cupón del carrito, el formulario de cupón del checkout y la aceptación de términos. Los elementos que nadie mira. Los que llevan años así precisamente porque nadie los mira.

Y aquí está lo que me hizo cambiar el orden de la lista: los tres viven en el paso de pagar. El elemento menos glamuroso de la tienda está exactamente en el punto donde el cliente decide si suelta el dinero o cierra la pestaña. Lo poco usado no es lo poco importante — a veces es solo lo que nadie ha querido tocar.

Y hay tres cosas más de FlowKit que están en marcha, que no se ven todavía y que os interesan más que los controles:

• Un pack de plantillas básicas de tienda, montadas con nuestros propios elementos. Para que empezar una tienda no sea empezar de cero cada vez.
• El asistente de IA cambia de estrategia. Con la 2.4 trayendo IA nativa, lo que tenía sentido que hiciera un asistente propio hace tres meses ya no es lo mismo. Prefiero replantearlo que mantener algo que la plataforma ya hace mejor.
• El FDS sale de FlowKit y pasa a ser un plugin aparte, gratuito. Porque no es un extra: junto con el sistema de diseño de Tailwind es la pieza sobre la que se apoya todo lo demás, y una pieza así no debería estar detrás de una licencia.

De lo del FDS no os cuento más hoy, porque merece su propia noticia y no un párrafo de pasada. La tendréis.

No os voy a dar fecha de nada, porque la 2.4 todavía está en beta y prometer días sobre algo que se mueve es cómo se pierde la confianza. Lo que sí os digo es en qué se está yendo el tiempo, y por qué en el orden que va.

Crocoblock ha sacado su propio builder, y como en Kodavio le hemos dado soporte, os cuento qué es y por qué me ha parecido que valía la pena.

Qué es. Un builder de frontend para WordPress orientado a desarrolladores. No es otro maquetador visual más: la promesa es que puedas trabajar visualmente sin perder el control del código que sale.

Salida DOM atómica. Un elemento del builder equivale a un nodo del DOM. Sin envoltorios ocultos, sin marcado generado de más. Quien haya peleado con capas de div que nadie pidió sabe por qué esto importa: HTML más limpio, páginas más rápidas y mantenimiento más sencillo.

Los estilos son CSS de verdad. Las clases se crean con nombres CSS reales y funcionan fuera del builder, así que puedes reutilizarlas en Gutenberg o en otro proyecto. Nada queda encerrado en un formato propietario.

Y van sincronizados. Puedes alternar entre los controles visuales y el CSS en crudo cuando quieras: los dos editan lo mismo. No hay una caja de "CSS adicional" aparte que luego se desincroniza.

Gestión de sistema de diseño. Trae gestor de estilos globales, de variables CSS, de clases, importación y exportación de frameworks CSS, y breakpoints propios en vez de la lógica responsive fija del builder.

Contenido dinámico sin PHP. Loop Builder, Query Builder y Theme Builder para cabecera, pie, single, archivo y plantillas de producto. Más condiciones de visibilidad por rol, dispositivo o datos.

Componentes con acceso al código. Se construyen en HTML, CSS y JS —a mano o por prompt— con propiedades, slots y Web Components con props, que puedes usar en Gutenberg como componentes vivos y no como plantillas estáticas.

Y aquí lo que nos toca de cerca: trae conexión MCP. Permite que agentes como Claude o Codex gestionen estructura, consultas, componentes, estilos y páginas directamente a través del builder. Con un detalle que me parece bien resuelto: los cambios de la IA pasan por un protocolo de prueba en seco, revisas el resultado y solo entonces se aplica.

Esa es exactamente la razón por la que Kodavio lo soporta. No hemos tenido que reimplementar nada: publica su MCP y Kodavio trabaja con él.

Lo que conviene saber antes de emocionarse. No hay versión gratuita: son 79 $ al año para un sitio, con 30 días de devolución. Las integraciones nativas con JetEngine, JetFormBuilder, JetSmartFilters y JetPopup todavía están por llegar, igual que el versionado con GitHub. Y no sustituye a Gutenberg: convive con él y se encarga solo de las plantillas o páginas que le asignes.

Es un producto joven. Pero la dirección —DOM limpio, CSS que sobrevive fuera, y MCP de serie— es justo la que a mí me interesa.

Ya está en control de calidad, así que la tenéis en unos días.

Y sale acompasada con Bricks 2.4: la hemos adaptado a esa versión, y lo lógico es que las dos lleguen juntas y no que os toque actualizar dos veces con una semana de diferencia.

Hace unos días os conté hacia dónde iba: nada de perseguir builders, sino reconocer los MCP que cada plugin ya publica y trabajar con ellos. Esto es lo que ha salido de aquella decisión.

Es una herramienta de desarrollo. No un asistente que te monta la web. Estas últimas semanas la he usado para depurar plugins que estaba construyendo yo mismo: analizar el código, sacar informes de lo que encuentra, e ir mejorando la parte de diseño sobre la marcha. Ahí es donde ha demostrado que vale.

Trabaja con los MCP que ya tienes instalados, no contra ellos. Si tienes el de Bricks o el de Crocoblock, Kodavio los reconoce y se apoya en ellos en vez de reimplementar lo que ya hacen bien.

Y llega lo prometido: la conversión entre builders. Bricks, Elementor y Gutenberg, que son los que de verdad usa la gente. Más el builder de Crocoblock, que he añadido de forma excepcional aunque todavía esté en beta, porque me parecía que valía la pena acompañarlo desde el principio.

También conversión entre los frameworks CSS que se usan con Bricks, con el mismo criterio: los que la gente usa hoy.

Y ahí se cierra. He visto plugins que dan compatibilidad con WPBakery, por ejemplo, y entiendo por qué: sobre el papel suma. Pero hoy casi nadie empieza un proyecto ahí. Mantener esa conversión sería trabajo que envejece solo — justo lo que decidimos no hacer.

Hay un cambio de fondo que quiero contarte, porque explica los dos anuncios de golpe.

Hasta ahora el sistema de diseño vivía pegado a Tailwind. Tenía sentido cuando ese era el único sitio donde lo usábamos. Pero el método ya no se trabaja solo así: también se usa con Bricks nativo, y un sistema de diseño que solo funciona en la mitad de tu trabajo no es un sistema, es una dependencia.

Así que lo hemos soltado. Los tokens, la escala, los componentes: todo pasa a ser CSS estándar, sin depender de las utilidades de nadie.

Y ahí viene lo interesante, que no lo hemos buscado sino que sale solo. En cuanto dejas de depender de Tailwind, el sistema funciona donde funcione el CSS: en Bricks nativo, en el nuevo editor v4 de Elementor y en Gutenberg. No hemos construido tres integraciones una a una. Hemos quitado la atadura, y los tres han venido de propina.

Por eso también sale de FlowKit y pasa a ser un plugin gratuito. Un sistema de diseño que ya no está atado a una herramienta tampoco tiene por qué estar atado a una licencia. Es el complemento natural del método, y tiene más sentido en manos de todos.

Sé que suena a lo contrario de lo que te contaba sobre Kodavio, así que déjame precisar la diferencia. Ampliar superficie es hacer más cosas y mantenerlas una a una. Esto es lo contrario: hemos quitado una dependencia, y por eso lo mismo funciona en más sitios sin código extra. Son tres entornos, son los que hay, y ahí se cierra.