El plugin Kodavio convierte cada WordPress en un servidor MCP con habilidades seguras (builders, diseño, conversión, admin). Cada vez que conectas un sitio sigues su prompt de conexión y tu agente — Claude Code, Cursor, Codex, OpenCode o Kilo — ya lo tiene disponible. Kodavio guarda además en la base de datos de cada sitio su propia memoria — design memory (tokens, paleta), scope del proyecto, change log — leíble con kodavio/design-read, kodavio/scope-read.

Lo que falta es la otra mitad: memoria del operador sobre cada sitio desde fuera (caveats de hosting, idiosincrasias del cliente, incidencias pasadas, recordatorios concretos) y reglas distintas según el entorno. Esa capa cliente es el Kodavio Agent Kit: un workspace clonable, todo en markdown portable, sin lock-in.

Principio: el agente es el autor (copy, jerarquía, dirección de diseño), Kodavio es el ejecutor, y tú apruebas lo irreversible.

Por qué lo necesitas

Sin esta capa, el modelo decide solo cosas que no debería:

• Cuándo está apuntando a producción y cuándo a staging si tienes los dos MCPs cargados del mismo cliente (un prompt ambiguo puede ir al sitio equivocado).
• Si una página existe (edit) o no (create). Reconstruir una publicada es irrecuperable.
• Si la operación pide gate humano o puede ejecutarla sola, según el entorno.
• Si el sitio tiene caveats que prohíben ciertas acciones (PHP roto, hosting frágil, sin backups).

El kit lo resuelve con un registro de sitios (registry/sites.json), una matriz de guardarraíles por entorno, un protocolo de sesión que el agente ejecuta antes de tocar nada, y una memoria operativa por sitio (sites/{slug}/NOTAS.md) que sobrevive a las sesiones.

Instalación en 5 minutos

Requisitos: agente con MCP (Claude Code recomendado), Node.js ≥ 18, plugin Kodavio instalado y acceso admin al WordPress.

# 1. Clonar el kit
git clone git@github.com:flowtitude/kodavio-agent-kit.git
cd kodavio-agent-kit

# 2. Crear tu registro local desde la plantilla (queda fuera de git)
cp registry/sites.example.json registry/sites.json

# 3. Abrir el kit con tu agente
claude # o: cursor . / codex / opencode / kilocode

Al abrirlo, el agente lee su puerta de entrada (AGENTS.md, o CLAUDE.md en Claude Code) y queda operativo: ya conoce el protocolo, las reglas y las skills. No hay build ni dependencias.

Windows: clona con -c core.symlinks=true (Developer Mode), o los symlinks de CLAUDE.md y .claude/{skills,agents} llegan rotos.

Conectar tu primer sitio (un comando)

/wp-onboard-site

(En Cursor / Codex / OpenCode / Kilo: "da de alta un sitio nuevo".) El agente te entrevista, verifica que Kodavio responde, registra el MCP en tu herramienta, rellena registry/sites.json con los datos reales (wp-get-config-summary) y crea su memoria. Sin agente: ./scripts/add-site.sh.

Empieza por un sitio de dev o staging. Aprende ahí, comete los errores ahí, y pasa a producción cuando el flujo te resulte natural.

Cómo se trabaja después

Cada sesión empieza por wp-site-session: el agente identifica el sitio, carga su memoria y aplica los guardarraíles del entorno. Después, en lenguaje natural:

En producción, el agente nunca publica, instala plugins, escribe PHP, borra ni hace operaciones masivas sin tu confirmación explícita.

Qué viene en el kit

• 12 skills de cliente para alta de sitio, planificación, construcción, conversión, salud, seguridad, contenido, FDS, Tailwind/WindPress, patrones y sesión.
• 10 subagentes especializados: auditor, operator, bricks/elementor/gutenberg-operator, content-architect, woo-operator, content-writer, verifier.
• 3 reglas duras locales: guardarraíles por entorno, protocolo Kodavio (orden canónico de llamadas) y código en vivo.
• Lanzador MCP con credenciales en el almacén del SO (Keychain / libsecret / pass / Credential Manager). Las Application Passwords no viven en archivos de config.

