Ir al contenido principal

Le he pedido a Kodavio que me liste las imágenes que no tienen alguno de estos campos rellenos. En la web que estoy trabajando me ha listado 2.398 imágenes o medios, de los cuales 1.172 no están completos. Ha creado un Excel con Urls, y los campos de las imágenes...
Me ha propuesto los textos a incluir y espera que los revise.
Le he preguntado si puede incluir los textos propuestos en las imágenes y me ha contestado esto:
Sí, puedo hacerlo después de tu aprobación, pero con una condición técnica:

Ahora mismo Kodavio solo permite listar medios (wp-list-media), no actualizarlos. Para escribir ALT y descripción en cada imagen necesitaré usar una vía segura alternativa, por ejemplo:

  1. Crear/usar un endpoint temporal protegido en WordPress para actualizar metadatos de medios por ID.
  2. Ejecutar los cambios por lotes desde el CSV aprobado.
  3. Verificar después una muestra o el lote completo leyendo de nuevo la biblioteca.

Y luego al intentar me dice...
Primer lote aplicado parcialmente:

  • 100/100 descripciones vacías actualizadas.
  • 0 descripciones vacías restantes en el lote 001.
  • No cambié ninguna descripción que ya tuviera contenido.
  • No cambié títulos.
  • No pude actualizar ALT porque Kodavio no expone escritura de meta de medios (_wp_attachment_image_alt).

He creado el endpoint PHP que me ha dado y se han incluido todos los Alt.

Tres versiones en dos días, con un hilo conductor: que puedas fiarte de lo que Kodavio te dice. Resumen rápido de lo que ha mejorado y lo nuevo que puedes probar ya.

Fiabilidad: lo que se escribe es lo que hay. Las conversiones Elementor ↔ Bricks con estructuras anidadas ya conservan siempre la jerarquía (antes podían quedar secciones vacías en el editor). Las copias de seguridad y el rollback funcionan también con contenido en castellano — acentos y caracteres especiales sobreviven intactos. Y se acabaron los falsos resultados: si una operación falla, devuelve un error claro; si dice que ha escrito, ha escrito.

Actualizaciones verificadas. El actualizador comprueba la huella SHA-256 de cada paquete antes de instalarlo. Si el archivo no coincide exactamente con el publicado, la actualización se aborta. Tu sitio ya lo está usando sin que hagas nada.

Nuevo: migración Tailwind v3 → v4. Para sitios con WindPress: una auditoría de solo lectura detecta las clases renombradas o eliminadas en v4 dentro de tu contenido de Bricks, Elementor y Gutenberg, y te avisa de los cambios de comportamiento que un renombrado no cubre. La aplicación es por página, con dry-run, copia de seguridad y rollback. Lo que requiere criterio humano se marca, no se reescribe solo.

Nuevo: SEO sea cual sea tu plugin. Kodavio ahora lee, analiza y rellena los snippets de SEO (título, descripción, keyword, Open Graph, robots…) con las mismas órdenes uses Rank Math, Yoast o SEOPress. El análisis señala qué corregir en cada página; tu agente redacta y aplica con verificación. Kodavio nunca inventa títulos por su cuenta.

WindPress: manos quietas. Kodavio ya no inyecta nada en WindPress: lee la configuración de Tailwind que tengas — la que sea — y solo escribe cuando se lo pides explícitamente. Esto corrige además los avisos PHP que algunos visteis con ambos plugins activos. Gracias a quien lo reportó: ese aviso destapó todo lo demás.

Y por debajo. Cada paquete se prueba ahora instalándose en un WordPress real antes de publicarse, además de la batería de tests de siempre. Los fallos que encontráis en beta se convierten en comprobaciones automáticas: la mejor manera de que no vuelvan.

Actualiza desde tu panel de plugins cuando quieras — la 0.1.5 ya está en el canal. Y si algo no cuadra, cuéntalo en la comunidad: como ves, los reportes se convierten en versiones.

Kodavio: qué ha cambiado en las últimas versiones (0.1.3 → 0.1.5)

Estaba probando en una web que tenía bloqueado la actualización de Windpress para evitar los problemas que entonces estaba dando este plugin.
Cuando he instalado Kodavio ha aparecido este error:
Warning: Undefined array key "relative_path" in /home/web/empacke.com/wp-content/plugins/windpress/src/Core/Runtime.php on line 128 Warning: Undefined array key "relative_path" in /home/web/empacke.com/wp-content/plugins/windpress/src/Core/Runtime.php on line 128 Warning: Undefined array key "relative_path" in /home/web/empacke.com/wp-content/plugins/windpress/src/Core/Runtime.php on line 128 Warning: Undefined array key "relative_path" in /home/web/empacke.com/wp-content/plugins/windpress/src/Core/Runtime.php on line 128
lo escribo por si Angel Julian debe tenerlo en cuenta.

