Estamos trabajando en la versión 0.3.0 y hay una decisión de fondo que quiero contarte, porque cambia lo que puedes esperar del plugin.

La tentación evidente era crecer a lo ancho: dar soporte a veinticinco builders, a seis plugins de formularios, a cada herramienta que aparece. Ese camino no lleva a ninguna parte. Acabas con un plugin que hace muchas cosas y ninguna del todo bien, y con una lista de compatibilidades que envejece sola.

Y mientras tanto ha pasado algo que lo cambia todo: cada plugin está sacando su propio MCP. Ya no hace falta que Kodavio reimplemente lo que hace otro. Le basta con reconocerlo y trabajar con él.

Esa es la dirección de la 3.0. En vez de ampliar superficie, Kodavio reconoce otros servicios MCP y los absorbe. Menos cosas, mejor hechas, y lo que traigas de fuera funcionando dentro.

No queremos que Kodavio lo haga todo. Queremos que lo que haga, lo haga bien.

Ya está hecho. Las suscripciones y la gestión de licencias han cambiado de sistema, y a partir de ahora todo vive en el mismo sitio: tu cuenta, tus licencias y tus pagos.

No tienes que hacer nada. Pero una mudanza de este tipo puede dejar algún cabo suelto, así que te pido una cosa: si entras y algo no funciona como esperabas —no ves tu licencia, no puedes descargar, el acceso te da error— escríbeme. No lo dejes pasar pensando que es cosa tuya. Lo miro y lo arreglo.

Prefiero que me lleguen diez avisos y que nueve sean falsa alarma, a que alguien se quede semanas sin poder entrar.

Tengo una web con Woocommerce y un tema hijo de Bricks donde tengo las personalizaciones con CSS además de las de Woocommerce.
¿Cómo puedo hacer el cambio a FlowKit sin perder todo lo que tengo hecho de manera fácil?

De un vistazo:

• Editor de Bricks más ágil — barra de viewport, snap de breakpoint, barra de widgets siempre a mano y conmutador de tipo de texto.
• Módulo Desistimiento UE para tu tienda WooCommerce.
• IA al día — catálogo de modelos actualizado y más fidelidad imagen→sección.
• Núcleo más limpio y robusto.

Editor de Bricks: menos fricción al construir

El bloque más grande de esta versión. Mejoras sobre el propio editor de Bricks, todas OFF por defecto (las enciendes en el panel):

• Barra de viewport con snap de breakpoint funcional: al cruzar cada ancho, cambia el dispositivo activo de Bricks —lee el umbral real de cada breakpoint—, así el editor y tu diseño van sincronizados.
• Barra de widgets siempre visible y plegada: sin la zona sensible del borde que chocaba con los controles de estructura, y con la lista ampliada a 15 elementos, filtrada por los que realmente tienes.
• Conmutador de tipo de texto (Titular / Texto / Enriquecido) integrado en el menú de clic derecho de Bricks.
• Ajustes finos de elementos: textarea, tamaño de controles, tags por defecto.

Desistimiento UE: tu tienda al día con la Directiva

Ya os lo presentamos, y con la 1.1.0 queda integrado del todo: botón como elemento de Bricks, cálculo del plazo, confirmación, email de acuse, estado «Desistido» y acceso para invitados por enlace + PIN. Desactivado por defecto.

IA al día

• Catálogo de modelos actualizado: Opus 4.8 / 4.7 / 4.6, Sonnet 5 por defecto, Haiku 4.5 y OpenRouter. El proxy omite temperature en los modelos que no la aceptan (adiós al error 400).
• Más fidelidad imagen→sección y ruta de imagen unificada a multimodal inline.
• Sinergia opcional con Kodavio vía WP Abilities.

Más limpio por dentro

Carga perezosa de los paneles de admin, text domain unificado, clases muertas fuera. Menos peso, mismo comportamiento en los módulos free.

Es la actualización más grande hasta la fecha: recoge todo lo trabajado desde la 0.1.7 y deja a Kodavio listo para el día a día real. Aquí va lo que trae.

De un vistazo:

• Backup y rollback por acción — deshaz la última escritura, una concreta o todas las de un archivo, con historial y botón Restaurar.
• Perfil de ejecución — tú marcas cuánta prudencia usa el agente (Rápido / Equilibrado / Seguro), tengas o no el kit.
• Decisiones con alternativas — cuando hay varias formas de hacer algo, Kodavio te da las opciones con pros y contras en vez de elegir a ciegas.
• Memoria de sesión por defecto — una sola llamada al arrancar y el agente ya sabe dónde está.
• Traducciones (.po/.mo) y creación de carpetas acotada.
• Más rápido y más robusto en todo.

