Personalizar un tema sin perderlo en la siguiente actualización

Por qué usamos un tema hijo en cada tienda en la que intervenimos

mypresta.rocks funciona sobre mypresta-rocks, un tema hijo de Hummingbird que mantenemos nosotros mismos. Cada tienda de cliente que hemos migrado desde 2013 acaba igual: un tema hijo de lo que el comerciante haya comprado, con nuestras personalizaciones encima. La razón es sencilla. Los autores de temas publican actualizaciones. Los comerciantes compran temas «premium» y luego alguien edita directamente los archivos .tpl del tema padre. Seis meses después el tema se actualiza y todos los ajustes desaparecen.

Un tema hijo mantiene las personalizaciones de plantillas separadas de las actualizaciones del tema padre. El cargador de plantillas de PrestaShop busca primero en el hijo y recurre al padre si no encuentra el archivo. Tú solo distribuyes los archivos que realmente has cambiado. Todo lo demás se hereda.

La media jornada que dedicamos a montar un tema hijo se ha amortizado, con intereses, en cada tienda que hemos actualizado desde 2018. La media jornada que no dedicamos termina con un correo del cliente titulado «la web vuelve a verse mal».

Usa un tema hijo para cambios concretos, colores, ajustes de maquetación, sobrescrituras de plantillas, CSS/JS personalizado, sobrescrituras de plantillas de módulos. Crea un tema personalizado completo solo cuando el diseño sea tan distinto de cualquier opción estándar que la herencia te cueste más de lo que te ahorra.

Para cualquier cosa nueva en PS 9.1+, elige Hummingbird. Es el único tema que PrestaShop desarrolla activamente. Classic sigue funcionando, pero cada nueva función del núcleo llega antes a Hummingbird.

Use theme.yml para declarar la herencia

Un tema hijo empieza con config/theme.yml, no con una copia completa de la carpeta del padre. El tema activo mypresta-rocks declara parent: hummingbird, los metadatos de visualización y la compatibilidad con PrestaShop 9 en un solo lugar, de modo que PrestaShop pueda cargar el tema padre y aplicar únicamente los archivos que tú sobrescribes a propósito.

Los proyectos sobre Classic usan el mismo principio con parent: classic. Mantén esta configuración pequeña, versionada y probada en una tienda de staging antes de activarla en producción; la guía de staging de PrestaShop es el complemento adecuado para esa puesta en marcha.

Mantenga la carpeta del tema hijo centrada

El tema hijo debe contener solo los archivos que tú posees: su configuración, la imagen de previsualización, las sobrescrituras de plantilla seleccionadas, las sobrescrituras de plantillas de módulos seleccionadas y los recursos que tú compilas o registras. Un tema hijo con solo los archivos necesarios es más fácil de auditar que una copia completa del padre, porque cada archivo tiene una razón clara para existir.

La estructura que se muestra aquí proviene del tema del sitio en producción. Las sobrescrituras se sitúan en templates/ y modules/, mientras que los archivos sin cambios permanecen en Hummingbird. Usa la guía de herramientas de desarrollo para que las compilaciones de recursos y los pasos de despliegue sean repetibles.

Sobrescriba bloques de Smarty en lugar de copiar plantillas enteras

La personalización de la página de producto puede extender la plantilla del padre y reemplazar un solo bloque con nombre, como product_header o product_tabs. Así se mantienen disponibles los cambios de Hummingbird de origen, mientras el tema hijo es dueño de esa decisión de maquetación concreta.

Las copias completas de plantillas siguen funcionando, pero aumentan el coste de mantenimiento. Prefiere {extends file='parent:...'} y sobrescrituras precisas de {block}, y después prueba las vistas personalizadas de producto, categoría, finalización de compra y módulos tras cada actualización del tema o de PrestaShop. La guía de hooks y sobrescrituras cubre la misma regla sobre la responsabilidad de mantener las personalizaciones a nivel de módulo.

Abra la página real de ajustes de Tema y Logotipo

Cuando los archivos estén listos, empaqueta el tema hijo como un ZIP listo para el importador. El archivo obligatorio es config/theme.yml; el generador de mypresta.rocks crea un ZIP con ese archivo en la raíz del paquete, y el importador de PrestaShop 9 lo registra correctamente.