Seguridad y mantenimiento

El repo nunca contiene datos reales: registry/sites.json, sites/{slug}/NOTAS.md y state.md están en .gitignore. Solo se versionan plantillas. Las credenciales se quedan en el almacén del SO.

Actualizar: git pull. Tus datos locales no se tocan. Mejoras del kit → issues/PRs en su repo. Errores del plugin → canal de la beta de Flowtitude.

Resumen:

• Fuentes de diseño (Design Sources) — capa nueva que unifica detrás de un solo contrato seguro las cinco fuentes donde puede vivir un sistema de diseño.
• WindPress in-place — los tokens se escriben dentro de tu sistema existente, no en un archivo aparte.
• Patrones — tres secciones nuevas, biblioteca portable entre sitios y modo por sitio.
• Auto-rollback ampliado a las escrituras de archivos de código (antes solo mu-plugins).
• Edición de PHP desbloqueada en hostings sin PHP CLI.
• Reorden a la par en los tres constructores.

Fuentes de diseño (Design Sources)

Antes, cada framework tenía su mecánica: archivos de WindPress, opciones de Bricks, Kit de Elementor, theme.json de Gutenberg, overrides de ACSS / Core Framework. La 0.1.7 lo unifica detrás de un solo contrato: listar, leer, parchear, hacer copia de seguridad y restaurar. Mismo flujo independientemente del backend.

Cubre cinco proveedores: WindPress · Globals de Bricks · Kit de Elementor · theme.json · ACSS / Core Framework. Toda escritura es en seco por defecto, hace copia de seguridad antes de tocar nada, devuelve diff y es restaurable por id.

Ejemplo: cambias --color-primary en un sitio WindPress, ves el diff antes de aplicar, queda registrada la copia, y si algo se ve mal restauras con el id. Mismo recorrido si lo que tocas es la paleta de Bricks, los colores del Kit de Elementor o settings.color.palette de theme.json.

WindPress / Tailwind: edición sobre tu sistema existente

En 0.1.6 al aplicar tokens Kodavio podía acabar creando un archivo de tema paralelo. 0.1.7 sigue las importaciones de tu main.css, localiza el archivo donde viven tus tokens (el primero con un bloque @theme) y los integra ahí. Actualiza los que ya hay, añade los nuevos en su sitio. Si en algún caso prefieres un archivo separado, sigue siendo opción explícita.

Ejemplo: tu setup tiene main.css → tokens.css. Cambias --color-primary y aterriza en tokens.css con un backup, no en un kodavio-theme.css aparte.

Patrones: biblioteca portable, tres nuevos y modo por sitio

• Tu propia biblioteca, portable: exportas tus patrones como pack de datos y los importas en otro sitio. Validación previa, vista previa por defecto, los patrones de fábrica protegidos.
• Tres secciones nuevas, sin imagen: stats band, steps y quote. Funcionan igual en Bricks y Elementor.
• Modo por sitio: sugerir (defecto), preferir u off. No es candado: aplicar un patrón a mano siempre funciona.

Ejemplos: te creas un pack con tus 4 héroes y lo importas en cada cliente nuevo. En el sitio de un banco pones el modo en off para que el agente nunca aplique patrones sin pedírselo explícitamente.

Nota honesta: en Elementor los patrones todavía emiten estructura sin propagar color/tipografía al widget atómico; ese cierre llega en 0.1.8.

Reorden a la par en los tres constructores

• Bricks: mover secciones de primer nivel ya se aplica de verdad (antes funcionaba dentro de contenedor, no en la raíz).
• Gutenberg: estrena el mover bloques sin reconstruir, conservando el resto intacto. En 0.1.6 esto solo existía en Bricks y Elementor.

Auto-rollback ampliado y PHP sin CLI

En 0.1.6 estrenamos un mecanismo para mu-plugins: tras escribir, se comprueba que el sitio sigue cargando (loopback a la portada) y si la edición lo ha tumbado, revierte sola el cambio. 0.1.7 extiende ese mismo guard a cualquier archivo de código (wp-write/patch/restore-code-file).