He seguido trabajando con Kodavio en el mismo sitio web. Esta vez para hacer una segunda página, y os comento como fue:
La primera parte de crea una nueva página llamada de tal forma y con esta URL... todo eso lo hace fenomenal, igual que listarte información, etc.
Comentar que en esta ocasión usé GPT-5.5 con el contrato de 20$ de chatGPT.
Después le pasé una captura de pantalla de Figma de cómo quería que fuese esa página, y que mantuviera el sistema de diseño así como las decisiones e indicaciones tomadas para la anterior... Y empezó a trabajar.
Lo que hizo se parecía un poco, ya bastante más que lo que ocurrió en las primeras pruebas, pero en lugar de modificarlo yo en Bricks, insistí dándole cambios.
Igualmente le dije que redactara los titulares y textos y que ocuparan el mismo espacio que los de la maqueta, y que estuvieran redactados en español de México (ya que es una web para una empresa mexicana). También dibujó en SVG los iconos, e hizo unas simulaciones donde había imágenes, ya que no estaban subidas estas en Medios, en Wordpress.
Esto le llevó (nos llevó) toda una mañana y parte de la tarde. El objetivo total no se cumplió, pero quedó relativamente aceptable.
Dejo captura de la maqueta y del resultado final realizado con Kodavio.

Cada vez se parece más Cada vez se parece más

¿Sabías que en FDS, al poner .has-background a una <section>, no solo se aísla con el padding correcto… sino que ajusta también el de las secciones vecinas?

Resultado: bloques de color que nunca quedan "pegados", sin que vayas sección por sección.

¿Qué otro truco de FDS te ha ahorrado más tiempo? 👇

Secciones con el aire perfecto, sin tocar nada

Vemos a menudo la misma confusión, así que vamos a aclararla sin humo.

Qué es Kodavio. Un plugin de WordPress que conecta tu agente de IA (Claude Code, OpenCode, Cursor…) con tu sitio por MCP: Bricks, contenido, queries, JetEngine… con permisos controlados. En una frase: el puente para que tu IA opere de verdad sobre tu WordPress, sin escribir scripts. Hace la ejecución fiable y repetible.

Qué NO es. No es un botón mágico que escupe un diseño pixel perfect con solo pedírselo. No sustituye al modelo, a un buen prompt, a un sistema de diseño (para eso está FDS), ni a tu criterio.

El mito (que alimentan muchos youtubers). «Escribe un prompt y ten un diseño perfecto». Esas apps que deslumbran en los vídeos van por patrones: las usas tres o cuatro veces y pierden la chispa — todo empieza a parecerse y el impacto se desvanece. Es un truco de demo, no una herramienta de trabajo.

La realidad. Un buen resultado sale de la suma: modelo capaz + prompt claro + un sistema (FDS) + criterio humano. Kodavio pone la pieza que falta —que tu IA ejecute sobre WordPress con seguridad y a tu manera—; el diseño lo pones tú y tu sistema.

Kodavio te da superpoderes de ejecución, no te ahorra pensar el diseño. Y por eso, bien usado, rinde más que cualquier «app mágica».

Qué es Kodavio — y qué NO es

Estamos trabajando en una nueva versión de Kodavio centrada en mejorar cómo el agente entiende, organiza y ejecuta los trabajos dentro de WordPress.

El objetivo no es solo añadir más funciones, sino hacer que Kodavio sea más útil en situaciones reales: crear páginas, trabajar con Bricks, Elementor, Gutenberg, WindPress/Tailwind, sistemas de diseño, contenido dinámico, migraciones entre builders y tareas de administración.

Una de las mejoras en las que estamos trabajando es que Kodavio pueda reconocer mejor el tipo de tarea que se le pide y seguir un flujo más adecuado para cada caso. No es lo mismo gestionar plugins, crear una página desde una maqueta, ajustar un sistema de diseño, convertir entre builders o estructurar CPTs y campos personalizados.

También estamos revisando cómo mejorar la supervisión del proceso, para que sea más fácil detectar cuándo el agente va por buen camino, cuándo necesita más contexto y cuándo el resultado no se corresponde con lo esperado.

Nos interesa mucho probar esto con casos reales. Si estás usando Kodavio, tus comentarios son especialmente valiosos: qué funciona, qué se queda corto, dónde se pierde el agente, qué esperabas que hiciera y qué resultado obtuviste.

Estas pruebas nos ayudan a mejorar tanto el plugin como la metodología de uso, para que Kodavio sea cada vez más práctico, más claro y más fiable en proyectos reales de WordPress.

Si quieres participar, comparte tu caso, tu configuración, el builder que usas y qué intentabas conseguir. Cuanto más concreto sea el feedback, más fácil será convertirlo en mejoras reales.

Estamos mejorando Kodavio con inteligencia más guiada

Estoy trabajando en una web que estaba empezada pero tenía sólo una página.
La configuración es
Brikcs Versión: 2.3.6
Flowtitude Child (Bricks)Versión: 1.0.12
flowtitude-1.1.3.windpress
WindPress Versión 3.3.83
WindPress Fix Versión 1.3.1
Trabajando desde OpenCode con OpenAI usando la versión de pago de ChatGPT