En PrestaShop 9, ve a Back Office > Diseño > Tema y Logotipo. Esta es la página de ajustes adecuada para subir el tema, activarlo, gestionar logotipos, diseños de página y la personalización avanzada del tema.

1. Abre Diseño > Tema y Logotipo.
2. Haz clic en Añadir nuevo tema en la cabecera de la página.
3. Mantén instalado el tema padre existente; el tema hijo hereda de él.

Importe el ZIP del tema hijo desde su ordenador

En la página Importar tema, usa Importar desde su ordenador y selecciona el archivo ZIP que contiene los archivos del tema hijo. PrestaShop lee los metadatos del tema desde config/theme.yml y registra el tema una vez que la subida se completa con éxito.

1. Selecciona el ZIP del tema hijo en el campo Archivo Zip.
2. Haz clic en Guardar para subirlo.
3. Vuelve a Tema y Logotipo, elige Usar este tema, borra la caché y verifica el escaparate.

Para tiendas en producción, sube y prueba el tema primero en staging y, después, sigue los mismos pasos de activación durante una ventana de mantenimiento tranquila.

Genere en línea un ZIP de tema hijo de Hummingbird

El Child Theme Generator es una herramienta pública en mypresta.rocks, por lo que no hay ningún módulo generador que instalar en tu propia tienda. Abre la página del generador, elige Hummingbird (PrestaShop 9), introduce el nombre del tema hijo, establece la versión de PrestaShop en 9.x e incluye los archivos de inicio que quieras en el ZIP.

Para la prueba sobre PS9 aquí, el generador descargó hummingbirdchild.zip con config/theme.yml, custom.css, custom.js, sobrescrituras opcionales de Smarty, imagen de previsualización, README y archivos opcionales de compilación SCSS.

Verifique el tema hijo generado tras la importación

Después de subir el ZIP generado a través de Importar tema, vuelve a Diseño > Tema y Logotipo. El tema generado debería aparecer junto a los temas padre, con su nombre de visualización, versión, autor e imagen de previsualización.

La importación de demostración sobre PS9 que se muestra aquí creó Hummingbird Child versión 1.0.0 de mypresta.rocks. En este punto puedes activarlo con Usar este tema, borrar la caché y revisar el escaparate antes de usarlo en producción.

Cómo es realmente un tema hijo en disco

Un tema hijo vive junto a su padre dentro de /themes/. Este ejemplo contiene la configuración obligatoria y una imagen de previsualización opcional:

themes/my-child-theme/
  config/
    theme.yml             <-- obligatorio: parent + name + version
  preview.png <-- opcional: previsualización 200x200 mostrada en el BO

En cuanto empiezas a personalizar, el directorio refleja la estructura del padre, pero solo contiene los archivos que has cambiado:

themes/my-child-theme/
  config/theme.yml
  assets/
    css/custom.css
    js/custom.js
  templates/
    catalog/product.tpl
    _partials/header.tpl
  modules/
    ps_featuredproducts/views/templates/hook/
      ps_featuredproducts.tpl
  translations/en-US/Shop/Theme.xlf
  preview.png

La disciplina que importa: añade un archivo solo cuando realmente lo estés cambiando. Cada archivo que copias es un archivo que ahora posees y tienes que mantener. Un tema hijo vacío que lo hereda todo está más sano que uno repleto de copias sin cambios de plantillas del padre.

theme.yml: el único archivo verdaderamente obligatorio

La línea crítica es parent: classic o parent: hummingbird. Eso es lo que conecta la herencia. Si te equivocas, PrestaShop trata tu hijo como un tema independiente sin padre al que recurrir, y la mitad del sitio se renderiza en blanco.

parent: classic
name: my-child-theme
display_name: My Child Theme
version: 1.0.0
author:
  name: "Your Name"
  email: "you@example.com"
  url: "https://yoursite.com"

meta:
  compatibility:
    from: 1.7.0.0
    to: ~

assets:
  use_parent_assets: true

theme_settings:
  default_layout: layout-full-width
  layouts:
    category: layout-left-column