Ejemplo: editas un plugin activo, el cambio mete un fatal, el sitio devuelve 500. Kodavio lo detecta y restaura la copia anterior. Tú no llegas a perder el acceso al admin.

Y en hostings sin PHP de línea de comandos —común en compartidos y gestionados— Kodavio valida la sintaxis en proceso antes de escribir, así que la edición de PHP deja de estar bloqueada en sitios donde antes te rechazaba todo .php.

Otros arreglos

• design-delete sobre una sección de la memoria de diseño exige ahora confirm_destructive (antes una llamada remota podía borrarla sin confirmación).
• Changelog acumulado durante el desarrollo y gate de release que rechaza una versión sin entrada de changelog.

0.1.7 es la versión que recoges al actualizar si ya estás en la beta privada. Como siempre: dry-run, confirmación y verificación posterior. La apertura comercial de la beta pública es el 1 de julio en flowtitude.com/kodavio.

tengo una antigua web realizada con WP Bakery y el theme TheGem y quiero rehacerla con Bricks y Tailwind.
¿Puede ayudarme Kodavio a conseguirlo? la web tienes CPTs, Blog extenso, y plugins que ayudan a mostrar galerías de portfolio.
De momento voy a sacar una copia y trabajarla en staging hasta tenerla resuelta y luego darle el cambio.
¿Cuál sería el proceso aconsejado con Kodavio?
Gracias.

Integración Avanzada Con Bricks, Iconos Y Contenido Reutilizable

Además del modelo de contenido y la interfaz editorial, se realizaron varias integraciones específicas con Bricks Builder para que el sistema dinámico pudiera trabajar de forma más natural dentro del editor visual.

El objetivo fue conectar los datos creados en WordPress con las plantillas Bricks, los shortcodes, los iconos y el selector de Dynamic Data.

Shortcodes Y Helpers Para Bricks

Algunos elementos de Bricks, especialmente ciertos campos text-basic, no ejecutaban shortcodes de forma directa en todos los contextos necesarios.

Para resolverlo se crearon helpers y buffers de salida que procesan dinámicamente ciertos shortcodes en frontend.

Entre los shortcodes implementados se encuentran:

• [pc_family_meta]
• [pc_product_icon]
• [pc_product_family_link]
• [pc_global_icon]

Estos shortcodes permiten insertar contenido dinámico en nodos Bricks existentes sin rehacer la plantilla completa.

Por ejemplo, el shortcode [pc_family_meta] permite que un texto de la plantilla archive lea un campo de la familia actual. Si el campo está vacío, puede mostrar un fallback.

Librería Global De Iconos SVG

Se creó una librería global editable de iconos SVG.

En lugar de pegar SVGs directamente en cada producto o bloque, se centralizaron los iconos mediante claves reutilizables.

Ejemplos de claves:

• bag
• weight
• print
• measure
• leaf
• recycle
• box
• gear
• sack
• medical
• school
• ecommerce

La ventaja es que un icono puede reutilizarse en distintos productos o familias. Si el SVG asociado a una clave cambia, se actualiza en todos los lugares donde se use esa clave.

La librería permite:

• Editar SVGs globales.
• Añadir nuevos iconos.
• Activar o desactivar iconos.
• Usar iconos en productos.
• Sanitizar el SVG con una whitelist segura.

Iconos En El Editor De Producto

Los productos incluyen campos de icono para beneficios e items de sustentabilidad.

Se conectó la librería global con los selectores del editor, de forma que los iconos disponibles ya no dependen sólo de una lista fija en código.

Esto permite ampliar la librería sin tener que modificar manualmente cada producto.

El usuario puede seleccionar una clave de icono desde el editor de producto, mientras que el SVG real queda gestionado desde la librería global.

Integración Con Dynamic Data De Bricks

Una mejora importante fue incorporar los campos propios dentro del selector de Dynamic Data de Bricks.

Bricks ya muestra datos nativos de WordPress y puede mostrar datos de JetEngine si el plugin está activo. Sin embargo, los campos creados a medida no aparecían de forma organizada para el usuario.

Para resolverlo se creó un MU plugin que usa filtros nativos de Bricks:

