Migrar do WordPress

Não há um importador de WordPress residente no Chinaski: nenhum parser de exportação WXR/XML, nenhum script de migração wp_posts. A migração é um exercício de preparar-fora, importar-dentro, usando as superfícies de importação que o produto de fato embarca. Esta página mapeia o que funciona, o que não tem suporte e uma ordem de migração prática.

O que migra de forma limpa hoje

Três superfícies de destino verificadas aceitam conteúdo estruturado:

Opção A: arquivos Markdown (a válvula de escape natural do WordPress)

O importador de Markdown (/admin/import-markdown, apontado tanto de Posts quanto de Pages) aceita:

• Um único arquivo .md ou um lote de até 100 arquivos (40 MiB agregados).
• Front matter YAML por arquivo: title, slug, language, meta_title, meta_description, category, tags, date.
• Fallbacks graciosos: um título ausente cai para o primeiro heading H1 do arquivo, depois para um nome de arquivo embelezado.
• Importações criam rascunhos por desígnio explícito: nada é autopublicado, e a publicação agendada nunca é perturbada por uma importação.
• Isolamento de erro por arquivo: arquivos que falham são nomeados no resultado sem falhar o lote inteiro.
• O Markdown é convertido no lado do servidor via o módulo opcional CommonMark; se seu host não o tem, a rota reporta um erro de admin claro (instale o módulo ou use conteúdo HTML pelos caminhos JSON/CSV/API).

Exportar conteúdo do WordPress para arquivos .md (título + front matter + corpo) é o caminho menos testado: muitos plugins de exportação de WP emitem Markdown diretamente, ou um pequeno script pode desenrolar as linhas de wp_posts.

Opção B: JSON/CSV

As rotas de exportação das listas de páginas/posts emitem o conjunto completo de colunas na ordem que o endpoint de importação espera (metadados OG, URL canônica, datas de agendamento no fuso do site, aninhamento, recorrência). Construa um conversor que mapeie os campos do WordPress nessas colunas e no HTML de wp_content, alimente-o como JSON/CSV, e as revisões/importações aterrissam com a maquinaria de ida-e-volta fazendo a checagem de sintaxe por você.

Opção C: a API REST (e o bulk do MCP)

Para migrações grandes/em lote, a superfície /api/* é a mais limpa:

• POST/PUT para itens únicos (páginas, posts, blocos, snippets…).
• POST /api/jobs aceitando bulk_upsert_pages, bulk_upsert_posts, bulk_create_blocks para lotes grandes (os upserts casam por slug+idioma).
• Se você já está conectado ao servidor MCP, bulk_import e suas ferramentas de tradução/auditoria usam a mesma superfície.

Mídia

Não há importador de mídia do WordPress. wp-content/uploads é reenviado pela biblioteca de mídia (upload em massa funciona) ou por script, asset a asset, via a API; então as referências no corpo são corrigidas (buscar/substituir caminhos antigos do domínio de uploads → novos caminhos de mídia). As substituições de mídia em outros lugares mantêm o mesmo nome de arquivo, de modo que qualquer referência pós-importação pode apontar para o mesmo lugar.

O que NÃO migra

• Temas do WordPress (hierarquias de templates PHP): o Chinaski não tem theming PHP; redesenhe em Template Toolkit, opcionalmente gerado via o fluxo de design-brief nos docs no app.
• Plugins do WP: não há arquitetura de hooks em que mapear; funcionalidades de plugins viram blocos, snippets ou processo editorial.
• Revisões, autosaves, histórico de aprovação: trate a migração como “trazer o conteúdo ao vivo”, não como proveniência; as trilhas de auditoria/revisão começam do zero.
• Plugins de formulários: nada mapeia automaticamente; reconstrua os formulários no editor de formulários do Chinaski e redirecione os shortcodes.
• Sistemas de comentários: não há equivalente; cubra separadamente se necessário.

A ordem de migração prática

1. Exporte do WordPress: tire wp_posts + categorias/tags (qualquer plugin de exportação do WP ou SQL).
2. Converta offline para arquivos Markdown com front matter ou para uma lista JSON na ordem de colunas de importação; ponha cada idioma sob seu próprio diretório/campo.
3. Envie a mídia separadamente: reenvie-a para a biblioteca de mídia (em massa) ou use a rota REST por script; então corrija as referências internas do conteúdo importado.
4. Execute a importação: o importador de Markdown por lote de arquivos ou o bulk da API para dados estruturados; os rascunhos chegam para revisão de conteúdo.
5. Confira por amostragem: verifique slugs, datas sensíveis a fuso, categorias (cada linha de conteúdo aterrissa sob o idioma configurado no lote de importação) e as referências de imagem.
6. Publique: aprove ou publique os rascunhos (o fluxo de aprovação pode estar desligado para admins e ligado para editores).
7. Trate as URLs antigas: exporte o mapeamento URL-do-wp→URL-nova e adicione redirecionamentos na seção de redirecionamentos do admin (padrões suportados onde o reverse proxy os impõe). Links antigos de mecanismos de busca continuam válidos.

O que você configurará à mão, não migrado

• Contas de usuário/admin: novos logins por instância (usuários do WordPress não atravessam).
• Tema: autoria em Template Toolkit com uma escolha de sistemas de design (o fluxo de prompt de LLM Theme Prompting dos docs é a configuração mais rápida para um design personalizado).
• Stacks de formulários: cada formulário de contato/feedback é reconstruído sob os Forms do Chinaski.
• Qualquer plugin WP sem equivalente direto no Chinaski: busca, SEO, cache, plugins de segurança; use os subsistemas relevantes no app (SEO é embutido; cache é o modelo de build estático).
• Agendamentos: os pontos de ativação cron/systemd da nova instância (deploy/backup/DB) como sua própria instalação operacional. Se o seu WordPress os executava a partir de plugins, os serviços próprios desta instalação os substituem.