Crear un tema hijo para Classic

Classic es lo que ejecutan la mayoría de las tiendas sobre PS 1.7 y 8.x. Cuatro pasos y estás en marcha:

# 1. Crea el directorio
mkdir -p themes/my-classic-child/config

# 2. Escribe config/theme.yml con parent: classic (ver arriba)

# 3. Coloca preview.png (200x200): cualquier PNG sirve en este punto

# 4. Activa desde Back Office > Diseño > Tema y Logotipo
#    O por CLI: php bin/console prestashop:theme:enable my-classic-child

Con use_parent_assets: true y sin ninguna sobrescritura, tu sitio se renderiza de forma idéntica a Classic. Ese es el punto de partida seguro, confirma que el tema hijo vacío funciona y, después, añade sobrescrituras una a una.

Crear un tema hijo para Hummingbird

Hummingbird es otra historia. Bootstrap 5.3 con propiedades personalizadas de CSS, CSS Layers (@layer) para el control de la cascada, TypeScript compilado mediante Webpack 5 y nomenclatura estilo BEM (.product__name, .product__description-short). La configuración es la misma que en Classic, escribe theme.yml con parent: hummingbird y un rango de compatibilidad que empiece en 9.1.0. La parte interesante es cómo se personalizan los recursos.

El sistema de CSS Layers, y por qué deja de pelear con la especificidad

Hummingbird declara su orden de capas en SCSS:

@layer vendors, bs-base, bs-components, bs-custom-components,
       ps-base, ps-components, ps-pages, ps-modules, utilities;

Los estilos de capas posteriores ganan sobre los de capas anteriores, independientemente de la especificidad del selector. Esta es la parte que sorprende a quienes vienen de Classic. Ya no necesitas !important. No necesitas un selector más largo. Pon tus reglas en la capa correcta y ganan.

@layer ps-components {
  .product__name {
    font-family: 'Your Custom Font', sans-serif;
  }
}

@layer ps-pages {
  .page--category .product-miniature {
    border: 1px solid #eee;
    border-radius: 8px;
  }
}

Compilación de SCSS

Si quieres SCSS en lugar de CSS plano, añade un paso de compilación. Un package.json con sass como dependencia de desarrollo, scripts para build:css (sass src/scss/custom.scss assets/css/custom.css --style=compressed) y watch:css. Después, npm install && npm run build:css.

Dart Sass a veces antepone una marca BOM UTF-8 al CSS compilado. Los navegadores ignoran entonces silenciosamente la primera regla, y tú pasas media hora preguntándote por qué tu reset no se aplica. Elimínala: sed -i '1s/^\xEF\xBB\xBF//' assets/css/custom.css. Lo hemos añadido a cada pipeline de compilación de Sass que ejecutamos.

Sobrescrituras de plantillas

Aquí es donde los temas hijo se ganan su sitio. La implementación de Smarty en PrestaShop admite un modelo de herencia limpio, y es así como cada una de nuestras tiendas aplica los ajustes de maquetación.

Cómo elige PrestaShop una plantilla

1. Tema hijo: themes/my-child/templates/
2. Tema padre: themes/hummingbird/templates/

La forma perezosa: copiar el archivo entero

Copia la plantilla del padre en el hijo y, después, edítala. Tu versión reemplaza la del padre por completo:

cp themes/hummingbird/templates/catalog/product.tpl \
   themes/my-child/templates/catalog/product.tpl

El precio que pagas: ahora posees el archivo entero. Cuando PrestaShop envíe una corrección a esa plantilla en la siguiente versión menor (y lo hacen), tu copia no la recibe. Usamos este enfoque para plantillas que realmente hemos reescrito de principio a fin, y casi nunca en otros casos.

La forma correcta: {extends} y sobrescribir solo los bloques que le importan

{extends file='parent:catalog/listing/category.tpl'}

{block name='product_list_header'}
  <div class="custom-category-header">
    <h1>{$category.name}</h1>
    <p>{$listing.pagination.total_items} products</p>
  </div>
{/block}