• bricks/dynamic_tags_list
• bricks/dynamic_data/render_tag
• bricks/dynamic_data/render_content
• bricks/frontend/render_data

Se añadió un grupo llamado Kodavio dentro del selector de campos dinámicos.

Algunos ejemplos de tags disponibles son:

• {kodavio_producto_material}
• {kodavio_producto_medidas}
• {kodavio_producto_descripcion_corta}
• {kodavio_producto_beneficio_1_titulo}
• {kodavio_producto_imagen_hero_silueta}
• {kodavio_familia_archive_h1}
• {kodavio_familia_list_title}
• {kodavio_familia_imagen_card}
• {kodavio_familia_contact_phone}

Esto permite crear o modificar elementos en Bricks usando directamente campos del sistema, sin memorizar claves internas ni depender de shortcodes.

Formatos De Tags

Se añadieron algunos formatos útiles.

Para imágenes:

• {kodavio_familia_imagen_card} devuelve una URL.
• {kodavio_familia_imagen_card:id} devuelve el ID del medio.
• {kodavio_familia_imagen_card:img} devuelve una etiqueta <img>.

Para textos:

• {kodavio_familia_archive_h1} permite HTML inline seguro.
• {kodavio_familia_archive_h1:plain} devuelve texto plano.
• {kodavio_producto_formulario_telefono:tel} devuelve una URL tel:.

Esto hace que los tags sean más flexibles según el contexto del campo Bricks donde se usen.

Creación De Productos Con Textos SEO

Se crearon productos con textos específicos, evitando duplicaciones.

Cada producto recibió:

• Título orientado al uso real.
• Descripción corta.
• Introducción.
• Beneficios.
• Datos técnicos.
• Bloque de sustentabilidad.
• Proceso.
• CTA de contacto.
• Relación con su familia.

La redacción se realizó con enfoque SEO, pero evitando repetir bloques genéricos. La intención fue que cada producto respondiera a una necesidad concreta del usuario y tuviera contenido propio.

Creación De Familias Con Textos SEO

También se redactaron archives de familia con contenido diferenciado.

Las familias no repiten literalmente el contenido de los productos. Funcionan como páginas de contexto comercial.

Por ejemplo:

• Una familia explica el tipo de solución y los canales de uso.
• Un producto explica características concretas, formatos, aplicaciones y beneficios.
• La familia agrupa y orienta.
• El producto detalla y convierte.

Esto ayuda a evitar contenido duplicado y mejora la calidad semántica del sitio.

Reestructuración De Familias Y Productos

Durante el proceso se ajustó la organización inicial.

Algunos cambios relevantes fueron:

• Bolsas para consumo interno pasó a Empaque grado alimenticio.
• Bobinas industriales se convirtió en producto dentro de esa familia.
• Se crearon productos específicos para Bolsas canal retail y Bolsas canal distribución.
• Se retiraron productos o enfoques que ya no encajaban en el nuevo mapa.

Esta reestructuración permitió que el contenido reflejara mejor la oferta real del negocio.

Verificación Y Seguridad

Cada cambio técnico se aplicó con un flujo controlado:

• Lectura previa del estado actual.
• Dry-run antes de escritura.
• Lint PHP remoto.
• Escritura real sólo después de validación.
• Backups automáticos de archivos modificados cuando aplica.
• Verificación del frontend.

Se comprobaron productos y archives tras los cambios para confirmar que seguían cargando correctamente y que no aparecían shortcodes literales o errores visibles.

Resultado Final

El resultado es un sistema avanzado de WordPress y Bricks donde:

• El contenido se gestiona desde WordPress.
• Las plantillas Bricks son reutilizables.
• Los campos aparecen en Dynamic Data.
• Los iconos son globales y editables.
• Los productos tienen contenido SEO específico.
• Las familias funcionan como landings dinámicas.
• El editor dispone de una interfaz más clara.
• El sistema está preparado para crecer.

El trabajo no consistió simplemente en crear páginas, sino en desarrollar una arquitectura dinámica sobre WordPress, Bricks y PHP personalizado, pensada para mantenimiento, escalabilidad y edición real por parte del cliente.

