Porter un plugin WordPress vers EmDash
Préservez le comportement visible par l'utilisateur et le modèle de données du plugin sans traduire le PHP ligne par ligne. WordPress et EmDash répartissent les responsabilités différemment, alors décidez d'abord si chaque fonctionnalité appartient au schéma de site, au code Astro, à un plugin sandboxé ou à un plugin natif de confiance.
Chargez creating-plugins avant d'implémenter le code du plugin. Chargez building-emdash-site lorsque le portage modifie des collections, des seeds, des requêtes ou des modèles frontend. Ces compétences définissent les API actuelles ; cette compétence couvre les décisions de migration.
Comprendre la source
Inspectez le code source du plugin, son comportement d'installation, les modifications de base de données, les hooks, les endpoints REST, les tâches planifiées, les écrans d'administration, les shortcodes ou blocs, le rendu frontend, les permissions et les services externes. Identifiez le comportement sur lequel les utilisateurs comptent, séparément de l'implémentation spécifique à WordPress.
Enregistrez :
- les données de contenu et de configuration requises ;
- les actions qui modifient ou publient des données ;
- les limites d'autorisation et de confiance ;
- le comportement en arrière-plan ou de nouvelle tentative ;
- les interactions frontend et administrateur ;
- les besoins d'importation, de migration et de restauration ;
- les obligations de licence pour les actifs ou le code copiés.
Si la source, le comportement attendu ou l'environnement EmDash cible est manquant, signalez l'écart au lieu d'inventer un équivalent.
Attribuer chaque responsabilité
| Responsabilité WordPress | Destination EmDash |
|---|---|
| Type de publication personnalisé, taxonomie ou métadonnées | Collection, taxonomie et champs créés via le schéma de site ou la seed |
| Paramètre de présentation à l'échelle du site | Paramètre de site lu par les modèles Astro |
| Paramètres utilisateur appartenant au plugin | ctx.settings ; déclarez les identifiants comme champs secret cryptés |
| Curseurs, caches ou état interne du plugin | Stockage ctx.kv dédié au plugin |
| Enregistrements interrogeables appartenant au plugin | Stockage ctx.storage.<collection> déclaré |
| Découverte, traduction ou publication de contenu | ctx.content et ctx.schema limités par les capacités ; les hooks de politique et les actions ont une autorité séparée |
| Gestion des taxonomies ou des redirections à l'exécution | ctx.taxonomies ou ctx.redirects avec une capacité de lecture/écriture restreinte |
| Administration des commentaires | ctx.comments ; les lectures exposent les données personnelles et l'utilisation de la modération avec le statut attendu |
| Endpoint REST WordPress | Route de plugin déclarée avec méthodes, entrées, en-têtes et mode de réponse explicites |
| Événement planifié | Hook cron et planification ctx.cron |
| Page ou formulaire d'administration | Block Kit pour les plugins sandboxés ; React uniquement pour un plugin natif de confiance |
| Metabox de l'éditeur de publication ou action d'entrée enregistrée | admin.editorPanels ou admin.editorActions sur des routes privées |
| Recherche d'utilisateur ou d'auteur | ctx.users avec users:read |
| Requête HTTP sortante | ctx.http.fetch() avec network:request et une entrée allowedHosts |
| Opération sur un média | Autorités séparées pour les métadonnées, la lecture d'octets, l'écriture de métadonnées et le téléchargement/suppression |
WP_Query ou balise de modèle | API de contenu EmDash dans le code du site Astro |
| Shortcode ou bloc d'éditeur | Contenu Portable Text existant lorsque c'est possible ; un bloc Portable Text personnalisé nécessite un plugin natif de confiance |
| Code head ou scripts bruts | page:fragments natif de confiance ; les plugins installés via le registre peuvent seulement contribuer des page:metadata validés |
Ne créez pas de collections ou de taxonomies en accédant aux tables système d'EmDash. Utilisez le schéma public, la seed, la CLI ou la limite d'administration. N'utilisez pas de routes REST internes pour imiter une API sandbox qui n'existe pas.
Gardez les autorités séparées : la lecture des métadonnées d'un média n'accorde pas les octets, la modération n'accorde pas la suppression, la politique de publication n'accorde pas les actions de publication, et la restauration de contenu n'accorde pas les lectures de contenu ordinaires.
Choisir le format du plugin
Utilisez un plugin sandboxé par défaut. Il prend en charge les hooks portables, les routes, le stockage déclaré, les médias, l'accès réseau, les outils MCP et l'interface utilisateur d'administration Block Kit via un contrat de confiance à l'installation.
Utilisez un plugin natif de confiance uniquement lorsque la fonctionnalité nécessite un accès au processus hôte, du code d'administration React, des composants de rendu Astro, des fragments de page bruts ou des définitions de blocs Portable Text personnalisées. Indiquez l'autorité supplémentaire et la limitation de distribution dans le plan de migration.
Certains plugins WordPress n'ont pas besoin d'un plugin EmDash. Un type de publication personnalisé avec des modèles frontend peut devenir uniquement un schéma, des données de seed et des pages Astro. N'ajoutez pas d'extension d'exécution lorsque la structure statique du site couvre le comportement.
Planifier le déplacement des données
Décrivez comment mapper les données WordPress existantes avant d'écrire du code d'exécution :
- mapper les ID de publication, les slugs, les locales, les auteurs, les statuts, les révisions et les dates de publication ;
- préserver les relations entre les publications, les termes, les médias et les enregistrements appartenant au plugin ;
- distinguer une importation unique d'une synchronisation continue ;
- rendre les importations redémarrables et définir comment les doublons sont détectés ;
- conserver les identifiants sources lorsqu'ils sont nécessaires pour la réconciliation ou les redirections ;
- identifier le contenu qui ne peut pas être représenté sans une décision produit.
Utilisez les données de seed pour le schéma initial et le contenu d'exemple d'un nouveau site. Utilisez un importateur ou un chemin de migration pour les données de production d'un site existant ; une seed n'est pas un mécanisme de sauvegarde ou de synchronisation continue.
Vérifier le comportement équivalent
Testez à travers la frontière qu'exercent les utilisateurs et l'exécution :
- assertions sur le schéma et les données importées pour les modifications du modèle de contenu ;
- tests de plugin en limite de production pour les hooks, routes, stockage et permissions du sandbox ;
- vérification navigateur pour les parcours d'administration et frontend ;
- cas de redémarrage, de livraison en double, d'autorisation et d'échec lorsque la fonctionnalité source en dépend.
Comparez le comportement observable, pas la structure interne. Documentez les différences intentionnelles et toute fonctionnalité WordPress qui reste non prise en charge.
Livrer le portage
Fournissez :
- un inventaire concis du comportement et des données WordPress ;
- la carte des responsabilités et la décision sandboxé/natif ;
- le plan de migration des données ou de la seed ;
- l'implémentation dans le code du plugin et du site ;
- les preuves de vérification et les lacunes connues ;
- l'attribution et les avis de licence pour le code ou les actifs réutilisés.