miketropi/nextora-child-themes

Temas filhos Nextora

Cria e audita temas filhos do Nextora: a inicialização (bootstrap), o pipeline de ativos e o registrador de blocos filho. As convenções de nível pai residem no próprio pai; os detalhes internos dos blocos pertencem a ../nextora-gutenberg-blocks/SKILL.md, e tudo sobre paleta, fontes ou o alternador de visitante pertence a ../nextora-design-system/SKILL.md.

Referências a carregar

Leia antes de escrever qualquer arquivo, pelo caminho relativo:

• references/child-contract.md — a tabela de substituição slug/prefixo, a receita exata de diretórios, o cabeçalho, o código de inicialização e enfileiramento, o registrador, as convenções PHP, os defeitos observados na amostra e a receita de aceitação downstream do WordPress. Carregue no passo 3 e não escreva código antes de tê-lo feito.
• source-map.md — de onde vem cada regra, com tags de proveniência e os fatos comumente mal interpretados.
• quality-gates.md — os critérios pelos quais o tema filho finalizado é medido. Carregue antes de declarar conclusão.

Ler as fontes locais tem precedência sobre a leitura destes arquivos. Cada valor citado em um skill ou referência é uma âncora, não um fato atual.

Fluxo de trabalho ordenado

1. Resolva as raízes, não as presuma

Em uma instalação ativa, o pai é o diretório de template e o filho é o diretório de stylesheet:

get_template_directory();      // raiz do pai
get_stylesheet_directory();    // raiz do tema ativo (filho quando um está ativo)

Fora de uma instalação, encontre um style.css com Theme Name: Nextora para o pai e um com Template: nextora para o filho. Se a fonte do pai estiver genuinamente faltando, diga isso e pare de reivindicar compatibilidade com Nextora; complete apenas o trabalho que não depende dela. Nunca fabrique uma âncora e nunca substitua um tema diferente silenciosamente.

2. Leia as evidências antes de propor qualquer coisa

Do filho alvo — ou do filho de amostra, quando a amostra é o que está sendo portado:

1. style.css — o cabeçalho real: Template, Version, Requires at least, Requires PHP, Tested up to, Text Domain, License.
2. functions.php — ordem de carregamento e o que o tema requer no escopo do arquivo.
3. theme.json — version, slugs de paleta/fontes, customTemplates, templateParts.
4. package.json e .nvmrc — quais scripts de build existem e em qual Node.
5. inc/, blocks/, resources/, assets/ — o que já existe.

Do pai: style.css, functions.php, inc/assets/assets.php, blocks/blocks.php. Estes são dos quais um filho depende, então seus nomes de handle e comportamento do registrador são o contrato, não a documentação.

3. Corrija a tabela de nomes antes de escrever arquivos