Campos Dinámicos, SEO Y Experiencia Editorial En WordPress

Una parte central del trabajo realizado en Plásticos Cantabria fue crear una capa de campos dinámicos que permitiera editar productos y familias desde WordPress sin tener que entrar constantemente en Bricks.

El objetivo fue que el usuario Editor pudiera modificar textos, imágenes, datos técnicos, llamadas a la acción y contenido SEO desde una interfaz clara y ordenada.

Campos Dinámicos Para Productos

Para el CPT producto se definieron campos personalizados que alimentan la plantilla individual de producto.

Entre los principales campos creados se encuentran:

• Descripción corta
• Descripción larga
• Material
• Medidas
• Impresión
• Usos
• Opciones sostenibles
• Teléfono
• Galería
• Productos relacionados
• Textos de formulario
• Imagen hero
• Imagen de características
• Imagen de fondo de sustentabilidad

También se crearon campos para bloques repetitivos, como beneficios, proceso de trabajo e items de sustentabilidad.

Por ejemplo:

• Beneficio 1 título
• Beneficio 1 texto
• Beneficio 1 icono
• Proceso 1 paso
• Proceso 1 título
• Proceso 1 texto

Esto permite que cada producto tenga una ficha completa y diferenciada, sin tener que crear una plantilla distinta para cada caso.

Campos Dinámicos Para Familias

Las familias de producto también recibieron su propia estructura de campos.

Cada familia puede editar:

• Keywords principales
• Meta título SEO
• Meta descripción SEO
• Etiqueta superior del hero
• H1 del archive
• Texto introductorio
• Imagen de fondo del hero
• Imagen visual del producto
• Título del listado
• Texto del listado
• Bloque de sustentabilidad
• Items de sustentabilidad
• Proceso
• Contacto
• Teléfono visible
• Imagen/card de familia

Esto permite que cada archive de familia funcione como una landing dinámica con contenido propio, no sólo como un listado automático.

Integración Con Rank Math SEO

Se añadieron campos específicos relacionados con Rank Math SEO.

En las familias se incorporaron campos como:

• rank_math_title
• rank_math_description
• Keywords principales

Esto permitió definir títulos SEO y metadescripciones de forma controlada, alineadas con la intención de búsqueda de cada familia.

La redacción SEO se trabajó evitando duplicar textos entre productos y familias. Cada producto y cada familia recibieron textos específicos, adaptados a su contexto comercial.

Interfaz Visual Para El Usuario Editor

No se dejaron los campos como una lista técnica sin estructura. Se creó una presentación visual agrupada por bloques dentro del editor de WordPress.

Los campos se organizaron en secciones como:

• SEO y estrategia
• Hero
• Listado de productos
• Sustentabilidad
• Proceso
• Contacto

Esto facilita que el usuario Editor entienda qué parte de la plantilla está editando.

También se añadieron mejoras editoriales como:

• Selectores de imagen.
• Vista previa de imágenes.
• Botones para usar fallback.
• Contadores de caracteres SEO.
• Etiquetas descriptivas.
• Agrupación visual de campos.
• Limpieza de campos antiguos que no tenían uso real.

Imagen/Card De Familia

Se mantuvo el campo Imagen/card familia porque será útil para futuros loops de familias de productos.

Originalmente era un campo numérico donde había que introducir manualmente el ID de un medio. Se mejoró para que funcione de forma parecida a una imagen destacada.

Ahora el editor puede:

• Seleccionar una imagen desde la biblioteca de medios.
• Ver una preview.
• Quitar la imagen.
• Ver la miniatura en la tabla de familias.

Este campo queda preparado para usarse en futuros listings, cards o bloques de navegación por familias.

Limpieza De Campos Obsoletos

Durante el proceso se detectaron campos antiguos creados en fases iniciales del modelo de contenido.

Algunos no estaban conectados a la plantilla actual y podían confundir al editor. En lugar de eliminarlos de la base de datos, se ocultaron de la interfaz.

Se ocultaron campos como:

• Título hero familia
• Descripción corta antigua
• Descripción larga SEO antigua
• CTA título
• CTA texto
• Orden destacado

