Trasplantar un plugin de WordPress a EmDash
Preserva el comportamiento visible para el usuario y el modelo de datos del plugin sin traducir PHP línea por línea. WordPress y EmDash dividen las responsabilidades de manera diferente, por lo que primero debes decidir si cada funcionalidad pertenece al esquema del sitio, código Astro, un plugin sandbox o un plugin nativo de confianza.
Carga creating-plugins antes de implementar el código del plugin. Carga building-emdash-site cuando el trasplante modifique colecciones, semillas, consultas o plantillas del frontend. Esas habilidades definen las APIs actuales; esta habilidad cubre las decisiones de migración.
Comprender la fuente
Inspecciona el código fuente del plugin, el comportamiento de instalación, los cambios en la base de datos, los hooks, los endpoints REST, el trabajo programado, las pantallas de administración, los shortcodes o bloques, la salida del frontend, los permisos y los servicios externos. Identifica el comportamiento del que dependen los usuarios por separado de la implementación específica de WordPress.
Registra:
- contenido requerido y datos de configuración;
- acciones que mutan o publican datos;
- autorización y límites de confianza;
- comportamiento en segundo plano o de reintento;
- interacciones del frontend y del administrador;
- necesidades de importación, migración y reversión;
- obligaciones de licencia para activos o código copiados.
Si la fuente, el comportamiento esperado o el entorno EmDash destino faltan, reporta la brecha en lugar de inventar un equivalente.
Asignar cada responsabilidad
| Responsabilidad de WordPress | Destino en EmDash |
|---|---|
| Tipo de contenido personalizado, taxonomía o metadatos | Colección, taxonomía y campos creados a través del esquema del sitio o semilla |
| Ajuste de presentación a nivel de sitio | Ajuste de sitio leído por las plantillas Astro |
| Ajustes de usuario del plugin | ctx.settings; declarar credenciales como campos secret encriptados |
| Cursores, cachés o estado interno del plugin | ctx.kv con ámbito de plugin |
| Registros consultables propiedad del plugin | Almacenamiento declarado ctx.storage.<collection> |
| Descubrimiento, traducción o publicación de contenido | ctx.content y ctx.schema con control de capacidades; los hooks de políticas y acciones tienen autoridad separada |
| Gestión de taxonomías o redirecciones en tiempo de ejecución | ctx.taxonomies o ctx.redirects con capacidad limitada de lectura/escritura |
| Administración de comentarios | ctx.comments; las lecturas exponen datos personales y los estados de moderación esperados |
| Endpoint REST de WordPress | Ruta de plugin declarada con métodos, entradas, encabezados y modo de respuesta explícitos |
| Evento programado | Hook cron y programación ctx.cron |
| Página o formulario de administración | Block Kit para plugins sandbox; React solo para un plugin nativo de confianza |
| Metabox del editor de entradas o acción al guardar una entrada | admin.editorPanels o admin.editorActions en rutas privadas |
| Búsqueda de usuario o autor | ctx.users con users:read |
| Solicitud HTTP saliente | ctx.http.fetch() con network:request y una entrada allowedHosts |
| Operación multimedia | Separar autoridades: metadatos, lectura de bytes, escritura de metadatos, y subir/eliminar |
WP_Query o etiqueta de plantilla | API de contenido de EmDash en el código del sitio Astro |
| Shortcode o bloque del editor | Texto Portátil existente cuando sea posible; un bloque de Texto Portátil personalizado requiere un plugin nativo de confianza |
Marcado <head> o scripts sin procesar | page:fragments de plugin nativo de confianza; los plugins instalados por registro solo pueden contribuir page:metadata validado |
No crees colecciones o taxonomías accediendo a las tablas del sistema de EmDash. Usa el esquema público, semilla, CLI o límite de administración. No uses rutas REST internas para imitar una API sandbox que no existe.
Mantén las autoridades separadas: leer metadatos multimedia no otorga bytes, la moderación no otorga eliminación, la política de publicación no otorga acciones de publicación, y la restauración de contenido no otorga lecturas ordinarias de contenido.
Elegir el formato del plugin
Usa un plugin sandbox por defecto. Admite hooks portátiles, rutas, almacenamiento declarado, multimedia, acceso a la red, herramientas MCP y UI de administración con Block Kit a través de un contrato de confianza en el momento de la instalación.
Usa un plugin nativo de confianza solo cuando la funcionalidad requiera acceso al proceso del host, código React de administración, componentes de renderizado de Astro, fragmentos de página sin procesar o definiciones de bloques de Texto Portátil personalizados. Indica la autoridad adicional y la limitación de distribución en el plan de migración.
Algunos plugins de WordPress no necesitan un plugin de EmDash. Un tipo de contenido personalizado más plantillas de frontend puede convertirse solo en esquema, datos de semilla y páginas Astro. No agregues una extensión en tiempo de ejecución cuando la estructura estática del sitio cubra el comportamiento.
Planificar el movimiento de datos
Describe cómo se mapean los datos existentes de WordPress antes de escribir código en tiempo de ejecución:
- mapear IDs de entradas, slugs, locales, autores, estados, revisiones y fechas de publicación;
- preservar relaciones entre entradas, términos, multimedia y registros propiedad del plugin;
- distinguir una importación única de datos que deben seguir sincronizándose;
- hacer las importaciones reiniciables y definir cómo se detectan los duplicados;
- mantener los identificadores de origen cuando sean necesarios para reconciliación o redirecciones;
- identificar contenido que no se puede representar sin una decisión de producto.
Usa datos de semilla para el esquema inicial y contenido de muestra de un nuevo sitio. Usa un importador o ruta de migración para los datos de producción de un sitio existente; una semilla no es una copia de seguridad ni un mecanismo de sincronización continua.
Verificar comportamiento equivalente
Prueba a través del límite que los usuarios y el entorno de ejecución ejercitan:
- aserciones de esquema y datos importados para cambios en el modelo de contenido;
- pruebas de plugin en el límite de producción para hooks sandbox, rutas, almacenamiento y permisos;
- verificación en navegador para recorridos de administración y frontend;
- casos de reinicio, entrega duplicada, autorización y fallos cuando la funcionalidad de origen dependa de ellos.
Compara el comportamiento observable, no la estructura interna. Documenta las diferencias intencionales y cualquier funcionalidad de WordPress que permanezca sin soporte.
Entregar el trasplante
Proporciona:
- un inventario conciso del comportamiento y los datos de WordPress;
- el mapa de responsabilidades y la decisión sandbox/nativo;
- el plan de migración de datos o semilla;
- la implementación en el código del plugin y del sitio;
- evidencia de verificación y brechas conocidas;
- atribución y avisos de licencia para código o activos reutilizados.