miketropi/nextora-child-themes

Nextora child themes

Crea y audita temas hijo de Nextora: el bootstrap, el pipeline de assets y el registrador de bloques hijo. Las convenciones de nivel padre residen en el propio padre; los internos de bloques pertenecen a ../nextora-gutenberg-blocks/SKILL.md, y todo lo relacionado con la paleta, las fuentes o el conmutador del visitante pertenece a ../nextora-design-system/SKILL.md.

Referencias a cargar

Lee estas antes de escribir cualquier archivo, mediante ruta relativa:

• references/child-contract.md — la tabla de sustitución slug/prefix, la receta exacta del directorio, el encabezado, el código de bootstrap y enqueue, el registrador, las convenciones PHP, los defectos observados de la muestra y la receta de aceptación downstream de WordPress. Cárgalo en el paso 3 y no escribas código antes de haberlo hecho.
• source-map.md — de dónde proviene cada regla, con etiquetas de procedencia y los hechos que se suelen citar incorrectamente.
• quality-gates.md — las puertas con las que se mide el hijo terminado. Cárgalo antes de declarar la finalización.

Leer las fuentes locales tiene prioridad sobre leer estos archivos. Cada valor citado en una habilidad o referencia es un ancla, no un hecho actual.

Flujo de trabajo ordenado

1. Resuelve las raíces, no las asumas

En una instalación en vivo, el padre es el directorio de plantillas y el hijo es el directorio de hojas de estilo:

get_template_directory();      // raíz padre
get_stylesheet_directory();    // raíz del tema activo (hijo cuando uno está activo)

Fuera de una instalación, busca un style.css con Theme Name: Nextora para el padre y uno con Template: nextora para el hijo. Si el código fuente del padre falta realmente, dilo y deja de reclamar compatibilidad con Nextora; completa solo el trabajo que no dependa de él. Nunca inventes un ancla ni sustituyas silenciosamente otro tema.

2. Lee la evidencia antes de proponer nada

Del objetivo hijo — o del hijo de muestra, cuando la muestra es lo que se está portando:

1. style.css — el encabezado real: Template, Version, Requires at least, Requires PHP, Tested up to, Text Domain, License.
2. functions.php — orden de carga y lo que el tema requiere en el ámbito del archivo.
3. theme.json — version, slugs de paleta/fuentes, customTemplates, templateParts.
4. package.json y .nvmrc — qué scripts de compilación existen y en qué Node.
5. inc/, blocks/, resources/, assets/ — lo que ya existe.

Del padre: style.css, functions.php, inc/assets/assets.php, blocks/blocks.php. Estos son de los que depende un hijo, por lo que sus nombres de manejador y comportamiento de registrador son el contrato, no la documentación.

3. Corrige la tabla de nombres antes de escribir archivos