También se resolvió una duplicidad relacionada con la imagen hero de familia, priorizando el campo más moderno, que incluye selector visual y preview.

Fallbacks Y Seguridad

Se implementaron fallbacks para evitar que una página quede rota si un campo está vacío.

Por ejemplo:

• Si una imagen no está definida, se mantiene una imagen por defecto.
• Si un texto dinámico está vacío, se puede usar un fallback.
• Si un campo de icono no tiene valor, se usa una clave por defecto.
• Si un dato de imagen no existe, no se fuerza una URL inválida.

Además, los datos se sanitizan según su tipo:

• Texto normal.
• HTML inline permitido.
• URLs.
• IDs de medios.
• SVGs.

Esto permite ofrecer flexibilidad editorial sin comprometer la seguridad del sitio.

Resultado Editorial

El resultado es una interfaz más clara para el usuario Editor.

Ahora los productos y familias pueden editarse desde WordPress con una lógica más parecida a un sistema de contenido profesional:

• El contenido está separado del diseño.
• Las plantillas son reutilizables.
• El SEO está integrado.
• Las imágenes son gestionables visualmente.
• Los campos que no se usan no confunden al usuario.
• El sistema queda preparado para crecer.

Quiero contaros la experiencia de haber creado una web catálogo de productos con CPT, Taxonomías y campos dinámicos.
Como la IA es tan lista y lo explica mejor que yo, le he pedido que os cuente qué es lo que ha hecho. Inicialmente yo diseñé y creé las plantillas de Bricks de Producto y de Familia de producto, pero usando titulares, textos, iconos y fotografías simulados. No campos dinámicos... Ha sido un trabajo muy interesante.
Como es muy largo lo divido en 3 entradas. Va la primera:

De Una Web Estática A Un Sistema Dinámico En WordPress Y Bricks

El trabajo realizado en Plásticos Cantabria partió de una necesidad habitual en proyectos WordPress avanzados: convertir una estructura visual creada en Bricks en un sistema dinámico, mantenible y preparado para crecer.

El objetivo no era únicamente crear páginas nuevas, sino construir una arquitectura de contenido donde los productos, las familias, los textos SEO, las imágenes y determinados elementos visuales pudieran gestionarse desde WordPress sin tener que duplicar plantillas o editar manualmente cada página en Bricks.

Análisis De Las Plantillas Bricks

El primer paso fue analizar las plantillas existentes en Bricks Builder.

Se revisaron las estructuras internas de las plantillas, los nodos, los IDs de elementos, los textos fijos, los bloques visuales, las imágenes y los puntos donde tenía sentido sustituir contenido estático por contenido dinámico.

Este análisis permitió distinguir entre dos capas:

• La capa visual, propiedad de Bricks.
• La capa de contenido, que debía pasar a WordPress mediante campos dinámicos.

La decisión técnica fue conservar la estructura visual de las plantillas y alimentar sus contenidos desde un modelo propio de datos. Esto evitó reconstruir el diseño desde cero y permitió mantener una única plantilla para múltiples productos y categorías.

Creación Del CPT Producto

Se creó un Custom Post Type llamado producto.

Este CPT permite gestionar cada solución comercial de Plásticos Cantabria como una entidad independiente dentro de WordPress.

Algunos ejemplos de productos creados son:

• Sacos industriales de plástico
• Bolsas ecommerce
• Bolsas tipo camiseta
• Bolsas para panadería
• Bolsas para congelación
• Bobinas industriales
• Bolsas canal retail
• Bolsas canal distribución

El CPT producto tiene su propio archive, sus URLs individuales y su relación con las familias de producto.

Esto permite que cada producto tenga contenido propio, campos personalizados, imágenes, textos SEO y estructura dinámica sin depender de una página estática creada a mano.

Creación De La Taxonomía Familia Producto

Junto al CPT se creó la taxonomía jerárquica familia_producto.

Esta taxonomía organiza los productos en grupos comerciales más amplios, como:

• Bolsas comerciales
• Bolsas de papel
• Empaque grado alimenticio
• Bolsas para basura
• Canal mayoreo

