Desarrollo dinámico en web con Kodavio (1/3)

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.