En cuanto a activar y desactivar plugins, sacra listados, etc. va perfecto.
Pero en cuanto a hacer el diseño no me ha gustado nada, pues me dice que no puede usar el sistema de diseño de WindPress y Talwind, le paso maquetas para que vea el diseño, contenido, etc. y lo que crea no se parece en nada. Lo primero que hizo lo hizo todo en widget code, y en plantillas php, supongo.
No me ha creado textos nuevos decentes, además de no usar la Ñ, Por mucho que le digo que use las imágenes que se encuentran en medios, y me dice que los ha usado, no carga nada. Y cada vez que le indico cambios vamos a peor. Eso sí, mucha palabreía y diciendo lo que supuestamente está haciendo, aunque el resultado no incluyera nada de lo que decía.
Supongo que será por la IA que estoy usando, pero principalmente esperaba que funcionase mejor o directo con los sistemas de Flowtitude.

Ya está disponible Kodavio 0.1.2 beta, una nueva actualización de Kodavio enfocada en mejorar la estabilidad, la experiencia de uso y la integración con los principales builders de WordPress.

Esta versión refuerza el trabajo con Bricks, Elementor y Gutenberg, mejora la fiabilidad de los flujos MCP y deja el plugin mejor preparado para instalaciones, pruebas y validaciones en entornos beta.

Entre las novedades principales:

  • Mejoras de estabilidad en la conexión MCP.
  • Integración más robusta con builders WordPress.
  • Mejoras en los flujos de creación, lectura y validación de contenido.
  • Ajustes en el sistema de actualizaciones.
  • Paquete instalable actualizado para pruebas beta.
  • Mejoras internas de calidad y mantenimiento.

Kodavio sigue avanzando como herramienta para conectar agentes de IA con WordPress de forma más segura, estructurada y compatible con los flujos reales de diseño, contenido y construcción visual.

La versión 0.1.2 beta ya puede descargarse e instalarse manualmente desde el área de descargas.

Kodavio 0.1.2 beta ya está disponible

Ya está disponible FlowKit 1.0.12, una actualización centrada en pulir dos zonas delicadas del producto: la gestión de Site Layer y la convivencia entre FDS/TDSM, WindPress y Bricks.

No es una release de grandes fuegos artificiales. Es una release de las buenas: menos ambigüedad en el panel, menos fricción al editar archivos y menos riesgo de trabajar con variables obsoletas dentro del builder.

Lo más importante

Site Layer ahora dice la verdad

Uno de los ajustes clave de esta versión está en el panel de Site Layer.

Hasta ahora, en algunos estados iniciales era posible ver una estructura «esperada» aunque todavía no existieran archivos reales. Eso podía hacer pensar que el Site Layer estaba ya listo para editar cuando en realidad la carpeta no existía o estaba vacía.

En la 1.0.12 el panel distingue mejor entre:

  • No creado
  • Creado pero vacío
  • Estructura disponible
  • Problema detectado

Además, cuando todavía no hay nada real que editar, ya no se muestra un árbol engañoso: aparece un estado vacío más claro y una acción coherente para crear o generar la estructura base.

Árbol de archivos más claro y más útil

El árbol de Site Layer también gana legibilidad:

  • Los estados ya no aparecen como simples puntos visuales.
  • Ahora se muestran badges con texto como Preview, Editable, Sistema, OK o Falta.
  • La acción de edición es más visible y directa.

Con esto resulta mucho más fácil entender qué archivo existe de verdad, cuál se puede editar y cuál forma parte de la base del sistema.

Mini editor más limpio

También se ha refinado el mini editor de archivos de Site Layer.

Se elimina el aviso innecesario de recarga heredado del editor nativo de WordPress, que entorpecía una tarea que debería ser rápida: abrir, tocar una línea y guardar.

La idea se mantiene intacta: cambios sencillos, rápidos y controlados, con backup automático y validación cuando toca.

FDS y Bricks: menos riesgo de variables obsoletas

En esta versión se ha afinado además el comportamiento entre Flowtitude Design System, WindPress y las variables nativas de Bricks.

Hasta ahora, cuando Bricks conservaba una copia de las variables windpress, podía darse el caso de trabajar con un snapshot viejo dentro del builder. Eso abría la puerta a estilos inconsistentes o diagnósticos confusos.

Desde la 1.0.12:

  • al guardar tokens en FDS/TDSM, la copia windpress de Bricks se limpia siempre
  • si la protección está activada, además Bricks no puede volver a persistir esa categoría
  • si la protección está desactivada, Bricks podrá volver a regenerarla más adelante, pero ya no se queda una copia vieja justo después del guardado

En otras palabras: se reduce el riesgo de trabajar con variables obsoletas sin obligar a un único modo de uso.

Cómo actualizar

La actualización estará disponible como Flowtitude Child / FlowKit 1.0.12.

Si el actualizador tarda en reflejarla, recuerda que el proxy puede necesitar su siguiente ciclo de refresco o una limpieza de caché según la instalación.

En resumen

FlowKit 1.0.12 no intenta hacer más cosas. Intenta hacer mejor las que ya estaban en el centro del flujo: editar, entender el estado del sistema y evitar incoherencias silenciosas.

Y eso, en un producto que se usa de verdad en proyectos reales, vale bastante.

FlowKit 1.0.12 ya está disponible: Site Layer más claro y FDS más fiable con Bricks