umairmsm/wp-build

Etapa 3: Build (Construcción)

Objetivo: el sitio funciona localmente. Los elementos reales se renderizan mediante funciones del núcleo. Las consultas se guardan, luego se reenvían, luego se purgan. Las pruebas de estructura están en verde.

Lee primero: el AGENTS.md del proyecto, luego references/architecture.md.

Pasos

1. Sitio local. Sigue la sección "Primera ejecución" del README.md del proyecto. Luego verifica: ddev wp eval 'echo wp_get_environment_type();' debe imprimir local. Si no es así, consulta references/local-env.md. Hasta que imprima local, el sitio piensa que está en producción: puede ser indexado y puede enviar correos a clientes reales.
2. Renombra el tipo de contenido de ejemplo. Hazlo antes de que exista contenido. <prefix>_offer se convierte en la palabra del negocio (tour, servicio, curso): el tipo de post, el slug de reescritura y las etiquetas en modules/content.php, además de los nombres de funciones (_get_offers, _render_offer_card), el archivo parts/offer-card.php y las pruebas. Los nombres de tipos de post tienen un límite de 20 caracteres.
3. Modela el contenido. Encuentra todos los campos que necesita el brief. Registra cada uno como metadato de post con un callback de saneamiento y un callback de autorización. Los precios son números en metadatos. 0 significa "bajo consulta", nunca "gratis". Si los editores necesitan pantallas de campos más enriquecidas, añade ACF (gratuito) encima, pero lee los valores solo a través de funciones del núcleo.
4. Archivos de datos → generador (cuando el propietario proporciona muchos elementos):
   • mantén un archivo Markdown o JSON por elemento en docs/data/<type>/;
   • escribe un script WP-CLI idempotente que cree o actualice publicaciones a partir de esos archivos;
   • asígnale un --dry-run;
   • ejecútalo con ddev wp eval-file - < scripts/<name>.php. Los archivos son la verdad revisable; la BD es la copia.
5. Las plantillas llaman a una función del núcleo por sección.
   • El layout vive en el tema: plantillas, parts/, anulaciones de skin.
   • Los datos, consultas, precios, frases de política y formularios vienen del núcleo.
   • Protege cada llamada con function_exists(), para que una plantilla nunca falle si falta el plugin.
6. Consultas. Mantén el pipeline en modules/enquiry.php (references/forms-and-leads.md).
   • Añade campos en tres lugares a la vez: el formulario, el manejador y la caja de detalles.
   • Configura la bandeja de entrada y el remitente en constantes de wp-config.php, nunca en código.
7. Texto de políticas (términos, depósitos, cancelación): colócalo en el núcleo como una función (por ejemplo <prefix>_policy( 'cancellation' )). Las plantillas imprimen esa función, y una prueba falla si una plantilla hardcodea una frase de política.
8. ¿Nuevo módulo? Añade un archivo en modules/, una línea require_once en el bootstrap, y actualiza tests/structure/core.spec.ts en el mismo commit.
9. Verifica y haz commit.
   • Ejecuta npm run test:structure y npm run lint:php (0 errores).
   • Pídele al agente wp-rules-reviewer que revise el diff.
   • Haz commit (Conventional Commits).

Puerta (marca en SITE_STATUS.md)

• wp_get_environment_type() = local
• Plugin central y tema hijo activos; skin cargado
• Elementos reales renderizados mediante funciones del núcleo; sin cards, precios o slugs hardcodeados
• Consulta: guardada → enviada por correo → reintento → purga; probada de extremo a extremo en Mailpit
• Pruebas de estructura en verde; PHPCS 0 errores

Nunca

• Lógica de negocio, WP_Query, precios, llamadas pll_* o texto de política en el tema.
• $_POST o $_GET sin wp_unslash + una función de saneamiento; salida sin esc_*.
• Claves de API o endpoints de terceros en HTML o JS. Reenvía desde el servidor.
• Activar módulos de plugins con wp option update sin procesar. Usa la UI o CLI del propio plugin, luego vuelve a revisar cada página que afecte.
• Funciones, opciones, hooks, claves de metadatos o nonces sin prefijo.