El prefijo parent: importa. Si lo omites, Smarty resuelve el archivo de vuelta a tu propia plantilla hija, que se extiende a sí misma, bucle infinito, tiempo de espera agotado de PHP. Hemos visto esto en cada proyecto Smarty que escala, se escribe un fragmento, se olvida el prefijo y se ve morir la petición.

Añadir al final y al principio en lugar de reemplazar

No siempre quieres reemplazar un bloque, a veces quieres añadirle contenido. Smarty tiene modificadores para eso:

{extends file='parent:catalog/product.tpl'}

{block name='product_description' append}
  <div class="shipping-notice">Free shipping on orders over $50</div>
{/block}

{block name='product_prices' prepend}
  <span class="price-badge">Best Price</span>
{/block}

Los bloques que expone la página de producto de Hummingbird

Los puntos de sobrescritura en el catalog/product.tpl de Hummingbird:

{block name='product_cover_thumbnails'}: imágenes del producto
{block name='product_header'}: nombre del producto (h1)
{block name='product_manufacturer'}: enlace de la marca
{block name='product_prices'}: visualización del precio
{block name='product_description_short'}: descripción corta
{block name='product_variants'}: selectores de combinación
{block name='product_add_to_cart'}: botón de añadir al carrito
{block name='product_tabs'}: acordeón de descripción/detalles
{block name='product_accessories'}: productos relacionados

Para cualquier otra página, el truco es leer la plantilla del padre. Cada {block name='...'} del padre es un punto de sobrescritura al que puedes apuntar desde el hijo.

Personalización de CSS

La convención de custom.css, y por qué Classic y Hummingbird no la respetan

Algunos temas comerciales populares (Warehouse, Flavor y varios temas de marketplaces) cargan automáticamente custom.css y custom.js si esos archivos existen en el directorio assets/ del tema. El assets.yml del tema los registra con alta prioridad, se cargan los últimos y nunca los tocan las actualizaciones del tema porque no forman parte de los archivos de distribución del tema. Es el patrón más limpio que tiene PrestaShop para «solo quiero añadir unas pocas reglas de CSS sin poseer un tema hijo».

themes/your-theme/
  assets/
    css/
      theme.css          <-- hoja de estilos principal del tema (actualizada por el tema)
      custom.css <-- tus sobrescrituras (nunca tocadas por las actualizaciones)
    js/
      theme.js           <-- JS principal del tema (actualizado por el tema)
      custom.js <-- tus scripts (nunca tocados por las actualizaciones)

Cuándo recurrir a cada uno:

• custom.css: cambios solo de CSS: colores, fuentes, espaciado, ocultar elementos, maquetación menor. Sin cambios de HTML. Sin JS. El ciclo de iteración más rápido posible.
• Tema hijo: todo lo que cambie la estructura HTML, añada JavaScript, sobrescriba la plantilla de un módulo o reestructure una maquetación. Un tema hijo puede incluir su propio custom.css encima.

Classic y Hummingbird no cargan automáticamente custom.css. Si estás en un tema predeterminado de PrestaShop, necesitas o bien un tema hijo con el archivo registrado en theme.yml, o bien un módulo como Custom CSS & JavaScript que te permita inyectar código desde el back office. Usamos lo segundo en tiendas de cliente pequeñas, donde el comerciante no va a tocar SSH y solo necesitamos aplicar tres ajustes de color.

