umairmsm/wp-build

Stage 3: Build

Ziel: Die Seite läuft lokal. Echte Inhalte werden durch Kernfunktionen gerendert. Anfragen werden gespeichert, dann weitergeleitet, dann bereinigt. Die Strukturtests sind grün.

Zuerst lesen: das AGENTS.md des Projekts, dann references/architecture.md.

Schritte

1. Lokale Seite. Folge dem README.md des Projekts, Abschnitt „Erster Start“. Dann prüfen: ddev wp eval 'echo wp_get_environment_type();' muss local ausgeben. Falls nicht, siehe references/local-env.md. Solange es nicht local ausgibt, glaubt die Seite, sie sei in Produktion: Sie kann indexiert werden und echte Kunden per E-Mail erreichen.
2. Beispiel-Inhaltstyp umbenennen. Dies tun, bevor Inhalte existieren. <prefix>_offer wird zum geschäftsspezifischen Begriff (Tour, Service, Kurs): der Post-Typ, der Rewrite-Slug und die Labels in modules/content.php, sowie die Funktionsnamen (_get_offers, _render_offer_card), die Datei parts/offer-card.php und die Tests. Post-Typ-Namen haben ein 20-Zeichen-Limit.
3. Inhalt modellieren. Finde jedes Feld, das die Aufgabenstellung benötigt. Registriere jedes als Post-Meta mit einem Sanitize-Callback und einem Auth-Callback. Preise sind Zahlen in Meta. 0 bedeutet „auf Anfrage“, niemals „kostenlos“. Wenn Redakteure umfangreichere Feldbildschirme benötigen, füge ACF (kostenlos) hinzu, aber lese Werte nur über Kernfunktionen aus.
4. Datendateien → Generator (wenn der Eigentümer viele Elemente bereitstellt):
   • eine Markdown- oder JSON-Datei pro Element in docs/data/<type>/ ablegen;
   • ein idempotentes WP-CLI-Skript schreiben, das Beiträge aus diesen Dateien erstellt oder aktualisiert;
   • mit --dry-run versehen;
   • ausführen mit ddev wp eval-file - < scripts/<name>.php. Die Dateien sind die überprüfbare Wahrheit; die Datenbank ist die Kopie.
5. Vorlagen rufen eine Kernfunktion pro Abschnitt auf.
   • Layout lebt im Theme: Vorlagen, parts/, Skin-Überschreibungen.
   • Daten, Abfragen, Preise, Richtlinientexte und Formulare kommen aus dem Kern.
   • Jeden Aufruf mit function_exists() schützen, damit eine Vorlage nie abstürzt, wenn das Plugin fehlt.
6. Anfragen. Halte die Pipeline in modules/enquiry.php (references/forms-and-leads.md).
   • Felder an drei Stellen gleichzeitig hinzufügen: im Formular, im Handler und im Details-Bereich.
   • Posteingang und Absender in wp-config.php-Konstanten setzen, niemals im Code.
7. Richtlinientext (AGB, Anzahlungen, Stornierung): im Kern als eine Funktion ablegen (z. B. <prefix>_policy( 'cancellation' )). Vorlagen geben diese Funktion aus, und ein Test schlägt fehl, wenn eine Vorlage einen Richtlinientext fest codiert.
8. Neues Modul? Eine Datei in modules/ hinzufügen, eine require_once-Zeile im Bootstrap und tests/structure/core.spec.ts im selben Commit aktualisieren.
9. Prüfen und committen.
   • npm run test:structure und npm run lint:php ausführen (0 Fehler).
   • Den wp-rules-reviewer-Agenten bitten, den Diff zu überprüfen.
   • Committen (Conventional Commits).

Tor (in SITE_STATUS.md abhaken)

• wp_get_environment_type() = local
• Kern-Plugin und Child-Theme aktiv; Skin lädt
• Echte Inhalte werden durch Kernfunktionen gerendert; keine fest codierten Karten, Preise oder Slugs
• Anfrage: gespeichert → per E-Mail gesendet → erneuter Versuch → bereinigt; Ende-zu-Ende in Mailpit getestet
• Strukturtests grün; PHPCS 0 Fehler

Niemals

• Geschäftslogik, WP_Query, Preise, pll_*-Aufrufe oder Richtlinientext im Theme.
• Rohe $_POST oder $_GET ohne wp_unslash + eine Sanitize-Funktion; Ausgabe ohne esc_*.
• Drittanbieter-API-Schlüssel oder Endpunkte in HTML oder JS. Vom Server aus weiterleiten.
• Plugin-Module mit rohem wp option update umschalten. Die eigene UI oder CLI des Plugins verwenden, dann jede betroffene Seite erneut prüfen.
• Unpräfixierte Funktionen, Optionen, Hooks, Meta-Schlüssel oder Nonces.