Última actualización: junio de 2026, cubre los temas hijo tanto con Hummingbird (PrestaShop 9, pipeline SCSS) como con Classic (PrestaShop 8). El mecanismo de sobrescritura es idéntico con cualquiera de los dos temas padre.
Este es el momento que convierte a un buen propietario de una tienda PrestaShop en uno frustrado: compraste un tema premium, querías cambiar tres cosas pequeñas, una fuente de encabezado distinta, el color de tu marca en los botones, un ajuste en el diseño de la página de producto, así que abriste /themes/your-theme/templates/catalog/product.tpl y lo editaste. Quedó perfecto. Después, seis semanas más tarde, el autor del tema publicó la versión 2.1 con una corrección de seguridad y una galería de producto más rápida. Hiciste clic en actualizar. Todos los cambios que habías hecho desaparecieron, sobrescritos, irrecuperables salvo que tengas una copia de seguridad con la que puedas comparar diferencias.
Esta es la herida autoinfligida más común en la personalización de PrestaShop, y desde hace años tiene una solución correcta: el tema hijo. Esta guía trata específicamente de eso: qué es realmente un tema hijo de PrestaShop a nivel de sistema de archivos, cómo el orden de resolución de sobrescrituras decide qué archivo gana, cómo crear uno sobre Hummingbird o Classic, y dónde está exactamente la línea entre "usar un tema hijo" y "esto necesita un módulo". Si lo que en realidad quieres es añadir un fragmento de CSS o un script de seguimiento sin bifurcar nada, esa es una tarea más concreta con su propia respuesta, consulta CSS y JavaScript personalizados sin romper las actualizaciones, y volveremos a remitirte a ella en el momento adecuado más abajo.
Qué es realmente un tema hijo (a nivel de archivo)
Un tema hijo es un directorio de tema independiente que declara un parent en su config/theme.yml y hereda todo de él, cada plantilla, cada recurso, cada valor de configuración, al mismo tiempo que te permite sobrescribir archivos individuales. No es una copia del tema padre. Es una capa ligera que se coloca encima. Cualquier archivo que no pongas en el hijo se sirve desde el padre; cualquier archivo que sí pongas en el hijo gana.
El "¿y eso qué importa?" es precisamente el sentido de toda la técnica: como el hijo vive en su propio directorio, una actualización del padre toca el padre y deja tu trabajo intacto. El padre publica la v2.1, tus sobrescrituras siguen ejecutándose encima de la v2.1 y tú pasas la tarde haciendo otra cosa en lugar de reconstruir personalizaciones de memoria. Obtienes las correcciones de errores y las mejoras de velocidad del autor del tema y tu identidad de marca, en vez de tener que elegir entre una cosa y la otra.
El orden de resolución de sobrescrituras: la mecánica que hace que funcione
Para confiar en los temas hijo, necesitas saber exactamente cómo decide PrestaShop qué plantilla renderizar. Cuando un controlador solicita una plantilla, la capa de renderizado del tema busca en un orden fijo y se detiene en la primera coincidencia:
| Prioridad | Ubicación que comprueba | Gana cuando… |
|---|---|---|
| 1 (la más alta) | Tema hijo: /themes/child/templates/... | Has colocado una sobrescritura aquí |
| 2 | Tema padre: /themes/parent/templates/... | El hijo no tiene copia |
| 3 | Plantillas front propias del módulo (para hooks de módulo) | Ningún tema sobrescribe esa plantilla de módulo |
Por eso "copia el único archivo que necesitas y edita la copia" funciona sin romper nada más: PrestaShop resuelve cada plantilla de forma independiente. Sobrescribe product.tpl y el resto de la tienda seguirá renderizándose desde el padre. No hay un interruptor de todo o nada: el hijo solo intercepta las rutas exactas que tú rellenes y delega en el padre todo lo demás. Esa delegación es la ventaja, no una limitación: cuantos menos archivos interceptes, más actualizaciones del padre llegarán directamente a tu tienda.
config/theme.yml: el archivo que declara la relación
Toda la herencia depende de un archivo dentro del directorio config/ de tu tema hijo, config/theme.yml. La clave parent es la que le dice a PrestaShop "sirve todo desde este tema salvo que yo lo sobrescriba". Un hijo mínimo basado en Hummingbird tiene este aspecto:
parent: hummingbird
name: my-store-child
display_name: My Store Child
version: 1.0.0
assets:
use_parent_assets: trueEl valor de parent debe coincidir con el nombre del directorio del tema padre (y el padre debe estar realmente instalado: un hijo no puede heredar de un tema que no existe en el servidor). El name debe ser único y debe coincidir con el nombre del propio directorio de tu hijo. Si te equivocas en cualquiera de los dos, PrestaShop vuelve silenciosamente al padre o se niega a activar el tema; ambas situaciones son más fáciles de diagnosticar cuando sabes que casi siempre se trata de una discrepancia de nombres en este archivo.
Crear un tema hijo paso a paso
Un tema hijo no hace nada hasta que se selecciona como tema activo.
- Crea el directorio, por ejemplo /themes/my-store-child/, con un directorio config/ dentro. No copies en él los archivos del padre. Un tema hijo mínimo puede ser muy pequeño, pero debe incluir un config/theme.yml válido que declare parent, name, display_name y version; con ese archivo en su sitio, se renderiza de forma idéntica al padre.
- Añade config/theme.yml en /themes/my-store-child/config/theme.yml con la referencia al padre mostrada arriba.
- Copia solo los archivos que realmente vayas a cambiar, conservando la ruta relativa. Para personalizar la página de producto, copia /themes/hummingbird/templates/catalog/product.tpl a /themes/my-store-child/templates/catalog/product.tpl y edita únicamente la copia del hijo.
- Actívalo en el back office, en Diseño → Tema & logotipo. Crear el directorio no hace nada por sí solo: hasta que selecciones y uses aquí el tema hijo, la tienda seguirá sirviendo el padre. Esta es la pregunta de soporte número uno de "por qué no aparece mi cambio", y la respuesta casi siempre es la misma: el hijo nunca se activó.
La estructura de directorios del hijo replica exactamente la del padre. El trabajo de una plantilla es vivir en la misma ruta relativa en el hijo que en el padre; esa coincidencia de ruta es lo que permite al resolvedor emparejarlas.
Qué debe ir en un tema hijo y qué no
Plantillas (.tpl): sí, es la herramienta adecuada
Los cambios de marcado estructural, reordenar bloques de la página de producto, añadir una sección de información personalizada, cambiar cómo se renderiza el encabezado. Son exactamente el tipo de trabajo para el que existen las sobrescrituras de plantilla. Copia la plantilla del padre en la ruta correspondiente del hijo y edítala. Sobrescribir una plantilla front de un módulo (un archivo bajo /themes/[theme]/modules/[module]/views/templates/front/[template].tpl) también es una técnica documentada, pero conviene saber que es un punto débil conocido específicamente con los temas hijo: la documentación de temas hijo de PrestaShop no cubre las sobrescrituras de plantillas de módulo, y hay informes abiertos de que se resuelven de forma inconsistente desde un hijo (la caché de plantillas puede servir la copia del padre en su lugar). Si necesitas rediseñar la salida de un módulo y estás usando un tema hijo, pruébalo cuidadosamente en tu versión, o coloca la sobrescritura directamente en el tema activo en lugar de depender de la delegación padre/hijo.
CSS y JavaScript: normalmente no es la capa correcta
Si tu cambio es puramente visual, colores, fuentes, espaciado, ocultar un elemento, sobrescribir una plantilla completa es una forma pesada de hacerlo, y te obliga a volver a fusionar esa plantilla en cada actualización del padre. La opción más ligera y más segura para actualizaciones es una hoja de estilos o un script que cargue después de los recursos del padre, sin duplicar ninguna lógica de plantilla. Es una tarea lo bastante distinta como para tener su propia guía: CSS y JavaScript personalizados en PrestaShop sin romper las actualizaciones. La regla práctica: recurre a una sobrescritura de plantilla solo cuando realmente necesites cambiar el marcado; todo lo que pueda hacerse con CSS, hazlo en CSS.
Lógica de negocio: ninguna de las dos; eso es un módulo
El límite estricto: si tu cambio afecta al comportamiento, cómo se calculan los precios, cómo se elige el envío, qué ocurre durante el proceso de pago. Un tema hijo es el lugar equivocado. Las plantillas muestran datos; no deben procesarlos. En el momento en que te descubras escribiendo lógica PHP real dentro de un archivo .tpl, habrás puesto código de negocio en la capa de presentación, donde no se puede probar, reutilizar ni actualizar de forma limpia. Ese trabajo pertenece a un módulo (o a una clase override), no al tema. Un tema decide cómo se ve el carrito; un módulo decide cómo se comporta el carrito.
Por qué "ligero" es una regla firme, no un detalle bonito
Cada archivo que sobrescribes es un archivo que deja de recibir las correcciones del autor del padre. Si el padre publica en la v2.1 un product.tpl corregido y más accesible, y tú tienes tu propia copia, no recibirás esa corrección: tu copia queda congelada con el marcado de la v2.0 hasta que fusiones manualmente la diferencia. Así que cada sobrescritura conlleva un coste de mantenimiento continuo, y la factura llega en cada actualización del padre.
La disciplina que mantiene bajo ese coste: sobrescribe la unidad más pequeña que resuelva el trabajo. ¿Necesitas añadir una clase a un elemento? Sobrescribe esa plantilla, no su layout padre ni toda la carpeta del catálogo. ¿Necesitas un cambio de color? Eso es CSS, no una plantilla. Un tema hijo con cuatro archivos sobrescritos se actualiza en cinco minutos; un tema hijo con cuarenta se convierte en un proyecto cada vez que el padre cambia.
Sobrevivir a una actualización del tema padre
Cuando el autor del padre publica una nueva versión, la rutina es corta porque la arquitectura hace el trabajo pesado:
- Actualiza el padre. Tu hijo es un directorio independiente, así que nada de lo que escribiste se sobrescribe.
- Compara tus sobrescrituras con las nuevas versiones del padre. Para cada archivo que copiaste, compara tu copia congelada del hijo con la nueva copia del padre usando cualquier herramienta diff. Este es el único lugar donde se paga el coste de mantenimiento, y solo llega a ser tan grande como tu número de sobrescrituras.
- Fusiona cualquier cosa que merezca conservarse, una corrección de error, un campo nuevo, una mejora de accesibilidad que el autor haya añadido a una plantilla que sobrescribes, en tu copia del hijo.
- Prueba las páginas afectadas, concretamente aquellas cuyas plantillas sobrescribes, antes y después.
Los archivos que no sobrescribiste no necesitan nada de esto: se actualizaron automáticamente en el mismo instante en que actualizaste el padre. Esa asimetría es todo el rendimiento de la técnica: haces trabajo de comparación y fusión solo en proporción a lo que personalizaste, y recibes todo lo demás sin esfuerzo.
Hummingbird frente a Classic: qué padre elegir en 2026
Hummingbird es la línea moderna de tema oficial de PrestaShop para la era PS 9, mientras que Classic sigue siendo común y está disponible, sobre todo en PS 8 y tiendas heredadas. El mecanismo de temas hijo es idéntico con independencia del padre, el mismo config/theme.yml, el mismo orden de resolución, pero el padre que elijas cambia la compilación de tus recursos:
| Padre | Herramientas front-end | Elígelo cuando… |
|---|---|---|
| Hummingbird (dirección de la era PS 9) | Build moderno (Webpack, SCSS), marcado más ligero | Estás creando una tienda nueva o quieres una base moderna con un marcado más ligero y rápido. |
| Classic (aún descargable) | Pipeline de recursos más antiguo y sencillo | Estás actualizando un hijo existente basado en Classic y la migración aún no compensa. |
Si estás actualizando desde PrestaShop 8 con un tema hijo basado en Classic, no tienes que migrar a Hummingbird el primer día, Classic sigue disponible como descarga independiente, , pero un proyecto nuevo debería empezar con Hummingbird. Como el pipeline de hojas de estilo de Hummingbird se basa en SCSS, la forma de compilar CSS personalizado difiere de Classic; por tanto, la elección del padre afecta sobre todo a tu flujo de trabajo de estilos, no a la lógica de sobrescritura. Elegir bien el tema base desde el principio es una decisión que merece hacerse de forma deliberada; lo cubrimos en cómo elegir el tema PrestaShop adecuado para tu negocio.
Formas comunes en que la gente todavía se equivoca
- No activaron nunca el hijo. El directorio y config/theme.yml existen, pero la tienda sigue sirviendo el padre porque nadie seleccionó el hijo en Diseño → Tema & logotipo. Siempre es lo primero que hay que comprobar.
- Discrepancia de nombres en config/theme.yml. El name no coincide con el directorio, o parent apunta a un tema que no está instalado. El hijo vuelve silenciosamente al padre o no se puede activar.
- Proliferación de sobrescrituras. Cuarenta plantillas copiadas porque "era más fácil copiar toda la carpeta". Ahora cada una es una fusión manual en cada actualización del padre. Mantenlo ligero desde el diseño.
- Sin control de versiones. Un tema hijo es código personalizado. Debe estar en Git con mensajes de commit reales, de modo que una mala fusión después de actualizar el padre esté a un revert de distancia, no sea un juego de adivinanzas.
- "Solo esta vez" en el padre. No existe solo esta vez. Una edición directa del padre se convierte en veinte, y entonces la actualización que no puedes aplicar es la de seguridad que más necesitabas. Cada cambio, por pequeño que sea, va en el hijo.
La conclusión
Levantar un tema hijo lleva unos diez minutos, un directorio, un config/theme.yml, el nombre del padre escrito correctamente, activarlo en el back office, y convierte cada futura actualización del padre, de un borrado de personalizaciones, en un trámite sin sobresaltos. No es una técnica avanzada ni una buena práctica opcional; en PrestaShop es simplemente la forma correcta de personalizar cualquier tema que no hayas escrito tú mismo. Si ahora mismo estás editando directamente archivos del tema padre, el movimiento es el mismo por pequeños que parezcan tus cambios: crea hoy un tema hijo y traslada tus sobrescrituras a él antes de que la próxima actualización las elimine. Después mantenlo ligero: lleva el estilo puro a CSS y JS que sobreviven a las actualizaciones, lleva el comportamiento a módulos y reserva las sobrescrituras de plantilla para los cambios de marcado que realmente las necesitan.
Preguntas frecuentes
¿Tengo que copiar todo el tema padre dentro de mi hijo?
No, y no deberías hacerlo. Un tema hijo hereda todo del padre por defecto; solo copias los archivos concretos que vas a cambiar, conservando su ruta relativa. Un hijo mínimo puede ser simplemente un directorio con un config/theme.yml válido, y se renderizará de forma idéntica al padre. Cuantos menos archivos copies, más actualizaciones del padre llegarán directamente a tu tienda.
Mi tema hijo se ve idéntico al padre y no aparece nada de lo que he cambiado. ¿Por qué?
Casi siempre es una de estas dos cosas: el hijo nunca se activó en Diseño → Tema & logotipo (crear el directorio no hace nada por sí solo), o hay una discrepancia de nombres en config/theme.yml: el name no coincide con el directorio del hijo, o parent apunta a un tema que no está instalado. Comprueba primero la activación y luego el YAML.
¿Puedo poner mi CSS y JavaScript personalizados en el tema hijo?
Puedes, pero para cambios puramente visuales, colores, fuentes, espaciado, ocultar un elemento, sobrescribir una plantilla completa es pesado y obliga a volver a fusionarla en cada actualización del padre. Una hoja de estilos o un script que cargue después de los recursos del padre es más ligero y no duplica ninguna lógica de plantilla. Reserva las sobrescrituras de plantilla para cambios reales de marcado; todo lo que CSS pueda hacer, hazlo en CSS. Consulta CSS y JavaScript personalizados sin romper las actualizaciones.
¿Mis sobrescrituras sobrevivirán cuando se actualice el tema padre?
Sí. El hijo vive en su propio directorio, así que una actualización del padre nunca lo toca. La tarea que sí debes hacer es comparar cada archivo que sobrescribiste con la nueva versión del padre y fusionar cualquier cambio que merezca la pena (una corrección de error, una mejora de accesibilidad). Ese trabajo es proporcional únicamente al número de archivos que copiaste, que es exactamente por eso que mantener bajo el número de sobrescrituras compensa.
¿Puede un tema hijo sobrescribir la plantilla front-end de un módulo?
Es una técnica documentada, pero es un punto débil conocido específicamente con los temas hijo: hay informes abiertos de que las sobrescrituras de plantillas de módulo se resuelven de forma inconsistente desde un hijo porque la caché de plantillas puede servir la copia del padre en su lugar. Si necesitas rediseñar la salida de un módulo y estás usando un tema hijo, pruébalo cuidadosamente en tu versión exacta, o coloca la sobrescritura directamente en el tema activo en lugar de depender de la delegación padre/hijo.
El cambio que quiero afecta al comportamiento, no a la apariencia. ¿Va en el tema hijo?
No. Si estás cambiando cómo se calculan los precios, cómo se elige el envío o qué ocurre durante el proceso de pago, eso es lógica de negocio y pertenece a un módulo o a una clase override, nunca a un archivo .tpl. Las plantillas muestran datos; no deben procesarlos. Un tema decide cómo se ve el carrito; un módulo decide cómo se comporta el carrito.
¿Debe un tema hijo estar en control de versiones?
Sí. Un tema hijo es código personalizado y debe estar en Git con mensajes de commit reales. La ventaja aparece después de actualizar el padre: si una fusión sale mal, estás a un revert de volver a un estado conocido, en lugar de intentar adivinar qué cambiaste. También hace trivial ver exactamente qué archivos del padre has bifurcado y, por tanto, cuáles tendrás que comparar en la siguiente actualización.
¿Hummingbird y Classic necesitan configuraciones distintas de tema hijo?
El mecanismo de sobrescritura es idéntico, el mismo config/theme.yml, el mismo orden de resolución, , así que la elección del padre no cambia la lógica. Lo que cambia es tu flujo de trabajo de estilos: el pipeline de hojas de estilo de Hummingbird se basa en SCSS y el de Classic es más sencillo, por lo que la forma de compilar CSS personalizado difiere. Elige Hummingbird para proyectos nuevos y Classic cuando mantengas un hijo existente basado en Classic.
Guías relacionadas
Comentarios
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.