La taxonomía no se usó sólo como una clasificación interna. Se convirtió en una parte importante del sistema dinámico, ya que cada familia dispone de su propio archive con textos, imágenes, SEO, bloques de contenido y listado de productos relacionados.

De este modo, las categorías dejan de ser simples páginas de listado y pasan a funcionar como landings dinámicas.

Relación Entre Productos Y Familias

Cada producto se asigna a una familia mediante la taxonomía familia_producto.

Esta relación permite que:

• Los productos aparezcan automáticamente en el archive de su familia.
• La plantilla de producto pueda mostrar la familia a la que pertenece.
• Las familias puedan tener contenido editorial propio sin duplicar información del producto.
• La navegación del sitio sea más coherente.

También se revisó la estructura inicial de familias y productos para ajustarla mejor al mapa comercial del sitio. Por ejemplo, Bobinas industriales pasó a funcionar como producto dentro de Empaque grado alimenticio, en lugar de mantenerse como familia independiente.

Uso De MU Plugins

La implementación técnica se realizó principalmente mediante MU plugins.

Los MU plugins son plugins obligatorios de WordPress que cargan automáticamente. En este proyecto se utilizaron para registrar el CPT, la taxonomía, los campos, las interfaces de edición, los helpers de frontend y las integraciones con Bricks.

Esta decisión tiene varias ventajas:

• El modelo de contenido no depende de que alguien active un plugin manualmente.
• El código queda separado por responsabilidades.
• Es más fácil hacer backups puntuales.
• El comportamiento es estable.
• Se evita duplicar la lógica entre distintos plugins visuales.

También tiene una desventaja: no es tan accesible para un usuario no técnico como una interfaz visual tipo JetEngine. Aun así, para esta fase del proyecto se priorizó estabilidad, control y precisión técnica.

Decisión Frente A JetEngine O CodeBox2

El sitio tiene JetEngine y WPCodeBox2 instalados, pero el modelo principal no se trasladó a estas herramientas.

La razón es que el CPT, la taxonomía y los campos ya estaban funcionando de forma estable desde MU plugins. Migrarlos a JetEngine en este momento habría implicado mapear campos, revisar compatibilidad, adaptar plantillas y evitar duplicidades.

JetEngine sigue siendo útil para otras tareas, especialmente listings, filtros o relaciones avanzadas. Pero en este caso el núcleo del modelo se mantuvo en código para reducir dependencias y asegurar que la estructura principal del sitio no se vea afectada por cambios en plugins secundarios.

Resultado De La Arquitectura

El resultado es una arquitectura WordPress más sólida:

• Un CPT específico para productos.
• Una taxonomía específica para familias.
• Plantillas Bricks reutilizables.
• Campos dinámicos conectados al contenido.
• Archives de familia con contenido editorial propio.
• Estructura preparada para SEO.
• Base técnica extensible para futuras mejoras.

Este enfoque convierte el sitio en un sistema dinámico, no en una colección de páginas sueltas.

Seguimos mejorando la edición en Bricks, Elementor y Gutenberg, y preparando algunas novedades. Pero antes de cerrarla, queremos construirla con vuestra ayuda.

Si estáis en la beta y os topáis con algo —un bug, un comportamiento raro o una mejora que os facilitaría el día a día—, contádnoslo 👇

- ¿Qué fallo os ha dado guerra últimamente?

- ¿Qué mejora os ahorraría tiempo de verdad?

No lo meteremos todo —priorizamos lo que sirve a nivel general, no caso a caso—, pero leemos cada respuesta y nos ayuda a decidir qué entra en la próxima versión.

Esta versión cambia cómo trabaja el agente sobre páginas que ya existen. Antes, para un cambio puntual —añadir una sección, mover un elemento, retocar un botón— el camino fácil acababa siendo reconstruir la página entera. La 0.1.6 convierte la edición en sitio en algo de primera clase en Bricks, Elementor y Gutenberg, suma una librería de patrones que se adapta al diseño de cada sitio y estrena exportación estática.

Editar sin reconstruir

