CMS e API

Guia de implementação WordPress.

Escolha deliberadamente a entrega do widget ou API, mantenha a página original canônica e publique versões de idiomas por meio de revisões.

Esclareça a tarefa e a decisão

Este guia transforma o guia de implementação wordpress em um fluxo de trabalho operacional revisável. Ele conecta decisões de domínio, propriedade, evidências e aceitação para que o resultado continue funcionando na produção.

Escolha deliberadamente a entrega do widget ou API, mantenha a página original canônica e publique versões de idiomas por meio de revisões.

Processo prático

  1. 1

    Tipos de origem de inventário, identificadores, campos, localidades, proprietários e estados de publicação.

  2. 2

    Escolha o padrão de entrega entre volume, latência, controle editorial e tolerância a falhas.

  3. 3

    Mapeie o registro de origem para um registro de versão de idioma separado com ligação durável.

  4. 4

    Adicione autenticação, idempotência, nova tentativa, invalidação de cache, registro em log e controles de acesso.

  5. 5

    Publicação de testes, alterações de origem, resultados indisponíveis, reversão, operação do teclado e monitoramento antes do lançamento.

Exemplo ou ferramenta

Um fluxo de trabalho do Gutenberg mapeia páginas de origem, estados de revisão, chaves de cache e navegação de idioma. Na ferramenta, registre também a linha de base, o proprietário, a decisão, as evidências, a questão em aberto e a data de aprovação. Use uma página ou transação real para que a equipe veja dependências, exceções e o trabalho de manutenção que segue o lançamento.

Ponto de decisãoRegistroCritério de aceitação
Linha de baseEstado atual observadoFonte e data registrada
DecisãoOpção selecionada e justificativaRisco e público considerados
EvidênciaTeste, documente ou meçaRevisável e específico da versão
AprovaçãoNome, função e dataTodos os critérios obrigatórios atendidos

Escolha widget, plug-in ou entrega API do lado do servidor

Use um widget quando a velocidade de implantação for importante, as páginas de origem já tiverem identificadores duráveis ​​e uma dependência do lado do cliente for aceitável. Use um plugin WordPress quando os editores precisarem de geração e revisão dentro da interface de administração. Use a entrega API do lado do servidor quando as versões do idioma precisarem ser indexadas, armazenadas em cache, incluídas em feeds e renderizadas mesmo quando o JavaScript não estiver disponível. Grandes editores geralmente combinam um plug-in para fluxo de trabalho com renderização no servidor para entrega.

Documente a escolha em relação ao controle editorial, desempenho, acessibilidade, pesquisa, comportamento de falha, fluxo de dados e propriedade de manutenção. A página original continua sendo a fonte oficial. Uma versão em idioma obtém sua própria postagem ou registro estruturado, URL estável, status de revisão e link de revisão da fonte. Evite armazenar conteúdo alternativo apenas em um campo personalizado sem versão ou cache do navegador, pois os revisores não podem aprová-lo, restaurá-lo ou auditá-lo de maneira confiável.

PadrãoMelhor ajusteControle primário
WidgetAdição rápida a um site controladoFallback acessível e estado de falha
Fluxo de trabalho do plug-inOs editores trabalham inteiramente em WordPressFunções, nonces, capacidades e revisões
API do lado do servidorPáginas indexadas, armazenáveis ​​em cache e resilientesFila, invalidação de cache e operações de implantação

Modelo de relacionamentos de origem e estados editoriais

Crie um tipo de postagem de versão de idioma ou use uma estrutura multilíngue que suporte relacionamentos de origem explícitos. Armazene o ID da postagem de origem, o ID da revisão de origem, a localidade de destino, o modo de idioma, o ID do resultado, a versão do glossário, o status da revisão, os aprovadores, a revisão publicada e o gatilho de revisão. Mantenha a estrutura de bloco transformada sempre que possível para que títulos, listas, links, tabelas e avisos permaneçam semânticos em vez de serem nivelados em um campo HTML.

Defina status para solicitado, geração, rascunho, revisão de assunto, revisão de idioma, aprovado, publicado, obsoleto e reprovado. Mapeie cada transição para um recurso WordPress, não apenas para um botão visível. Um gerador pode criar um rascunho, mas não pode aprová-lo. Quando a fonte for alterada, compare sua revisão com a revisão de origem aprovada e mova a versão do idioma para obsoleta ou seja necessária revisão. Não publique silenciosamente um resultado regenerado.

  1. 1

    Registre o registro da versão do idioma e os metadados necessários com sanitização e permissões REST.

  2. 2

    Mapeie blocos Gutenberg suportados e defina o comportamento para blocos não suportados.

  3. 3

    Configure funções e transições de status permitidas.

  4. 4

    Gere em uma revisão separada e apresente uma comparação de origem.

  5. 5

    Publique somente após as aprovações necessárias para o nível de risco do conteúdo.

