Ein WordPress-Plugin nach EmDash portieren
Bewahre das für Benutzer sichtbare Verhalten und das Datenmodell des Plugins, ohne PHP zeilenweise zu übersetzen. WordPress und EmDash teilen die Verantwortlichkeiten anders auf, daher entscheide zunächst, ob jedes Merkmal in Site-Schema, Astro-Code, ein sandboxiertes Plugin oder ein vertrauenswürdiges natives Plugin gehört.
Lade creating-plugins, bevor du Plugin-Code implementierst. Lade building-emdash-site, wenn der Port Collections, Seeds, Queries oder Frontend-Vorlagen ändert. Diese Skills definieren die aktuellen APIs; dieser Skill behandelt Migrationsentscheidungen.
Die Quelle verstehen
Untersuche den Plugin-Quellcode, das Installationsverhalten, Datenbankänderungen, Hooks, REST-Endpunkte, geplante Aufgaben, Admin-Bildschirme, Shortcodes oder Blöcke, Frontend-Ausgabe, Berechtigungen und externe Dienste. Identifiziere das Verhalten, auf das sich Benutzer verlassen, getrennt von der WordPress-spezifischen Implementierung.
Dokumentiere:
- erforderliche Inhalts- und Konfigurationsdaten;
- Aktionen, die Daten verändern oder veröffentlichen;
- Autorisierungs- und Vertrauensgrenzen;
- Hintergrund- oder Wiederholungsverhalten;
- Frontend- und Administratorinteraktionen;
- Import-, Migrations- und Rollback-Anforderungen;
- Lizenzverpflichtungen für kopierte Assets oder Code.
Falls die Quelle, das erwartete Verhalten oder die Ziel-EmDash-Umgebung fehlen, melde die Lücke, anstatt eine Entsprechung zu erfinden.
Jede Verantwortung zuweisen
| WordPress-Verantwortung | EmDash-Ziel |
|---|---|
| Benutzerdefinierter Beitragstyp, Taxonomie oder Metadaten | Collection, Taxonomie und Felder, erstellt über das Site-Schema oder Seed |
| Seitenweite Präsentationseinstellung | Site-Einstellung, gelesen von Astro-Vorlagen |
| Plugin-eigene Benutzereinstellungen | ctx.settings; Anmeldeinformationen als verschlüsselte secret-Felder deklarieren |
| Plugin-eigene Cursor, Caches oder interner Zustand | Plugin-bezogener ctx.kv |
| Plugin-eigene abfragbare Datensätze | Deklarierter ctx.storage.<collection>-Speicher |
| Inhaltserkennung, Übersetzung oder Veröffentlichung | Berechtigungsgesteuerte ctx.content und ctx.schema; Policy-Hooks und -Aktionen haben separate Autorität |
| Laufzeit-Taxonomie- oder Redirect-Verwaltung | ctx.taxonomies oder ctx.redirects mit enger Lese-/Schreibberechtigung |
| Kommentarverwaltung | ctx.comments; Lesezugriffe legen personenbezogene Daten offen und Moderation verwendet erwartete Status |
| WordPress-REST-Endpunkt | Deklarierte Plugin-Route mit expliziten Methoden, Eingaben, Headern und Antwortmodus |
| Geplanter Ereignis | cron-Hook und ctx.cron-Planung |
| Admin-Seite oder -Formular | Block Kit für sandboxierte Plugins; React nur für ein vertrauenswürdiges natives Plugin |
| Metabox des Beitragseditors oder Aktion beim Speichern | admin.editorPanels oder admin.editorActions auf privaten Routen |
| Benutzer- oder Autorensuche | ctx.users mit users:read |
| Ausgehende HTTP-Anfrage | ctx.http.fetch() mit network:request und einem allowedHosts-Eintrag |
| Medienoperation | Getrennte Metadaten-, Byte-Lese-, Metadaten-Schreib- und Hochladen/Löschen-Berechtigungen |
WP_Query oder Template-Tag | EmDash-Inhalts-API in Astro-Site-Code |
| Shortcode oder Editor-Block | Vorhandener Portable Text Inhalt wo möglich; ein benutzerdefinierter Portable Text Block erfordert ein vertrauenswürdiges natives Plugin |
| Raw Head-Markup oder Skripte | Vertrauenswürdiger nativer page:fragments; per Registry installierte Plugins können nur validiertes page:metadata beitragen |
Erstelle keine Collections oder Taxonomien, indem du in EmDash-Systemtabellen eingreifst. Verwende das öffentliche Schema, Seed, CLI oder die Admin-Grenze. Verwende keine internen REST-Routen, um eine Sandbox-API zu imitieren, die nicht existiert.
Halte Berechtigungen getrennt: Das Lesen von Medienmetadaten gewährt keine Bytes, Moderation gewährt keine Löschung, Veröffentlichungspolitik gewährt keine Veröffentlichungsaktionen, und das Wiederherstellen von Inhalten gewährt keine gewöhnlichen Inhaltslesevorgänge.
Das Plugin-Format wählen
Standardmäßig ein sandboxiertes Plugin verwenden. Es unterstützt portable Hooks, Routen, deklarierten Speicher, Medien, Netzwerkzugriff, MCP-Tools und eine Block-Kit-Admin-Benutzeroberfläche über einen Installationszeit-Vertrauensvertrag.
Ein vertrauenswürdiges natives Plugin nur dann verwenden, wenn das Feature Host-Prozesszugriff, React-Admin-Code, Astro-Rendering-Komponenten, rohe Seitenfragmente oder benutzerdefinierte Portable-Text-Block-Definitionen erfordert. Gib die zusätzliche Autorität und die Verteilungseinschränkung im Migrationsplan an.
Einige WordPress-Plugins benötigen kein EmDash-Plugin. Ein benutzerdefinierter Beitragstyp plus Frontend-Vorlagen können zu reinem Schema, Seed-Daten und Astro-Seiten werden. Füge keine Laufzeiterweiterung hinzu, wenn die statische Site-Struktur das Verhalten abdeckt.
Datenbewegung planen
Beschreibe, wie vorhandene WordPress-Daten abgebildet werden, bevor Laufzeitcode geschrieben wird:
- Beitrags-IDs, Slugs, Gebietsschemata, Autoren, Status, Revisionen und Veröffentlichungsdaten abbilden;
- Beziehungen zwischen Beiträgen, Begriffen, Medien und Plugin-eigenen Datensätzen bewahren;
- einen einmaligen Import von Daten unterscheiden, die weiterhin synchronisiert werden müssen;
- Importe wiederholbar machen und definieren, wie Duplikate erkannt werden;
- Quellkennungen behalten, wenn sie für Abgleiche oder Weiterleitungen benötigt werden;
- Inhalte identifizieren, die ohne eine Produktentscheidung nicht dargestellt werden können.
Seed-Daten für das anfängliche Schema und Beispielinhalte einer neuen Website verwenden. Einen Importer oder Migrationspfad für die Produktionsdaten einer bestehenden Website verwenden; ein Seed ist kein Backup oder Mechanismus zur fortlaufenden Synchronisation.
Äquivalentes Verhalten überprüfen
Testen über die Grenze hinweg, die Benutzer und die Laufzeit nutzen:
- Schema- und importierte Datenbehauptungen für Änderungen am Inhaltsmodell;
- Plugin-Tests auf Produktionsgrenze für Sandbox-Hooks, Routen, Speicher und Berechtigungen;
- Browser-Überprüfung für Admin- und Frontend-Abläufe;
- Neustart-, Duplikatzustellungs-, Autorisierungs- und Fehlerfälle, wenn das Quellfeature davon abhängt.
Vergleiche beobachtbares Verhalten, nicht interne Struktur. Dokumentiere beabsichtigte Unterschiede und alle WordPress-Funktionen, die weiterhin nicht unterstützt werden.
Den Port ausliefern
Bereitstellen:
- eine knappe Bestandsaufnahme des WordPress-Verhaltens und der Daten;
- die Verantwortungszuordnung und die Entscheidung für sandboxiert/nativ;
- den Datenmigrations- oder Seed-Plan;
- die Implementierung über Plugin- und Site-Code;
- Überprüfungsnachweise und bekannte Lücken;
- Quellenangabe und Lizenzhinweise für wiederverwendeten Code oder Assets.