emdash-cms/emdash

Portiere ein WordPress-Theme zu EmDash

Erstelle die relevanten Layouts und Interaktionen des Themes als Astro-Site, die mit EmDash betrieben wird. Bewahre die vom Benutzer gewünschte visuelle Treue und den Funktionsumfang; nimm nicht an, dass jede WordPress-Vorlage oder Demo-Funktion zum Port gehören.

Lade building-emdash-site für aktuelle EmDash-Schema-, Query-, Rendering-, Cache- und Seed-Muster. Wenn eine Live-Referenzseite verfügbar ist, verwende die agent-browser-CLI für den gerenderten Vergleich; führe agent-browser skills get core --full für die Befehlsreferenz aus.

Wähle die Belege

Verwende die besten verfügbaren Quellen in dieser Reihenfolge:

1. Theme-Quellcode und theme.json, Stylesheets, Vorlagen und functions.php;
2. eine Live-Demo auf repräsentativen Desktop- und Mobilansichtsfenstern;
3. Screenshots oder Designdateien, die vom Benutzer bereitgestellt wurden;
4. explizite Designentscheidungen, wenn die Quelle mehrdeutig ist.

Gehe nicht davon aus, dass Demo-Inhalte oder Bilder der Lizenz des Theme-Codes unterliegen. Verwende ein Asset nur dann wieder, wenn seine Lizenz oder die Rechte des Benutzers dies erlauben; verwende andernfalls einen klar lizenzierten Ersatz mit ähnlichen Abmessungen und visuellem Gewicht.

Plane den Port

Erfasse nur die Seitentypen, Komponenten, responsiven Zustände und Interaktionen, die für die angeforderte Site benötigt werden. Ordne die WordPress-Verantwortlichkeiten zu, bevor du implementierst:

• PHP-Vorlagen werden zu Astro-Routen, Layouts und Komponenten.
• Benutzerdefinierte Beitragstypen, Metadaten und Taxonomien werden zu EmDash-Kollektionen, Feldern und Taxonomien.
• Theme Customizer-Werte werden zu Site-Einstellungen oder expliziter Projektkonfiguration.
• Menü-Positionen werden zu benannten EmDash-Menüs, die von Vorlagen abgefragt werden.
• Sidebars und Widgets werden zu Widget-Bereichen oder gewöhnlichen Astro-Komponenten.
• Shortcodes und plugin-eigenes Verhalten können eine separate Plugin-Migration erfordern.

Lies WordPress Theme Konzept-Mapping beim Übersetzen der Vorlagenhierarchie, functions.php-Registrierungen, Vorlagen-Tags, Hooks, Widgets oder wiederverwendbaren Blöcke.

Dynamische EmDash-Inhaltsrouten müssen serverseitig gerendert bleiben. Verwende die EmDash Image-Komponente für EmDash-Medienfelder; gewöhnliche Theme-Assets können die Astro-Asset-Verwaltung nutzen.

Arbeite in abgegrenzten Phasen

Lese eine Phasendatei nur dann, wenn diese Phase zutrifft:

• Erkennung und Referenzerfassung
• Design-Extraktion
• Vorlagenkonvertierung
• Dynamische EmDash-Funktionen
• Schema und Seed-Daten
• Gerenderte Verifizierung

Wenn du ein eigenständiges Theme-Projekt erstellst, beginne mit der aktuellen Site-Vorlage des Repositorys oder dem vorhandenen Projekt des Benutzers. Bestätige das Ziel, bevor du schreibst, und ersetze keine vorhandene Site-Struktur ohne explizite Anweisung.

Überprüfe das Ergebnis

Erstelle die Site und teste jede Seite und Interaktion des Umfangs. Vergleiche übereinstimmende Ansichtsfenster mit der Referenz, einschließlich responsiver Navigation, Inhalten mit langen und fehlenden Werten, RTL, wenn Admin- oder Theme-Verhalten von der Richtung abhängt, sowie relevante leere oder Fehlerzustände.

Erstelle Vorher-Nachher- oder Referenz-Ergebnis-Screenshots, wenn visuelle Treue Teil der Abnahme ist. Berichte bewusste Abweichungen, fehlende Quellenbelege, nicht unterstütztes WordPress-Verhalten und Asset-Ersetzungen.

Lizenzierung und Namensnennung

Überprüfe die tatsächliche Lizenz und Hinweise des Quellthemes. Bewahre erforderliche Urheberrechts- und Namensnennungsangaben, füge den anwendbaren Lizenztext für wiederverwendeten Code ein und identifiziere Drittanbieter-Assets separat. Bezeichne einen Port nicht als GPL-2.0-or-later, nur weil die Quelle ein WordPress-Theme ist.