Carregue references/child-contract.md e preencha sua tabela de substituição para o slug solicitado. Cada identificador gerado — funções PHP, constantes, domínio de texto, nomes de blocos, classes CSS, propriedades personalizadas, slugs de padrões, handles e nomes base de arquivos — vem desse único slug. Nomes de propriedade do pai (nextora_*, NEXTORA_*, nextora/*, global-styles, nextora-app, nextora-main, os slugs de paleta e fontes do pai, os papéis --nextora-font-*) nunca são renomeados.

4. Disponha apenas os diretórios que o filho precisa

A receita está em references/child-contract.md. Obrigatórios: raiz style.css, theme.json, functions.php. Adicione inc/, resources/, assets/, templates/, parts/, patterns/ conforme aplicável, blocks/<block-slug>/ apenas quando o filho realmente enviar blocos personalizados, e fontes mais arquivos de licença apenas quando fontes forem enviadas. Não crie andaimes de funcionalidades vazios e não clone uma árvore de tema inteira.

5. Escreva o cabeçalho, depois a constante de versão, depois a inicialização

A ordem importa: inc/bootstrap/version.php define a única constante <CHILD_PREFIX>_VERSION, o cabeçalho style.css Version: deve ser igual a ela, e o pipeline de ativos usa ela como fallback, então a constante deve existir antes que qualquer coisa exija o pipeline. No cabeçalho, declare apenas mínimos reais — nunca copie o valor Tested up to de outro tema.

6. Escreva functions.php com filho-antes-do-pai em mente

WordPress carrega o functions.php de um filho antes do pai, então nada no escopo do arquivo pode chamar uma função do pai ou ler uma constante NEXTORA_*. Defina os próprios _DIR/_URI do filho a partir do diretório de stylesheet, exija o autoloader do Composer apenas quando legível, e exija os próprios arquivos do filho. Toda operação dependente do pai pertence dentro de um hook, e referencia os handles do pai pelo nome e verifica se eles estão registrados primeiro.

7. Conecte o pipeline de ativos

Stylesheet do filho em wp_enqueue_scripts prioridade 25, dependendo dos global-styles e nextora-app do pai quando estes estiverem registrados; script do filho em prioridade 30 dependendo de nextora-main quando registrado; estilos do canvas do editor em after_setup_theme prioridade 20 através de add_editor_style(). Proteja cada enfileiramento com uma verificação de arquivo legível e use nomes base de saída que não colidam — um assets/css/app.css ou assets/js/main.js do filho pode sombrear o ativo do pai. Código completo e tabela de hooks: references/child-contract.md.

8. Adicione o registrador de blocos apenas quando o filho enviar blocos

WordPress não escaneia a pasta blocks/ de um tema. Registre cada diretório que contenha um block.json legível em init a partir de get_stylesheet_directory(), adicione a categoria de inserção do filho e espelhe a coerção de categoria no lado do cliente. Metadados de blocos, UI do editor e renderizadores estão em ../nextora-gutenberg-blocks/SKILL.md. Nenhum diretório blocks/ significa nenhum requisito de registrador.

9. Passe a aparência para o sistema de design

Se o filho deve seguir a troca de cor/fonte predefinida ou do visitante, carregue ../nextora-design-system/SKILL.md na mesma sessão e deixe que ele decida as ligações de papéis, famílias de fontes theme.json e arquivos de predefinições. O corpo, cabeçalhos e botões de um filho resolvem através das variáveis de papel do Nextora; eles nunca são fixados diretamente nas fontes de um design de amostra.

10. Verifique no site em execução

Execute apenas os comandos de build que o package.json do próprio filho alvo declara, então carregue uma página front-end e o canvas do editor e confirme que os ativos estão realmente enfileirados e que a proteção não escondeu um build ausente. A receita de aceitação em references/child-contract.md é a prova em nível de navegador. Marque qualquer coisa que você não testou como não verificado.

Verificações de conclusão

• Pai e filho resolvidos a partir de seus próprios style.css, não assumidos ou codificados.
• Template: nextora presente; Version do cabeçalho igual a <CHILD_PREFIX>_VERSION.
• Text Domain: igual ao slug do filho, e toda string traduzível em PHP/JS do filho usa esse domínio.
• Nenhuma chamada de função do pai e nenhuma leitura de NEXTORA_* no escopo do arquivo do filho.
• Todo registro de enfileiramento/editor-style é protegido por uma verificação de arquivo legível e uma verificação wp_style_is()/wp_script_is() antes de adicionar um handle do pai.
• Nomes base de ativos do filho não colidem com app.css / main.js do pai.
• Registrador de blocos existe apenas se blocks/ existir, usa o diretório de stylesheet, ignora block.json ilegível e registra a categoria do filho.
• references/child-contract.md seguido para estrutura, e quality-gates.md aplicado.
• Front-end e canvas do editor realmente carregam os ativos do filho.

Limites

Este skill é uma instrução em Markdown. Ele não fornece gerador, árvore de tema inicial, gerenciador de pacotes ou instalador, e nunca edita o pai ou o filho de amostra. O scaffold npm run gen do pai é exclusivo do pai; um tema filho é criado escrevendo os arquivos descritos aqui.