Backup y rollback: deshacer por acción, no por sesión

Antes cada subsistema guardaba sus copias por su cuenta. La 0.2.0 lo unifica en un solo registro: cada escritura que toca algo irreversible queda anotada como una operación con su identificador (op_id).

Deshacer es por acción, de tres formas: la última (rollback latest), una concreta (rollback op_id=…) o todas las de un archivo (rollback path=… since=ayer).

Y en Kodavio › Tools tienes el Historial de backups: fecha, operación, herramienta y ruta, con Restaurar en cada fila. Antes de restaurar, guarda una copia del estado actual —por si el rollback tampoco era lo que querías—.

Es selectivo: lo que WordPress ya cubre con sus revisiones no se duplica; donde no llega —opciones, código, mu-plugins, el kit de Elementor, los globals de Bricks— sí hay copia propia. Con retención configurable (por defecto 7 días) y una tarea diaria que barre lo antiguo.

Perfil de ejecución: tú marcas la prudencia

Antes el "perfil" era una preferencia que las skills ignoraban. Ahora es vinculante desde el propio plugin: eliges el nivel en Kodavio › Tools y el agente ajusta su disciplina de escritura.

• Rápido: escribe directo, con dry-run solo en lo destructivo.
• Equilibrado (por defecto): dry-run en lo destructivo, copia de seguridad y verificación ligera.
• Seguro: dry-run siempre, leer antes de escribir y verificación completa.

Lo mejor: funciona aunque no tengas el kit descargado. El nivel viaja en el arranque de sesión, así que cualquier agente que conecte con tu sitio lo respeta. Y nunca rebaja los guardarraíles: en producción se sigue trabajando en borrador y con confirmación.

Decisiones con alternativas: opciones, no adivinanzas

Cuando un objetivo tiene varias vías —¿modelo el CPT con código nativo, ACF, JetEngine o Pods?—, elegir por ti puede condicionar tu modelo de datos, tu día a día o tu factura. La 0.2.0 añade options-for: le dices el objetivo y te devuelve las opciones con pros y contras, marca cuáles tienes instaladas y decide si preguntarte o resolver.

Y si ya lo tienes claro, se lo dices una vez: preferencias por sitio. "Para CPTs, JetEngine". A partir de ahí deja de preguntar en ese sitio.

Traducciones y carpetas

• i18n: Kodavio ya lista y lee tus .po, edita entradas y compila el .mo que WordPress carga en tiempo real. Todo acotado al directorio de idiomas, con copia y dry-run.
• Crear carpetas, pero acotado: solo dentro de bases permitidas (idiomas, uploads, plugin/tema), nunca rutas arbitrarias.

Memoria de sesión, ahora por defecto

Una sola llamada al arrancar —context-bootstrap— recupera el scope del proyecto, el sistema de diseño activo, tus avisos e instrucciones, tus preferencias y el perfil de ejecución. El agente entra a cada sesión sabiendo dónde está, sin que se lo recuerdes.

Más rápido, más robusto

• Menos esperas: se memoiza el trabajo caro que antes se repetía en cada llamada, se elimina un N+1 en las analíticas y la comprobación de licencia ya no puede colgar la petición.
• mu-plugins a prueba de cortes: la escritura es atómica, una lectura concurrente nunca pilla el archivo a medias.
• Detección de constructor unificada: una misma página se resuelve igual mire quien la mire.

Como siempre: dry-run, confirmación y verificación posterior. Buena parte de este corte sale de vuestro feedback —así que gracias por probar y reportar—. 🙌

Pues eso, que sólo lo debería ver el administrador.

Hola a todos 👋

Os traemos una de las novedades que llegan con el lanzamiento de FlowKit: el módulo Desistimiento UE, dentro del paquete E-commerce Tools.

El contexto, en corto. Desde el 19 de junio, la Directiva (UE) 2023/2673 obliga a toda tienda online que venda a consumidores europeos a ofrecer un botón de desistimiento: visible, tan destacado como el de compra, disponible durante todo el plazo y con confirmación por email. Si el cliente no puede encontrarlo, su plazo pasa de 14 días a 12 meses. No es un detalle menor.

Cómo funciona en FlowKit. Fiel a la filosofía de construir todo a tu manera:

• El botón es un elemento de Bricks («Botón de desistimiento (UE)», categoría Flowtitude: Mi Cuenta). Lo activas en el panel y lo colocas donde quieras en tus plantillas de pedido, con tus clases de Tailwind. Consejo: ponlo también en la plantilla de «Pedido recibido», que es donde aterrizan los invitados.
• El plazo (14 días por defecto) se calcula desde la entrega o desde la fecha del pedido, según configures. Dentro del plazo, botón activo con fecha límite; pasado el plazo, no desaparece: muestra «plazo finalizado», que es lo que te protege de la ampliación a 12 meses.
• Al confirmar, FlowKit registra el desistimiento, pasa el pedido a «Desistido», te avisa y envía al cliente el email de acuse con tus instrucciones de devolución. Todos los textos son editables desde el panel.
• Exclusiones: casilla por producto (Avanzado) o categorías completas, para personalizados, perecederos, digital consumido, etc.

Y la parte que más nos gusta: invitados sin cuenta. Si el cliente compró sin registrarse, puede desistir igual: cada pedido lleva un enlace de acceso directo en sus emails y un PIN de 6 dígitos en el recibo. Con el shortcode [ft_order_access] puedes montar un formulario de rescate (nº de pedido + email + PIN) en cualquier página. Cada compra tiene sus datos de acceso; nadie necesita crear una cuenta.

Todo llega desactivado por defecto y se enciende desde FlowKit → E-commerce → pestaña «Desistimiento UE».

Un recordatorio honesto: FlowKit pone la mecánica; la redacción legal final de vuestros textos conviene pasarla por asesoría jurídica.

🚀 Lanzamos FlowKit junto a Kodavio a principios de la próxima semana. Si tenéis tiendas con clientes europeos, este módulo solo ya justifica la suscripción.

¿Dudas sobre cómo lo encajaríais en vuestras plantillas? Os leemos en los comentarios.

Aviso rápido sobre las versiones que están saliendo estos días.

Es muy probable que esta semana veáis que nos saltamos alguna versión intermedia. En vez de ir soltando 0.1.8, 0.1.9 y demás como parches, estamos apuntando directo a la 0.2.0.

La 0.2.0 será el pistoletazo de salida — la primera versión pensada para meter en producción con confianza. Lo que trae:

• Sistema de licencias integrado: activación por clave, límite de sitios por plan, renovación desde el propio wp-admin. Es el bloque que estaba pendiente para separar la beta comunitaria del producto vendido.
• Más características y mejoras que iremos desglosando en el changelog cuando cerremos scope.
• Auditoría y limpieza del código: estamos entrando en la fase de pulido — código muerto fuera, bugs conocidos cerrados, rendimiento afinado. Queremos que la 0.2.0 se sienta sólida desde el primer minuto.

La idea es que cuando alguien instale Kodavio 0.2.0 en un sitio real, la sensación sea «esto está pulido» y no «esto es una beta con potencial». El agente por dentro sigue siendo el mismo — lo que cambia es el envoltorio, la robustez y la experiencia de administración.

Gracias, @luismm. Sin tus feedbacks constantes. Cada feedback que has dejado ha empujado alguna decisión útil, aunque no siempre acabe en algo visible.

Iré contando por aquí cuando la 0.2.0 esté cerca. Mientras tanto, si estás usando alguna beta y ves algo raro, sigue reportándolo — se lee todo.

Hoy le he pedido que entre en la web que aún está publicada y que vamos a cambiar, y donde no tengo instalado Kodavio, y obtenga todas las Urls de páginas, post, productos, etc. y que proponga redirecciones 301 a sitios de la nueva web, en la que estamos trabajando con Kodavio. Lo ha hecho todo, ha entrado, leído sacado un mapa web y propuesto redirecciones de forma coherente a URLs de la nueva web.
Luego le he dicho que cree las redirecciones en Rank Math SEO. Lo he comprobado, después de que me dijera que lo había hecho ya, y afirmo que así lo ha hecho. Además de manera ordenada y correctamente.
Otra ventaja de Kodavio.

Si usas FDS, tienes la tipografía resuelta sin pensar en píxeles.

En vez de decidir text-5xl aquí y text-3xl allá, pones la clase por lo que ES:

.display para el impacto del hero.
.heading para los títulos (el comodín del día a día).
.subheading para apoyar.
.text-medium para el cuerpo.

¿Qué ganas con eso?

Jerarquía clara. Eliges por significado (display › heading › subheading › texto), no por un tamaño suelto.

Composición fina de regalo. Los titulares llevan text-balance y el cuerpo text-pretty, así que las líneas nunca quedan feas.

Una sola fuente de verdad. La escala entera sale de unos pocos tokens: ajustas el ritmo una vez y se propaga a todo el sitio.

En resumen: menos decisiones por título y más consistencia.

¿Usas una escala tipográfica con nombres o sigues poniendo tamaños a mano en cada título? 👇