Carga references/child-contract.md y completa su tabla de sustitución para el slug solicitado. Cada identificador generado — funciones PHP, constantes, dominio de texto, nombres de bloques, clases CSS, propiedades personalizadas, slugs de patrones, manejadores y nombres base de archivos — proviene de ese único slug. Los nombres propiedad del padre (nextora_*, NEXTORA_*, nextora/*, global-styles, nextora-app, nextora-main, los slugs de paleta y fuentes del padre, los roles --nextora-font-*) nunca se renombran.

4. Coloca solo los directorios que el hijo necesita

La receta está en references/child-contract.md. Requeridos: root style.css, theme.json, functions.php. Agrega inc/, resources/, assets/, templates/, parts/, patterns/ según corresponda, blocks/<block-slug>/ solo cuando el hijo realmente envíe bloques personalizados, y fuentes más archivos de licencia solo cuando se envíen fuentes. No crees andamiaje de características vacío y no clones todo un árbol de temas.

5. Escribe el encabezado, luego la constante de versión, luego el bootstrap

El orden importa: inc/bootstrap/version.php define la única constante <CHILD_PREFIX>_VERSION, el Version: del encabezado style.css debe ser igual, y el pipeline de assets recurre a ella, por lo que la constante debe existir antes de que nada requiera el pipeline. En el encabezado, declara solo mínimos reales — nunca copies el valor Tested up to de otro tema.

6. Escribe functions.php teniendo en cuenta que el hijo va antes que el padre

WordPress carga el functions.php de un hijo antes que el del padre, por lo que nada en el ámbito del archivo puede llamar a una función del padre ni leer una constante NEXTORA_*. Define las propias _DIR/_URI del hijo a partir del directorio de la hoja de estilo, requiere el autoloader de Composer solo cuando sea legible, y requiere los propios archivos del hijo. Cada operación que dependa del padre debe ir dentro de un hook, y debe referirse a los manejadores del padre por su nombre y verificar que estén registrados primero.

7. Conecta el pipeline de assets

Hoja de estilo del hijo en wp_enqueue_scripts prioridad 25, dependiendo de global-styles y nextora-app del padre cuando estén registrados; script del hijo en prioridad 30 dependiendo de nextora-main cuando esté registrado; estilos de canvas del editor en after_setup_theme prioridad 20 a través de add_editor_style(). Protege cada enqueue con una comprobación de archivo legible, y usa nombres base de salida que no colisionen — un assets/css/app.css o assets/js/main.js del hijo puede sombrear el asset del padre. Código completo y tabla de hooks: references/child-contract.md.

8. Agrega el registrador de bloques solo cuando el hijo envíe bloques

WordPress no escanea la carpeta blocks/ de un tema. Registra cada directorio que contenga un block.json legible en init desde get_stylesheet_directory(), agrega la categoría de insertador del hijo, y refleja la coerción de categoría del lado del cliente. Los metadatos de bloques, la UI del editor y los renderizadores están en ../nextora-gutenberg-blocks/SKILL.md. Sin directorio blocks/ significa sin requisito de registrador.

9. Entrega la apariencia al sistema de diseño

Si el hijo debe seguir el cambio de color/fuente preestablecido o del visitante, carga ../nextora-design-system/SKILL.md en la misma sesión y deja que decida los enlaces de roles, las familias de fuentes de theme.json y los archivos preestablecidos. El cuerpo, los encabezados y los botones de un hijo se resuelven a través de las variables de rol de Nextora; nunca se fijan directamente a las fuentes de un diseño de muestra.

10. Verifica contra el sitio en ejecución

Ejecuta solo los comandos de compilación que declara el package.json del hijo objetivo, luego carga una página del front-end y el canvas del editor y confirma que los assets realmente están en cola y que la comprobación no ocultó una compilación faltante. La receta de aceptación en references/child-contract.md es la prueba a nivel de navegador. Marca todo lo que no hayas ejercitado como no verificado.

Comprobaciones de finalización

• Padre e hijo resueltos desde su propio style.css, no asumidos ni codificados.
• Template: nextora presente; el Version del encabezado es igual a <CHILD_PREFIX>_VERSION.
• Text Domain: es igual al slug del hijo, y cada cadena traducible en PHP/JS del hijo usa ese dominio.
• Sin llamada a función padre y sin lectura de NEXTORA_* en el ámbito del archivo del hijo.
• Cada registro de enqueue/editor-style está protegido por una comprobación de archivo legible y una comprobación wp_style_is()/wp_script_is() antes de agregar un manejador padre.
• Los nombres base de assets del hijo no colisionan con app.css / main.js del padre.
• El registrador de bloques existe solo si existe blocks/, usa el directorio de hojas de estilo, omite block.json no legible, y registra la categoría del hijo.
• Se sigue references/child-contract.md para la estructura, y se aplica quality-gates.md.
• El front-end y el canvas del editor realmente cargan los assets del hijo.

Límites

Esta habilidad es instrucción Markdown. No incluye generador, árbol de temas de inicio, gestor de paquetes ni instalador, y nunca edita el padre ni el hijo de muestra. El andamiaje npm run gen del padre es solo para el padre; un tema hijo se crea escribiendo los archivos descritos aquí.