El agente edita cualquier página existente de forma quirúrgica —añadir una sección, crear, mover o borrar un elemento, o cambiar uno solo— sin rehacer el resto. Funciona en Bricks, Elementor y Gutenberg, y el enrutado distingue "editar lo que hay" de "crear de cero", así que un cambio pequeño deja de costar una reconstrucción. Tras cada cambio, la recomendación es releer y confirmar que solo se tocó lo pedido.

Patrones de layout que se adaptan al sitio

Nueva librería de patrones (hero, CTA, características, precios, FAQ, testimonios, dos columnas). Un patrón se define una vez y, al aplicarlo, su color, espaciado y contenedor se resuelven al sistema de diseño activo del sitio —Bricks variables, ACSS, Core Framework o WindPress/Tailwind— o caen a valores nativos sensatos. Un mismo patrón, on-brand en cualquier framework, sin pegar JSON a mano. Disponibles en Bricks y Elementor v4.

Elementor v4

La creación nueva usa ya elementos atómicos v4 (e-flexbox + e-heading/e-paragraph/e-button). La edición sigue soportando v3 clásico y el modo híbrido, para poder tocar lo que cada sitio ya tiene.

Avisos de "fallos silenciosos"

Muchos errores de estilo en los builders no dan error: simplemente no pintan nada. Kodavio ahora los detecta antes de escribir —tipografía mal escrita, sombras o gradientes mal anidados, valores en formato incorrecto, breakpoints inexistentes— tanto en Bricks como en Elementor.

Exportación estática (beta)

Nueva habilidad kodavio/static-export: renderiza una página publicada, extrae el CSS y los recursos que necesita, reescribe las rutas y entrega un bundle portable (HTML + assets) listo para subir a un host estático. Por defecto en dry-run.

Integridad de datos

• Gutenberg: el contenido con barras invertidas o JSON ya no se corrompe al guardar.
• Bricks: añadir o duplicar elementos ya no colisiona identificadores; y mover un elemento respeta de verdad su nueva posición.

Y además, en este ciclo

WooCommerce para agentes (pedidos, stock, informe de ventas), diff visual en conversiones, y migración selectiva de contenido y formularios entre sitios (Fluent Forms, CF7, WPForms).

Para betatesters

Pídele un cambio y lo hace donde está, sin rehacer la página. Patrones que respetan tu sistema de diseño. Menos «se ve raro y no sé por qué»: el agente avisa de las formas que fallan en silencio. Y más confianza en tus datos. Como siempre, todo con dry-run, confirmación y verificación posterior.

Dos utilidades de Tailwind v4 que arreglan un detalle que se nota mucho y casi nadie toca:

• text-balance en titulares (<h1>, <h2>): reparte las palabras entre líneas para que no quede una sola colgando. Adiós a la viuda del titular.
• text-pretty en párrafos largos: evita esas líneas finales con una palabra suelta.

Una clase, cero CSS custom, y el texto respira mucho mejor en todos los anchos.

¿Qué otro detalle pequeño de tipografía marca la diferencia en tus diseños? 👇

Esta vez le he pedido a Kodavio que busque los archivos de medios que no se están usando en la web.
Resultado inicial:
Imágenes auditadas: 2.398

• URLs públicas del sitemap revisadas: 164
• Imágenes detectadas como usadas: 846
• Archivos candidatos a no usados: 602

No podía acceder a la base de datos para poder hacer una segunda confirmación. Creó un endpoint temporal que puse en CodeBox. Analizó nuevamente y confirmó los resultados.
Después creo una carpeta para mover los seleccionados y preparé otro endpoint para poder mover esos archivos y ponerlos en cuarentena antes de borralos definitivamente. Primero hizo una prueba con 20 imágenes. Lo aprobé, y a continuación movió el resto (593)
Totales de los restantes:
Candidatos de alta confianza: 594

• Adjuntos movidos a cuarentena: 593
• Archivos físicos movidos, incluyendo miniaturas: 3.947
• Errores de movimiento: 0
• Archivos faltantes durante el movimiento: 0

Hasta el momento no he notado que falte ninguna imagen. Sigo buscando...
Si funciona sin ningún error ha sido un ahorro de tiempo y de riesgo tremendo.