CCC te dará problemas. Cuando Combinar, Comprimir, Cachear está activado, tu custom.css se fusiona en un archivo combinado con nombre de hash. Edita custom.css y no cambia nada en el front hasta que subas la versión del CSS en los ajustes de Rendimiento o borres themes/*/assets/cache/. Cada ticket de soporte de «¡pero si cambié el CSS!» que hemos contestado empieza aquí.

Registrar CSS a través de theme.yml

assets:
  use_parent_assets: true
  css:
    all:
      - id: my-child-custom-style
        path: assets/css/custom.css
        media: all
        priority: 200

Los valores de priority más altos se cargan más tarde, lo que te da una autoridad de sobrescritura natural sobre los estilos del padre. En Hummingbird, prefiere @layer antes que la gimnasia con prioridades. Es la razón de ser del sistema de capas. En Classic, iguala la profundidad de selector del padre y evita !important. En cuanto empiezas a salpicar !important, estás en una guerra que solo puede escalar.

Recolorear una tienda Hummingbird en tres líneas

:root {
  --bs-primary: #2563eb;
  --bs-primary-rgb: 37, 99, 235;
  --bs-body-font-family: 'Inter', system-ui, sans-serif;
}

Eso es todo. El enfoque de propiedades personalizadas de Bootstrap 5 significa que los cambios a nivel de rebranding no necesitan recompilar SCSS ni una sola vez.

Personalización de JavaScript

Registrar JS a través de theme.yml

assets:
  use_parent_assets: true
  js:
    all:
      - id: my-child-custom-js
        path: assets/js/custom.js
        priority: 200

Cambia all por el nombre de una página para acotar el script: product, category, cart, checkout, cms, index (página de inicio) o cualquier nombre de controlador. Cargamos la mayoría de los scripts de analítica y seguimiento de forma global, y la mayoría de las mejoras por página de forma acotada. No hay razón para que una barra fija de la página del carrito tenga que analizarse en cada impresión de producto.

El bus de eventos de JS de PrestaShop

El front office expone un pequeño bus de eventos en window.prestashop. Escucha los eventos que te interesan en lugar de sondear el DOM:

prestashop.on('updatedProduct', function(event) { /* combinación cambiada */ });
prestashop.on('updateCart', function(event) { /* carrito actualizado */ });

jQuery: sigue cargado, sigue sin quitarlo

Classic carga jQuery de forma global. Hummingbird también carga jQuery 3.x para la compatibilidad con módulos, aunque el tema en sí es TypeScript. Para tu propio código en Hummingbird, el JS puro da mejor rendimiento, Bootstrap 5 abandonó su dependencia de jQuery y el tema lo sigue. Pero si quitas jQuery para «limpiar», se rompe todo módulo de terceros que aún use $(...). Tenemos una regla: nunca deshabilitar jQuery en una tienda en producción sin auditar antes cada módulo activo.

Sobrescrituras de plantillas de módulos

Las plantillas de cualquier módulo pueden sobrescribirse desde el tema reflejando la estructura de directorios del módulo bajo themes/your-child/modules/. Esta es una de las mejores funciones de PrestaShop y la forma más limpia de reestilizar un módulo de terceros sin hacerle un fork.

Orden de resolución

1. Tema hijo: themes/my-child/modules/module_name/views/templates/...
2. Tema padre: themes/parent/modules/module_name/views/templates/...
3. El propio módulo: modules/module_name/views/templates/...

La mecánica

Localiza la plantilla del módulo (p. ej. modules/ps_featuredproducts/views/templates/hook/ps_featuredproducts.tpl), cópiala a la ruta equivalente bajo el directorio modules/ de tu tema y edítala. El módulo se actualiza libremente sin tocar tu versión.

Las sobrescrituras del tema ganan de forma absoluta. Si un módulo parchea su plantilla para corregir un fallo de XSS y tu tema tiene una copia de hace seis meses, la versión antigua sigue renderizándose, XSS incluido. Compara con diff tus sobrescrituras de módulos frente a las versiones actuales de los módulos al menos una vez por trimestre. Lo hacemos como parte del mantenimiento trimestral de cada tienda.

Traducciones dentro de los temas hijo

Orden de búsqueda de traducciones:

1. Traducciones de la base de datos (Back Office > Internacional > Traducciones)
2. Directorio translations/ del tema hijo
3. Directorio translations/ del tema padre
4. Traducciones del módulo
5. Traducciones del núcleo

Para cambios puntuales de cadenas, usa simplemente el editor de traducciones del Back Office. Para cualquier cosa que quieras tener en Git, crea archivos XLIFF en themes/my-child/translations/en-US/Shop/Theme/Global.xlf:

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
  <file original="shop-theme-global" source-language="en-US"
        target-language="en-US" datatype="plaintext">
    <body>
      <trans-unit id="add_to_cart" approved="yes">
        <source>Add to cart</source>
        <target>Add to bag</target>
      </trans-unit>
    </body>
  </file>
</xliff>

