Si mantienes un sitio en WordPress durante años, tarde o temprano te enfrentas a un problema clásico: has personalizado el CSS, quizás también el header.php, y cada actualización del tema te obliga a repetir esos cambios desde cero. La solución habitual es un tema hijo (o child theme), y en este artículo repaso el proceso completo que he seguido en Indaga.net, incluyendo las dudas que me han surgido por el camino (hacía mucho tiempo que no hacía esto…).
Comentar que todo el proceso sirve para cualquier tema o theme de WordPress, no solo para Twenty Seventeen.
¿Qué es un tema hijo y por qué usarlo?
Un tema hijo es un tema que hereda toda la funcionalidad y las plantillas de otro tema, el «padre», pero permite sobreescribir archivos concretos sin tocar el original. La gran ventaja es que las actualizaciones del tema padre no borran tus personalizaciones, siempre que estén en el sitio correcto.
En mi caso, el tema padre es Twenty Seventeen, y el objetivo principal era mantener un CSS personalizado sin perderlo cada vez que WordPress actualiza el tema.
Estructura mínima necesaria
Contra lo que podría parecer, no hace falta replicar toda la estructura de carpetas del tema padre. Con dos archivos en la raíz ya es suficiente para tener un tema hijo funcional:
wp-content/themes/tema-hijo/
├── style.css
└── functions.phpEl stylee.css necesita una cabecera específica que le indica a WordPress cuál es el tema padre:
/*
Theme Name: Indaga Child
Template: twentyseventeen
Version: 1.0.0
*/Y el functions.php se encarga de encolar primero el CSS del padre y después el propio, para que las reglas personalizadas puedan sobreescribir las originales:
<?php
add_action( 'wp_enqueue_scripts', 'indaga_child_enqueue_styles' );
function indaga_child_enqueue_styles() {
wp_enqueue_style( 'twentyseventeen-parent-style', get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'indaga-child-style',
get_stylesheet_directory_uri() . '/style.css',
array( 'twentyseventeen-parent-style' ),
wp_get_theme()->get('Version')
);
}Con esto ya se puede activar el tema hijo desde Apariencia → Temas.
Carpetas opcionales
Solo tiene sentido crearlas si de verdad se van a usar:
- /assets/css/: para separar el CSS en varios archivos en lugar de amontonarlo todo en style.css.
- /assets/js/: si se añade JavaScript propio.
- /inc/: para dividir functions.php en varios archivos PHP si crece mucho.
- /template-parts/: solo si se van a sobreescribir plantillas concretas del padre (la ruta y el nombre de archivo deben coincidir exactamente con los del tema original para que WordPress detecte la sustitución).
- /languages/: si se traducen cadenas propias del tema hijo.
La duda del «AdSense desaparecido»
Al activar el tema hijo, me surgió una duda: si tuviera código de AdSense no aparecía en el sitio, y mi primer instinto fue pensar que si lo tuviera, tendría que copiar el header.php del padre al hijo para «recuperarlo».
Aquí está el matiz importante: WordPress hereda automáticamente los archivos de plantilla que el hijo no tiene. Si el tema hijo no incluye su propio header.php, WordPress usa sin más el header.php del tema padre, con todo su contenido, incluyendo cualquier código insertado directamente en él. Así que, en teoría, no debería haber ninguna pérdida solo por activar el hijo.
Antes de tocar nada, conviene descartar por orden:
- Caché activa. Con un plugin de caché como WP Fastest Cache, es fácil estar viendo una versión antigua de la página. Vaciar la caché y probar en incógnito resuelve muchos falsos problemas de este tipo
- Que el tema activo sea realmente el hijo
- Ver el código fuente de la página (Ctrl+U) para comprobar si el fragmento está presente en el HTML aunque no se vea (podría ser un bloqueador de anuncios del propio navegador, no un problema de plantilla)
En este caso concreto, el sitio todavía estaba en fase de revisión y por eso no se mostraban anuncios: no era un problema del tema hijo en absoluto.
¿Qué pasa si actualizo el tema padre?
Esta es probablemente la pregunta más importante de todo el proceso, y la respuesta no es igual para todos los archivos:
- functions.php del tema hijo: totalmente a salvo. Es un archivo propio, en su propia carpeta, y una actualización del tema padre jamás lo toca.
- header.php / footer.php editados directamente en el tema padre: aquí está el riesgo real. Si el código de AdSense (o cualquier otra personalización) se editó directamente en el
header.phpde Twenty Seventeen, una actualización del tema sustituye ese archivo por el original del repositorio, y esos cambios se pierden.
La solución es sencilla: copiar el header.php (y cualquier otro archivo modificado directamente en el padre) a la carpeta del tema hijo, manteniendo el mismo nombre. A partir de ese momento, la herencia de plantillas hace que WordPress use la versión del hijo en lugar de la del padre, y esos archivos quedan protegidos frente a futuras actualizaciones.
El detalle estético: la miniatura en blanco
Un último detalle menor pero visible: al crear el tema hijo desde cero, la miniatura que aparece en Apariencia → Temas queda en blanco. Esto es simplemente porque falta el archivo screenshot.png en la raíz del tema; WordPress no lo genera automáticamente.
Basta con subir una imagen (idealmente en proporción 4:3, por ejemplo 1200×900 px) con ese nombre exacto a la raíz del tema hijo. No requiere ninguna declaración adicional en style.css ni en functions.php; WordPress la detecta solo por estar ahí.
Así es como queda el mío:
Resumen del proceso
- Crear style.css y functions.php en wp-content/themes/tema-hijo/ (en mi caso wp-content/themes/indaga/ al haber llamado así al tema hijo o child theme.
- Activar el tema hijo desde el escritorio de WordPress.
- Antes de dar por buena cualquier «desaparición» de contenido, descartar caché y confirmar el tema activo.
- Copiar a la carpeta del hijo cualquier archivo de plantilla (header.php, footer.php, etc.) que se haya editado directamente en el tema padre, para blindarlo frente a actualizaciones.
- Añadir un screenshot.png para que la miniatura del tema deje de aparecer en blanco.
Con estos pasos, el sitio queda preparado para recibir actualizaciones de Twenty Seventeen sin sobresaltos, manteniendo intactas todas las personalizaciones (que son bastantes…).
