Construir con Codex un plugin de WordPress para editar contenido sin tocar código

1. El problema: editar una web no debería exigir entender su frontend

Cuando una aplicación usa WordPress como gestor de contenidos y Astro como frontend, la separación técnica aporta rendimiento y flexibilidad, pero también introduce una fricción: la persona responsable de la web necesita cambiar textos e imágenes sin conocer componentes, rutas, despliegues ni repositorios. El requisito no es simplemente “conectar WordPress con Astro”. Es definir una interfaz editorial comprensible, un modelo de datos estable y un canal seguro para que el frontend consuma esos cambios.

La propuesta concreta es un plugin de WordPress que registre grupos de campos mediante Advanced Custom Fields (ACF), los muestre en una pantalla editorial simplificada y exponga únicamente los datos necesarios para el frontend. Codex puede actuar como agente de desarrollo para diseñar, implementar, probar y documentar este sistema, pero no forma parte del producto final ni sustituye la revisión de una persona.

2. Propuesta de producto y flujo de uso

El producto sería un plugin orientado a sitios con páginas de contenido estructurado: portada, página de servicios, contacto o bloques promocionales. Su usuario principal es una persona no técnica que necesita editar contenido desde el panel de WordPress y comprobar qué se publicará.

El flujo debe ser corto y explícito:

• La persona entra en una pantalla de edición con campos como título, subtítulo, llamada a la acción e imagen principal.
• El formulario valida campos obligatorios, longitud de textos, formato de URL y tipo o tamaño de imagen.
• WordPress guarda los valores como metadatos ACF asociados a una página o a un tipo de contenido personalizado.
• El plugin expone una respuesta JSON estable para el frontend, sin obligar a Astro a conocer la estructura interna de WordPress.
• La persona puede ver un estado de guardado, errores de validación y, si se implementa, una previsualización antes de publicar.

La interfaz debería ocultar opciones irrelevantes del administrador y usar etiquetas editoriales, ayuda contextual y previsualizaciones de imágenes. En móvil, los campos deben seguir siendo utilizables, aunque la edición prolongada de contenido puede requerir una experiencia de escritorio.

3. Arquitectura de la solución

En WordPress, el plugin puede registrar un tipo de contenido, grupos de campos ACF y rutas REST propias. Registrar los campos desde código o mediante archivos JSON versionados facilita reproducir la instalación y revisar cambios en Git. ACF seguiría siendo una dependencia explícita; el plugin debe comprobar si está activa y mostrar un error accionable si no lo está, en lugar de fallar silenciosamente.

Una ruta como /wp-json/site-content/v1/home devolvería un esquema reducido: textos, URLs, identificadores de medios y tamaños disponibles. El servidor debe aplicar permisos, escapar o sanear valores donde corresponda y evitar exponer metadatos administrativos. Para contenido público, la lectura puede ser anónima. Para borradores o previsualizaciones, se necesita autenticación de WordPress, un mecanismo de vista previa y controles de caducidad.

Astro consumiría esa API durante la generación estática o bajo demanda. Si el sitio requiere cambios casi inmediatos, un webhook de WordPress puede invalidar la caché o iniciar un despliegue. No hace falta convertir WordPress en una API genérica: un contrato pequeño y documentado reduce el acoplamiento. El almacenamiento principal seguiría siendo la base de datos de WordPress y la biblioteca multimedia; el frontend podría usar una caché CDN.

4. Qué aporta Codex y qué no debe delegarse

Codex puede trabajar como agente sobre un repositorio con instrucciones precisas: inspeccionar la estructura existente, crear el esqueleto del plugin, registrar hooks, implementar rutas REST, preparar pruebas y actualizar la documentación. Una instrucción útil debe fijar el alcance: “crea un plugin que dependa de ACF, registre el grupo de campos de la portada, exponga una ruta pública de solo lectura, valide respuestas y añada pruebas para dependencia ausente, campos vacíos y medios eliminados”. También conviene pedir cambios pequeños, revisar el diff y ejecutar las pruebas después de cada fase.

La IA es adecuada para generar código repetitivo, transformar requisitos en esquemas, proponer casos límite y ayudar a diagnosticar errores. No debería decidir por sí sola qué contenidos son públicos, qué permisos tienen los editores, qué datos personales se almacenan o cuándo una migración de campos es segura. Esas decisiones pertenecen al responsable del producto y deben quedar documentadas.

No se necesita un modelo generativo dentro del plugin. Las reglas deterministas de WordPress y ACF resuelven la edición, validación y entrega de datos. La IA puede asistir durante el desarrollo o, como funcionalidad futura separada, sugerir textos; pero mezclar generación de contenido con un editor básico ampliaría el riesgo y el alcance sin resolver el problema principal.

5. Fases de implementación y pruebas

La construcción con Codex debería dividirse en entregas verificables:

• Descubrimiento: definir páginas, campos, roles, estados de publicación, contrato JSON y criterio de aceptación.
• Plugin mínimo: activar la dependencia, registrar campos, añadir saneado y mostrar avisos administrativos.
• API: crear rutas, permisos, respuestas estructuradas y errores HTTP consistentes.
• Frontend: consumir el contrato desde Astro, representar carga, ausencia de contenido y fallo de API.
• Entrega: preparar documentación, instalación limpia, configuración de URL, caché y procedimiento de rollback.

Las pruebas deben cubrir activación y desactivación del plugin, ausencia de ACF, usuarios sin permisos, validación de campos, imágenes borradas, respuestas incompletas, errores 404 y fallos de red. En el frontend, una respuesta vacía no debe producir una página rota ni mostrar valores de prueba. La revisión humana debe comprobar el panel con la tarea real, leer el texto de cada etiqueta, validar accesibilidad básica y contrastar el resultado visual con el diseño.

6. Limitaciones, riesgos y siguiente paso

ACF introduce dependencia y posibles diferencias entre versiones o licencias. La API REST añade una superficie de seguridad que requiere limitar rutas, aplicar permisos y revisar la exposición de medios. La generación estática puede dejar contenido desactualizado si no existe invalidación de caché. También hay una tensión entre flexibilidad editorial y estabilidad del frontend: permitir demasiados campos libres puede convertir el contrato en una colección difícil de mantener.

La primera versión viable hoy es un plugin pequeño, con campos estructurados, API de solo lectura y un frontend Astro que gestione estados de error. Codex puede acelerar cada fase, pero el criterio de aceptación debe venir del uso editorial, no del volumen de código generado. El siguiente paso es elegir una única página real, definir su esquema de campos y pedir a Codex que produzca una primera implementación acompañada de pruebas y un documento de decisiones. ¿Cuánta libertad debería ofrecer el editor antes de que una solución más determinista proteja mejor la estabilidad del frontend?

Dirección visual

Imagen editorial horizontal de una mesa de trabajo con una guía impresa de campos de contenido estructurado, tarjetas con etiquetas de título, imagen y llamada a la acción, fotografías preparadas para la biblioteca multimedia y una vista parcial de una página web publicada que refleja esos cambios. El sujeto central es el flujo material entre contenido editable, medios y resultado frontend; no aparecen logotipos, texto legible ni interfaces futuristas. La composición debe dejar claro que una persona no técnica organiza entradas en WordPress y que esas entradas terminan formando una página web coherente.