umairmsm/wp-build

Étape 3 : Construction

Objectif : le site tourne en local. Les éléments réels s'affichent via les fonctions du noyau. Les enquêtes sont sauvegardées, puis transmises, puis purgées. Les tests de structure sont au vert.

Lire d'abord : le fichier AGENTS.md du projet, puis references/architecture.md.

Étapes

1. Site local. Suivre la section « Premier lancement » du README.md du projet. Vérifier ensuite : ddev wp eval 'echo wp_get_environment_type();' doit afficher local. Si ce n'est pas le cas, consulter references/local-env.md. Tant que ce n'est pas local, le site se considère en production : il peut être indexé et envoyer des emails à de vrais clients.
2. Renommer le type de contenu exemple. À faire avant que le contenu existe. <prefix>_offer devient le mot métier (tour, service, cours) : le type de publication, l'identifiant de réécriture et les libellés dans modules/content.php, ainsi que les noms de fonctions (_get_offers, _render_offer_card), le fichier parts/offer-card.php et les tests. Les noms de types de publication ont une limite de 20 caractères.
3. Modéliser le contenu. Trouver chaque champ nécessaire au brief. Enregistrer chacun comme meta de publication avec une fonction de nettoyage et une fonction d'autorisation. Les prix sont des nombres dans les meta. 0 signifie « sur demande », jamais « gratuit ». Si les éditeurs ont besoin d'écrans de champs plus riches, ajouter ACF (gratuit) par-dessus, mais lire les valeurs uniquement via les fonctions du noyau.
4. Fichiers de données → générateur (lorsque le propriétaire fournit de nombreux éléments) :
   • conserver un fichier Markdown ou JSON par élément dans docs/data/<type>/ ;
   • écrire un script WP-CLI idempotent qui crée ou met à jour les publications à partir de ces fichiers ;
   • lui ajouter une option --dry-run ;
   • l'exécuter avec ddev wp eval-file - < scripts/<nom>.php. Les fichiers sont la vérité révisable ; la base de données est la copie.
5. Les templates appellent une fonction du noyau par section.
   • La mise en page vit dans le thème : templates, parts/, surcharges de skin.
   • Les données, requêtes, prix, phrases de politique et formulaires proviennent du noyau.
   • Protéger chaque appel avec function_exists(), afin qu'un template ne provoque jamais d'erreur fatale si le plugin est manquant.
6. Enquêtes. Conserver le pipeline dans modules/enquiry.php (references/forms-and-leads.md).
   • Ajouter les champs à trois endroits simultanément : le formulaire, le gestionnaire et la boîte de détails.
   • Définir la boîte de réception et l'expéditeur dans les constantes de wp-config.php, jamais dans le code.
7. Texte de politique (conditions générales, acomptes, annulation) : le placer dans le noyau sous forme d'une fonction (par exemple <prefix>_policy( 'cancellation' )). Les templates appellent cette fonction, et un test échoue si un template code en dur une phrase de politique.
8. Nouveau module ? Ajouter un fichier dans modules/, une ligne require_once dans le bootstrap, et mettre à jour tests/structure/core.spec.ts dans le même commit.
9. Vérifier et valider.
   • Exécuter npm run test:structure et npm run lint:php (0 erreurs).
   • Demander à l'agent wp-rules-reviewer de passer en revue le diff.
   • Valider (Conventional Commits).

Porte (cocher dans SITE_STATUS.md)

• wp_get_environment_type() = local
• Plugin noyau et thème enfant actifs ; le skin se charge
• Les éléments réels s'affichent via les fonctions du noyau ; pas de cartes, prix ou identifiants codés en dur
• Enquête : sauvegardée → envoyée par email → relancée → purgée ; testée de bout en bout dans Mailpit
• Tests de structure au vert ; PHPCS 0 erreurs

Jamais

• Logique métier, WP_Query, prix, appels pll_* ou texte de politique dans le thème.
• $_POST ou $_GET bruts sans wp_unslash + une fonction de nettoyage ; sortie sans esc_*.
• Clés API ou points de terminaison tiers dans le HTML ou le JS. Transmettre depuis le serveur.
• Activer/désactiver des modules de plugin avec wp option update brut. Utiliser l'interface utilisateur ou la CLI du plugin, puis revérifier chaque page affectée.
• Fonctions, options, hooks, clés de meta ou nonces sans préfixe.