Portar um plugin WordPress para o EmDash
Preserve o comportamento visível ao usuário e o modelo de dados do plugin sem traduzir PHP linha por linha. WordPress e EmDash dividem responsabilidades de forma diferente, portanto, primeiro decida se cada funcionalidade pertence ao schema do site, ao código Astro, a um plugin sandboxed ou a um plugin nativo confiável.
Carregue creating-plugins antes de implementar o código do plugin. Carregue building-emdash-site quando a porta alterar coleções, seeds, consultas ou templates frontend. Essas skills definem as APIs atuais; esta skill cobre as decisões de migração.
Entender a fonte
Inspecione o código fonte do plugin, comportamento de instalação, alterações no banco de dados, hooks, endpoints REST, trabalhos agendados, telas administrativas, shortcodes ou blocos, saída frontend, permissões e serviços externos. Identifique o comportamento no qual os usuários confiam separadamente da implementação específica do WordPress.
Registre:
- dados de conteúdo e configuração necessários;
- ações que alteram ou publicam dados;
- autorização e limites de confiança;
- comportamento em segundo plano ou de repetição;
- interações frontend e administrativas;
- necessidades de importação, migração e reversão;
- obrigações de licença para ativos ou código copiados.
Se a fonte, o comportamento esperado ou o ambiente EmDash alvo estiverem faltando, relate a lacuna em vez de inventar um equivalente.
Atribuir cada responsabilidade
| Responsabilidade WordPress | Destino no EmDash |
|---|---|
| Custom post type, taxonomia ou metadados | Coleção, taxonomia e campos criados através do schema do site ou seed |
| Configuração de apresentação do site inteiro | Configuração do site lida por templates Astro |
| Configurações de usuário do plugin | ctx.settings; declare credenciais como campos secret criptografados |
| Cursores, caches ou estado interno do plugin | ctx.kv com escopo do plugin |
| Registros consultáveis de propriedade do plugin | Armazenamento ctx.storage.<collection> declarado |
| Descoberta de conteúdo, tradução ou publicação | ctx.content e ctx.schema com controle de capacidade; hooks de política e ações têm autoridade separada |
| Gerenciamento de taxonomia ou redirecionamentos em tempo de execução | ctx.taxonomies ou ctx.redirects com capacidade restrita de leitura/escrita |
| Administração de comentários | ctx.comments; leituras expõem dados pessoais e moderação usa status esperado |
| Endpoint REST do WordPress | Rota de plugin declarada com métodos, entradas, cabeçalhos e modo de resposta explícitos |
| Evento agendado | Hook cron e agendamento ctx.cron |
| Página ou formulário administrativo | Block Kit para plugins sandboxed; React apenas para um plugin nativo confiável |
| Metabox do editor de post ou ação de entrada salva | admin.editorPanels ou admin.editorActions em rotas privadas |
| Busca de usuário ou autor | ctx.users com users:read |
| Requisição HTTP de saída | ctx.http.fetch() com network:request e uma entrada allowedHosts |
| Operação de mídia | Autoridades separadas para metadados, leitura de bytes, escrita de metadados e upload/delete |
WP_Query ou tag de template | API de conteúdo EmDash no código do site Astro |
| Shortcode ou bloco do editor | Conteúdo Portable Text existente quando possível; um bloco Portable Text personalizado requer plugin nativo confiável |
| Marcação head bruta ou scripts | page:fragments nativo confiável; plugins registrados na instalação podem contribuir apenas page:metadata validado |
Não crie coleções ou taxonomias acessando tabelas internas do EmDash. Use o schema público, seed, CLI ou limite administrativo. Não use rotas REST internas para imitar uma API sandbox que não existe.
Mantenha as autoridades separadas: ler metadados de mídia não concede bytes, moderação não concede exclusão, política de publicação não concede ações de publicação, e restaurar conteúdo não concede leituras comuns de conteúdo.
Escolher o formato do plugin
Use um plugin sandboxed por padrão. Ele suporta hooks portáteis, rotas, armazenamento declarado, mídia, acesso à rede, ferramentas MCP e interface administrativa Block Kit através de um contrato de confiança na instalação.
Use um plugin nativo confiável apenas quando o recurso exigir acesso ao processo host, código React administrativo, componentes de renderização Astro, fragmentos de página brutos ou definições de bloco Portable Text personalizadas. Indique a autoridade extra e a limitação de distribuição no plano de migração.
Alguns plugins WordPress não precisam de um plugin EmDash. Um custom post type mais templates frontend pode se tornar apenas schema, dados seed e páginas Astro. Não adicione uma extensão em tempo de execução quando a estrutura estática do site cobrir o comportamento.
Planejar a movimentação de dados
Descreva como os dados existentes do WordPress se mapeiam antes de escrever código em tempo de execução:
- mapeie IDs de post, slugs, locales, autores, status, revisões e datas de publicação;
- preserve relacionamentos entre posts, termos, mídia e registros de propriedade do plugin;
- distinga uma importação única de dados que devem continuar sincronizando;
- torne as importações reiniciáveis e defina como duplicatas são detectadas;
- mantenha identificadores fonte quando forem necessários para reconciliação ou redirecionamentos;
- identifique conteúdo que não pode ser representado sem uma decisão de produto.
Use dados seed para o schema inicial de um novo site e conteúdo de exemplo. Use um importador ou caminho de migração para dados de produção de um site existente; um seed não é um backup ou mecanismo de sincronização contínua.
Verificar comportamento equivalente
Teste através do limite que os usuários e o runtime exercitam:
- asserções de schema e dados importados para alterações no modelo de conteúdo;
- testes de plugin no limite de produção para hooks sandbox, rotas, armazenamento e permissões;
- verificação no navegador para jornadas administrativas e frontend;
- casos de reinicialização, entrega duplicada, autorização e falha quando o recurso fonte depende deles.
Compare comportamento observável, não estrutura interna. Documente diferenças intencionais e qualquer recurso WordPress que permaneça sem suporte.
Entregar a porta
Forneça:
- um inventário conciso do comportamento e dados do WordPress;
- o mapa de responsabilidades e a decisão de sandbox/nativo;
- o plano de migração de dados ou seed;
- a implementação através do código do plugin e do site;
- evidências de verificação e lacunas conhecidas;
- atribuição e avisos de licença para código ou ativos reutilizados.