Las tiendas multilingües tienen un directorio por configuración regional: translations/fr-FR/, translations/de-DE/. Borra la caché tras los cambios, las traducciones se cachean de forma agresiva: php bin/console cache:clear.

Personalizaciones que acabamos haciendo en la mayoría de las tiendas

Cabecera reestructurada

{extends file='parent:_partials/header.tpl'}

{block name='header_nav'}
  <nav class="custom-header-nav container">
    <div class="row align-items-center">
      <div class="col-md-3">{hook h='displayNav1'}</div>
      <div class="col-md-6 text-center">
        <a href="{$urls.base_url}"><img src="{$shop.logo}" alt="{$shop.name}"></a>
      </div>
      <div class="col-md-3 text-end">{hook h='displayNav2'}</div>
    </div>
  </nav>
{/block}

Fuentes personalizadas hechas como es debido

Archivos WOFF2 en assets/fonts/, referenciados desde el CSS:

@font-face {
  font-family: 'CustomFont';
  src: url('../fonts/CustomFont-Regular.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}
body { font-family: 'CustomFont', system-ui, sans-serif; }

Establece siempre font-display: swap. Sin él, el navegador oculta el texto hasta que se carga la fuente y tu Largest Contentful Paint se penaliza en los Core Web Vitals. Precarga la fuente crítica: <link rel="preload" as="font" type="font/woff2" crossorigin>. Hemos visto las puntuaciones de LCP subir 30 puntos en tiendas que hicieron solo esta corrección.

Sacar la descripción completa fuera de las pestañas

{extends file='parent:catalog/product.tpl'}

{block name='product_description_short'}
  <div class="product__description-short">{$product.description_short nofilter}</div>
  {if $product.description}
    <div class="product__description-full mt-3">{$product.description nofilter}</div>
  {/if}
{/block}

{block name='product_description'}{/block} {* eliminado de las pestañas *}

Qué cambió en los temas de PS 9

• Hummingbird es el predeterminado en las instalaciones nuevas de PS 9.1. Las tiendas actualizadas conservan su tema anterior. Classic sigue distribuyéndose y funcionando, pero las nuevas funciones llegan antes a Hummingbird.
• Smarty se mantiene para el front office. Twig se usa en el admin (cada vez más, aunque la migración no está completa al 100%). Tus sobrescrituras de {extends} y {block} del front office siguen funcionando sin cambios.
• Bootstrap 5.3 en lugar de Bootstrap 4. Si estás migrando un hijo de Classic a Hummingbird, la guía de migración de Bootstrap es la página que querrás tener abierta.
• CSS Layers cambian cómo se resuelve la especificidad. Deja de recurrir a !important.
• WebP es el formato de imagen predeterminado. Nueva clave framework en theme.yml: bootstrap-v5.3.3.
• Algunos globales heredados de JS han desaparecido. Todo lo que se enganchaba al antiguo JS de Classic necesitará pruebas.

Twig puede acabar llegando al front office en una futura versión mayor. Mantén tus sobrescrituras al mínimo y tus nombres de bloque sensatos y tendrás una transición más fácil cuando ocurra.

Depurar problemas del tema

Primer movimiento, siempre: php bin/console cache:clear. Para desarrollo, pon la caché de plantillas en «Forzar compilación» y desactiva CCC en Parámetros Avanzados > Rendimiento. Cualquier otra cosa y estarás depurando archivos cacheados, no tu código.

Si cambias una plantilla y no ves el cambio, la caché te está mintiendo. No sigas retocando la plantilla, borra la caché, fuerza la compilación y vuelve a mirar. La mitad de los tickets de «mi sobrescritura no funciona» que recibimos empiezan como una caché de compilación olvidada.

Añade ?SMARTY_DEBUG a cualquier URL del front para una ventana emergente que muestra cada plantilla cargada y cada variable en el ámbito. Establece _PS_SMARTY_FORCE_COMPILE_ y _PS_SMARTY_CONSOLE_ a 1 en config/defines.inc.php para mantenerla activa entre recargas.

Los errores que realmente se encontrará

Si la caché está realmente atascada, elimina a mano var/cache/prod/smarty/compile/ y var/cache/prod/smarty/cache/. Lo hacemos más a menudo de lo que nos gustaría admitir.

Actualizar: donde el tema hijo por fin se amortiza

Cuando el tema padre se actualiza, esto es lo que le pasa a cada archivo:

• Solo en el padre: se actualiza con normalidad, el hijo hereda automáticamente la nueva versión.
• Sobrescrito en el hijo: la versión de tu hijo sigue ganando. La actualización del padre es invisible para tu tienda.
• Archivos exclusivos del hijo: totalmente intactos.

Antes de apretar el gatillo en una actualización del padre: haz copia de seguridad de todo, lista tus sobrescrituras (find themes/my-child/templates -name "*.tpl"), ejecuta la actualización en staging (tenemos un procedimiento para eso en la guía de desarrollo local), compara con diff las plantillas del padre que cambiaron frente a tus sobrescrituras y, después, prueba cada página personalizada en dispositivos reales. Sáltate cualquiera de estos pasos y te enterarás a las 8 de la mañana del lunes equivocado.

Las sobrescrituras dirigidas con {extends} superan a las copias de archivo completo, siempre. Cuando el padre añade un bloque nuevo, tu hijo con {extends} lo hereda automáticamente. Una copia de archivo completo lo pierde por completo, y te enteras solo cuando un cliente se queja de que la nueva función no está ahí.

Lista de comprobación previa al lanzamiento

Configuración: theme.yml tiene el parent: correcto y un name: en minúsculas y sin espacios. use_parent_assets: true está establecido. Si se incluye, preview.png se muestra correctamente. El rango de compatibilidad coincide con la versión de PS sobre la que distribuyes.

Plantillas: Cada sobrescritura usa {extends file='parent:...'} donde puede. Los nombres de bloque coinciden con el padre carácter por carácter. var/logs/ está limpio. Las sobrescrituras de módulos se han comparado con diff frente a las versiones actuales de los módulos. nofilter está en cada variable HTML que no necesita volver a escaparse.

Recursos: El CSS personalizado se carga después del del padre (priority alta o la @layer correcta). Nada de !important salpicado por ahí. Las fuentes son WOFF2 con font-display: swap. Sin errores de consola de JS. CCC se ha activado y el sitio sigue renderizándose.

Pruebas: Escritorio en Chrome, Firefox, Safari, Edge. Móvil en iOS Safari y Android Chrome. Cada punto de ruptura responsive. En dispositivos táctiles: página de inicio, categorías, producto, carrito, finalización de compra, cuenta de cliente, CMS, búsqueda, 404.

Mantenimiento: El tema hijo está en Git. Las sobrescrituras están documentadas en algún lugar donde una persona pueda encontrarlas. El proceso de compilación está escrito (ve nuestra guía de herramientas de desarrollo). El equipo sabe que no debe editar los archivos del padre.

Lecturas relacionadas

• Cómo migrar a PrestaShop 9: guía completa de actualización: cambios de tema en el salto a PS 9
• Hooks y sobrescrituras de PrestaShop: guía de referencia para desarrolladores: cuándo recurrir a un hook en lugar de a una sobrescritura del tema
• SEO de PrestaShop: URLs, Schema, Sitemaps y Core Web Vitals: personalizaciones de tema compatibles con SEO
• Temas hijo en PrestaShop: por qué nunca debe editar el tema padre
• Cómo elegir el tema de PrestaShop adecuado para su negocio

Módulos relacionados

• HTML Blocks: añade bloques de contenido configurables en lugar de editar plantillas
• Mega Menu: crea una cabecera/navegación avanzada sin hacks en el tema
• Product Extra Info Tabs: añade pestañas a la página de producto sin sobrescribir plantillas

Preguntas relacionadas

• Los cambios CSS que hago no aparecen en el front end.
• La traducción del módulo no funciona, el texto sigue en inglés.
• Override no funciona, mi plantilla personalizada se ignora.
• Temas PrestaShop gratuitos vs premium: lo que realmente obtienes
• ¿Qué comprueba la revisión de idoneidad de temas?
• ¿Pueden revisar un tema que ya he comprado o sobre el que ya he construido?