Armazene em cache com segurança e forneça navegação de idioma durável

Crie chaves de cache do site, ID da postagem de origem, revisão da fonte, localidade, modo de idioma e versão do renderizador. Invalidar a página do idioma relacionado quando sua revisão aprovada for alterada, sua fonte for alterada, um bloco compartilhado for alterado ou uma regra de terminologia relevante for republicada. Se o processamento for executado de forma assíncrona, veicule a última versão aprovada enquanto o novo rascunho é revisado. Nunca substitua o conteúdo aprovado por um estado vazio porque a geração não está disponível.

Adicione links de idiomas como âncoras comuns renderizadas pelo servidor com nomes claros, como ‘linguagem simples’ e ‘leitura fácil’. Inclua links recíprocos para a página de origem e corrija metadados em idiomas alternativos. Preserve o foco do teclado após uma troca de página e anuncie uma mudança de rota somente por meio do título e cabeçalho normais da página. Uma versão ausente deve explicar que ela está indisponível e vincular de volta à fonte, não ocultar o controle ou fazer loopback silenciosamente.

  • As chaves de cache incluem versões de origem e de renderizador.

  • A última página aprovada sobrevive a API e interrupções na fila.

  • Os links de idiomas funcionam sem JavaScript e usam terminologia aprovada.

  • Os metadados canônicos e alternativos refletem o relacionamento real.

  • As alterações no bloco compartilhado e no glossário acionam as tarefas de revisão afetadas.

Teste o caminho completo de publicação e reversão

Use uma cópia de teste com blocos representativos de Gutenberg, campos personalizados, formulários incorporados, blocos reutilizáveis ​​e postagens restritas. Geração de testes, aplicação de funções, comentários de revisão, publicação agendada, visualização, invalidação de cache, atualização de origem, marcação obsoleta, exclusão, restauração e reversão. Confirme se os pontos de extremidade REST rejeitam leituras e gravações não autorizadas e se os trabalhos em segundo plano não podem ser acionados entre sites sem credenciais válidas de servidor ou nonce.

Antes da produção, defina o monitoramento de filas, propriedade de erros, rotação de credenciais, teste de atualização de plugins, backup de banco de dados e um procedimento de desativação segura. A aceitação requer renderização correta em pontos de interrupção comuns, navegação por teclado e leitor de tela, nenhuma mudança de layout de conteúdo tardio, títulos estruturados válidos, aprovação rastreável e restauração da última revisão aprovada. Registre o WordPress suportado, PHP, editor, plug-in multilíngue e configurações de cache.

Funções, evidências e aprovação

Mantenha a geração separada da publicação. Uma resposta bem-sucedida é um rascunho, não uma aprovação. Armazene o identificador de origem e a versão, as configurações de transformação, o identificador de resultado, o estado de revisão, o aprovador e o horário de publicação. Quando a fonte for alterada, marque a versão do idioma para revisão em vez de substituir silenciosamente o conteúdo aprovado. Isso torna possível a reversão e a auditoria em todas as plataformas.

Operações e manutenção

O trabalho não termina na publicação. Vincule a versão ou configuração do idioma à sua origem, monitore medidas de qualidade e serviço e defina gatilhos de revisão concretos. Os gatilhos incluem alterações na fonte, alterações legais, novas necessidades do público, dúvidas recorrentes de suporte, alterações técnicas e incidentes. Um proprietário nomeado avalia o gatilho, abre uma nova revisão quando necessário e registra a aprovação renovada.

Lista de verificação para publicação

  • A integração usa identificadores de origem duráveis.

  • As credenciais são armazenadas no servidor e rotacionadas.

  • O comportamento de tempo limite, nova tentativa e limite de taxa são definidos.

  • Solicitações repetidas são idempotentes.

  • O conteúdo gerado entra em estado de revisão.

  • As alterações na origem invalidam ou reabrem a versão.

  • A navegação por idioma funciona por teclado e tecnologia assistiva.

  • O monitoramento cobre falhas, filas, latência e conteúdo obsoleto.

Fontes de referência

  1. Documentação Simple8 API
  2. Padrões de entrega Simple8
  3. Diretrizes de acessibilidade para conteúdo da Web (WCAG) 2.2

Coloque o guia em prática

Teste Simple8 com conteúdo representativo e use a lista de verificação para planejar um fluxo de trabalho de produção controlado.

Teste seu próprio texto