Ein Theme anpassen, ohne es beim nächsten Update zu verlieren

Warum wir auf jedem Shop, den wir betreuen, ein Child-Theme einsetzen

mypresta.rocks selbst läuft auf mypresta-rocks, einem Child-Theme von Hummingbird, das wir selbst pflegen. Jeder Kundenshop, den wir seit 2013 migriert haben, endet auf dieselbe Weise: ein Child-Theme dessen, was der Händler gekauft hat, mit unseren Overrides obendrauf. Der Grund ist einfach. Theme-Autoren veröffentlichen Updates. Händler kaufen „Premium“-Themes und dann bearbeitet jemand die übergeordneten .tpl-Dateien direkt. Sechs Monate später wird das Theme aktualisiert und jede Anpassung ist weg.

Ein Child-Theme hält Template-Anpassungen von Updates des Parent-Themes getrennt. Der Template-Loader von PrestaShop schaut zuerst im Child nach und fällt auf das Parent zurück, wenn er die Datei dort nicht findet. Sie liefern nur die Dateien aus, die Sie tatsächlich geändert haben. Alles andere wird vererbt.

Der halbe Tag, den wir für das Einrichten eines Child-Themes aufwenden, hat sich auf jedem Shop, den wir seit 2018 aktualisiert haben, mit Zinsen ausgezahlt. Der halbe Tag, den wir nicht aufwenden, endet mit einer Kunden-E-Mail mit dem Betreff „die Seite sieht wieder falsch aus“.

Verwenden Sie ein Child-Theme für gezielte Änderungen, Farben, Layout-Anpassungen, Template-Overrides, eigenes CSS/JS, Modul-Template-Overrides. Bauen Sie nur dann ein vollständig eigenes Theme, wenn das Design so stark von allem Standardmäßigen abweicht, dass die Vererbung Sie mehr kosten würde, als sie einspart.

Für alles Neue auf PS 9.1+ wählen Sie Hummingbird. Es ist das einzige Theme, das PrestaShop aktiv weiterentwickelt. Classic funktioniert weiterhin, aber jede neue Kernfunktion erscheint zuerst auf Hummingbird.

Verwenden Sie theme.yml, um die Vererbung zu deklarieren

Ein Child-Theme beginnt mit config/theme.yml, nicht mit einer vollständigen Kopie des Parent-Ordners. Das aktive Theme mypresta-rocks deklariert parent: hummingbird, Anzeige-Metadaten und die Kompatibilität mit PrestaShop 9 an einer Stelle, sodass PrestaShop das Parent-Theme laden und nur die Dateien anwenden kann, die Sie bewusst überschreiben.

Classic-Projekte nutzen dasselbe Prinzip mit parent: classic. Halten Sie diese Konfiguration klein, versioniert und getestet auf einem Staging-Shop, bevor Sie sie in der Produktion aktivieren; der PrestaShop-Staging-Leitfaden ist der richtige Begleiter für dieses Rollout.

Halten Sie den Child-Theme-Ordner fokussiert

Das Child-Theme sollte nur Dateien enthalten, die Ihnen gehören: seine Konfiguration, das Vorschaubild, ausgewählte Template-Overrides, ausgewählte Modul-Template-Overrides sowie Assets, die Sie kompilieren oder registrieren. Ein fokussiertes Child-Theme lässt sich leichter prüfen als eine vollständige Parent-Kopie, weil jede Datei einen klaren Grund hat, zu existieren.

Die hier gezeigte Struktur stammt vom Theme der Live-Site. Overrides liegen unter templates/ und modules/, während unveränderte Dateien in Hummingbird verbleiben. Nutzen Sie den Leitfaden zu den Entwicklungswerkzeugen, um Asset-Builds und Deployment-Schritte wiederholbar zu halten.

Überschreiben Sie Smarty-Blöcke, statt ganze Templates zu kopieren

Die Anpassung der Produktseite kann das Parent-Template erweitern und einen einzelnen benannten Block ersetzen, etwa product_header oder product_tabs. So bleiben Upstream-Änderungen von Hummingbird verfügbar, während das Child-Theme die konkrete Layout-Entscheidung besitzt.

Vollständige Template-Kopien funktionieren weiterhin, erhöhen aber die Wartungskosten. Bevorzugen Sie {extends file='parent:...'} und präzise {block}-Overrides und testen Sie dann nach jedem Theme- oder PrestaShop-Update die angepassten Produkt-, Kategorie-, Checkout- und Modul-Oberflächen. Der Leitfaden zu Hooks und Overrides behandelt dieselbe Regel zur Verantwortung für Anpassungen auf Modulebene.

Öffnen Sie die echte Seite „Theme & Logo“-Einstellungen

Sobald die Dateien bereit sind, packen Sie das Child-Theme als importfähiges ZIP. Die erforderliche Datei ist config/theme.yml; der Generator von mypresta.rocks erstellt ein ZIP mit dieser Datei im Archiv-Wurzelverzeichnis, und der Importer von PrestaShop 9 registriert es korrekt.

Gehen Sie in PrestaShop 9 zu Back Office > Design > Theme & Logo. Dies ist die richtige Einstellungsseite für Theme-Upload, Aktivierung, Logos, Seitenlayouts und erweiterte Theme-Anpassung.

1. Öffnen Sie Design > Theme & Logo.
2. Klicken Sie im Seitenkopf auf Neues Theme hinzufügen.
3. Lassen Sie das vorhandene Parent-Theme installiert; das Child-Theme erbt von ihm.

Importieren Sie das Child-Theme-ZIP von Ihrem Computer

Verwenden Sie auf der Seite Theme-Import die Option Von Ihrem Computer importieren und wählen Sie die ZIP-Datei mit den Child-Theme-Dateien aus. PrestaShop liest die Theme-Metadaten aus config/theme.yml und registriert das Theme, nachdem der Upload erfolgreich war.

1. Wählen Sie das Child-Theme-ZIP im Feld Zip-Datei aus.
2. Klicken Sie auf Speichern, um es hochzuladen.
3. Kehren Sie zu Theme & Logo zurück, wählen Sie Dieses Theme verwenden, leeren Sie den Cache und prüfen Sie den Storefront.

Laden Sie das Theme bei Produktivshops zuerst auf Staging hoch und testen Sie es dort, und führen Sie dann dieselben Aktivierungsschritte während eines ruhigen Wartungsfensters aus.

Erzeugen Sie online ein Hummingbird-Child-Theme-ZIP

Der Child Theme Generator ist ein öffentliches Werkzeug auf mypresta.rocks, es gibt also kein Generator-Modul, das Sie in Ihrem eigenen Shop installieren müssten. Öffnen Sie die Generator-Seite, wählen Sie Hummingbird (PrestaShop 9), geben Sie den Namen des Child-Themes ein, setzen Sie die PrestaShop-Version auf 9.x und schließen Sie die Starter-Dateien ein, die Sie im ZIP haben möchten.

Für den hier gezeigten PS9-Nachweis lud der Generator hummingbirdchild.zip mit config/theme.yml, custom.css, custom.js, optionalen Smarty-Overrides, Vorschaubild, README und optionalen SCSS-Build-Dateien herunter.

Prüfen Sie das erzeugte Child-Theme nach dem Import

Nachdem Sie das erzeugte ZIP über Theme-Import hochgeladen haben, kehren Sie zu Design > Theme & Logo zurück. Das erzeugte Theme sollte neben den Parent-Themes erscheinen, mit seinem Anzeigenamen, der Version, dem Autor und dem Vorschaubild.

Der hier gezeigte PS9-Demo-Import erstellte Hummingbird Child Version 1.0.0 von mypresta.rocks. An diesem Punkt können Sie es mit Dieses Theme verwenden aktivieren, den Cache leeren und den Storefront prüfen, bevor Sie es in der Produktion einsetzen.

Wie ein Child-Theme auf der Festplatte tatsächlich aussieht

Ein Child-Theme liegt neben seinem Parent innerhalb von /themes/. Dieses Beispiel enthält die erforderliche Konfiguration und ein optionales Vorschaubild:

themes/my-child-theme/
  config/
    theme.yml             <-- erforderlich: parent + name + version
  preview.png <-- optional: 200x200-Vorschau im BO angezeigt

Sobald Sie mit der Anpassung beginnen, spiegelt das Verzeichnis die Struktur des Parents wider. Enthält aber nur die Dateien, die Sie geändert haben:

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

Die Disziplin, auf die es ankommt: Fügen Sie eine Datei nur dann hinzu, wenn Sie sie tatsächlich ändern. Jede Datei, die Sie hinüberkopieren, ist eine Datei, die Ihnen nun gehört und die Sie pflegen müssen. Ein leeres Child-Theme, das alles erbt, ist gesünder als eines, das mit unveränderten Kopien von Parent-Templates vollgestopft ist.

theme.yml: die einzige wirklich verpflichtende Datei

Die entscheidende Zeile ist parent: classic oder parent: hummingbird. Das verdrahtet die Vererbung. Machen Sie es falsch, behandelt PrestaShop Ihr Child als eigenständiges Theme ohne Parent, auf das es zurückfallen kann, und die halbe Website bleibt leer.

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

Ein Child-Theme für Classic erstellen

Classic ist das, was die meisten Shops auf PS 1.7 und 8.x verwenden. Vier Schritte und Sie sind live:

# 1. Verzeichnis erstellen
mkdir -p themes/my-classic-child/config

# 2. config/theme.yml mit parent: classic schreiben (siehe oben)

# 3. preview.png (200x200) ablegen: an dieser Stelle genügt jedes PNG

# 4. Über Back Office > Design > Theme & Logo aktivieren
#    Oder per CLI: php bin/console prestashop:theme:enable my-classic-child

Mit use_parent_assets: true und ganz ohne Overrides rendert Ihre Site identisch zu Classic. Das ist der sichere Ausgangspunkt, bestätigen Sie, dass das leere Child-Theme funktioniert, und fügen Sie dann nacheinander einzeln Overrides hinzu.

Ein Child-Theme für Hummingbird erstellen

Hummingbird ist ein anderes Kaliber. Bootstrap 5.3 mit CSS Custom Properties, CSS Layers (@layer) zur Steuerung der Kaskade, TypeScript kompiliert über Webpack 5 und BEM-artige Benennung (.product__name, .product__description-short). Die Einrichtung ist dieselbe wie bei Classic, schreiben Sie theme.yml mit parent: hummingbird und einem Kompatibilitätsbereich, der bei 9.1.0 beginnt. Das Interessante ist, wie Sie Assets anpassen.

Das CSS-Layer-System, und warum Sie aufhören, gegen die Spezifität zu kämpfen

Hummingbird deklariert seine Layer-Reihenfolge in SCSS:

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

Stile in späteren Layern gewinnen über frühere, unabhängig von der Selektor-Spezifität. Das ist der Teil, der Leute überrascht, die von Classic kommen. Sie brauchen kein !important mehr. Sie brauchen keinen längeren Selektor. Legen Sie Ihre Regeln in den richtigen Layer und sie gewinnen.

@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;
  }
}

SCSS-Kompilierung

Wenn Sie SCSS statt reinem CSS möchten, fügen Sie einen Build-Schritt hinzu. Eine package.json mit sass als Dev-Abhängigkeit, Skripte für build:css (sass src/scss/custom.scss assets/css/custom.css --style=compressed) und watch:css. Dann npm install && npm run build:css.

Dart Sass stellt kompiliertem CSS gelegentlich eine UTF-8-BOM voran. Browser ignorieren dann stillschweigend die erste Regel, und Sie verbringen eine halbe Stunde damit, sich zu fragen, warum Ihr Reset nicht greift. Entfernen Sie sie: sed -i '1s/^\xEF\xBB\xBF//' assets/css/custom.css. Wir haben dies zu jeder Sass-Build-Pipeline hinzugefügt, die wir betreiben.

Template-Overrides

Hier verdienen sich Child-Themes ihren Lohn. Die Smarty-Implementierung von PrestaShop unterstützt ein sauberes Vererbungsmodell, und so wendet jeder unserer Shops Layout-Anpassungen an.

Wie PrestaShop ein Template auswählt

1. Child-Theme: themes/my-child/templates/
2. Parent-Theme: themes/hummingbird/templates/

Der bequeme Weg: die ganze Datei kopieren

Kopieren Sie das Parent-Template in das Child und bearbeiten Sie es dann. Ihre Version ersetzt die des Parents vollständig:

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

Der Preis, den Sie zahlen: Ihnen gehört nun die gesamte Datei. Wenn PrestaShop im nächsten Minor-Release einen Fix für dieses Template ausliefert (und das tut es), erhält Ihre Kopie ihn nicht. Wir verwenden diesen Ansatz für Templates, die wir wirklich von Grund auf neu geschrieben haben, und fast nie sonst.

Der richtige Weg: {extends} und nur die Blöcke überschreiben, die Ihnen wichtig sind

{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}

Das Präfix parent: ist entscheidend. Lassen Sie es weg, und Smarty löst die Datei zurück auf Ihr eigenes Child-Template auf, das sich selbst erweitert, Endlosschleife, PHP-Timeout. Wir haben das auf jedem Smarty-Projekt gesehen, das wächst: Man schreibt ein Snippet, vergisst das Präfix und sieht zu, wie der Request stirbt.

Anhängen und voranstellen statt ersetzen

Sie möchten nicht immer einen Block ersetzen, manchmal möchten Sie etwas hinzufügen. Smarty hat dafür Modifikatoren:

{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}

Die Blöcke, die Hummingbirds Produktseite bereitstellt

Die Override-Punkte auf Hummingbirds catalog/product.tpl:

{block name='product_cover_thumbnails'}: Produktbilder
{block name='product_header'}: Produktname (h1)
{block name='product_manufacturer'}: Markenlink
{block name='product_prices'}: Preisanzeige
{block name='product_description_short'}: Kurzbeschreibung
{block name='product_variants'}: Kombinationsauswahl
{block name='product_add_to_cart'}: In-den-Warenkorb-Schaltfläche
{block name='product_tabs'}: Beschreibung/Details-Akkordeon
{block name='product_accessories'}: verwandte Produkte

Für jede andere Seite besteht der Trick darin, das Parent-Template zu lesen. Jedes {block name='...'} im Parent ist ein Override-Punkt, den Sie vom Child aus ansteuern können.

CSS-Anpassung

Die custom.css-Konvention, und warum Classic und Hummingbird sie nicht beachten

Einige beliebte kommerzielle Themes (Warehouse, Flavor und mehrere Marketplace-Themes) laden custom.css und custom.js automatisch, wenn diese Dateien im assets/-Verzeichnis des Themes vorhanden sind. Die assets.yml des Themes registriert sie mit hoher Priorität, sie werden zuletzt geladen und werden nie von Theme-Updates angerührt, weil sie nicht zu den Distributionsdateien des Themes gehören. Es ist das sauberste Muster, das PrestaShop für „ich möchte einfach ein paar CSS-Regeln hinzufügen, ohne ein Child-Theme zu besitzen“ hat.

themes/your-theme/
  assets/
    css/
      theme.css          <-- Haupt-Stylesheet des Themes (vom Theme aktualisiert)
      custom.css         <-- Ihre Overrides (nie von Updates angerührt)
    js/
      theme.js           <-- Haupt-JS des Themes (vom Theme aktualisiert)
      custom.js          <-- Ihre Skripte (nie von Updates angerührt)

Wann Sie zu welchem greifen sollten:

• custom.css: reine CSS-Änderungen: Farben, Schriften, Abstände, Ausblenden von Elementen, kleinere Layout-Anpassungen. Keine HTML-Änderungen. Kein JS. Die schnellstmögliche Iterationsschleife.
• Child-Theme: alles, was die HTML-Struktur ändert, JavaScript hinzufügt, das Template eines Moduls überschreibt oder ein Layout umstrukturiert. Ein Child-Theme kann obendrein seine eigene custom.css enthalten.

Classic und Hummingbird laden custom.css nicht automatisch. Wenn Sie auf einem Standard-PrestaShop-Theme sind, brauchen Sie entweder ein Child-Theme mit der in theme.yml registrierten Datei oder ein Modul wie Custom CSS & JavaScript, mit dem Sie Code aus dem Back Office einschleusen können. Wir verwenden Letzteres auf kleinen Kundenshops, bei denen der Händler SSH nicht anfasst und wir nur drei Farbanpassungen einspielen müssen.

CCC wird Sie beißen. Wenn Combine, Compress, Cache aktiv ist, wird Ihre custom.css in eine hash-benannte kombinierte Datei gemerged. Bearbeiten Sie custom.css und im Frontend ändert sich nichts, bis Sie die CSS-Version in den Performance-Einstellungen erhöhen oder themes/*/assets/cache/ löschen. Jedes „aber ich habe das CSS doch geändert!“-Support-Ticket, das wir beantwortet haben, beginnt hier.

CSS über theme.yml registrieren

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

Dateien mit höheren priority -Werten werden später geladen und erhalten dadurch Vorrang vor den Parent-Stilen. Bevorzugen Sie auf Hummingbird @layer gegenüber Prioritäts-Akrobatik. Es ist der ganze Grund, warum das Layer-System existiert. Passen Sie auf Classic die Selektor-Tiefe des Parents an und vermeiden Sie !important. Sobald Sie anfangen, !important zu verstreuen, sind Sie in einem Krieg, den Sie nur eskalieren können.

Einen Hummingbird-Shop in drei Zeilen umfärben

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

Das war's. Der Custom-Property-Ansatz von Bootstrap 5 bedeutet, dass Änderungen auf Rebranding-Niveau keine einzige SCSS-Neukompilierung benötigen.

JavaScript-Anpassung

JS über theme.yml registrieren

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

Tauschen Sie all gegen einen Seitennamen aus, um das Skript einzugrenzen: product, category, cart, checkout, cms, index (Startseite) oder einen beliebigen Controller-Namen. Wir laden die meisten Analyse- und Tracking-Skripte global und die meisten seitenspezifischen Erweiterungen eingegrenzt. Es gibt keinen Grund, warum eine Sticky Bar der Warenkorbseite bei jeder Produktansicht geparst werden müsste.

Der JS-Event-Bus von PrestaShop

Das Front Office stellt einen kleinen Event-Bus auf window.prestashop bereit. Hören Sie auf die Ereignisse, die Sie interessieren, statt das DOM abzufragen:

prestashop.on('updatedProduct', function(event) { /* Kombination geändert */ });
prestashop.on('updateCart', function(event) { /* Warenkorb aktualisiert */ });

jQuery: weiterhin geladen, weiterhin nicht entfernen

Classic lädt jQuery global. Hummingbird lädt aus Gründen der Modul-Kompatibilität ebenfalls jQuery 3.x, obwohl das Theme selbst TypeScript ist. Für Ihren eigenen Code auf Hummingbird bietet Vanilla JS bessere Performance. Bootstrap 5 hat seine jQuery-Abhängigkeit fallengelassen und das Theme folgt dem. Aber wenn Sie jQuery entfernen, um „aufzuräumen“, geht jedes Drittanbieter-Modul kaputt, das weiterhin $(...) verwendet. Wir haben eine Regel: jQuery auf einem Produktivshop niemals deaktivieren, ohne zuvor jedes aktive Modul zu prüfen.

Modul-Template-Overrides

Die Templates jedes Moduls können vom Theme aus überschrieben werden, indem Sie die Verzeichnisstruktur des Moduls unter themes/your-child/modules/ spiegeln. Das ist eine der besten Funktionen von PrestaShop und der sauberste Weg, ein Drittanbieter-Modul neu zu gestalten, ohne es zu forken.

Auflösungsreihenfolge

1. Child-Theme: themes/my-child/modules/module_name/views/templates/...
2. Parent-Theme: themes/parent/modules/module_name/views/templates/...
3. Modul selbst: modules/module_name/views/templates/...

Die Mechanik

Finden Sie das Template des Moduls (z. B. modules/ps_featuredproducts/views/templates/hook/ps_featuredproducts.tpl), kopieren Sie es an den passenden Pfad unter dem modules/-Verzeichnis Ihres Themes und bearbeiten Sie es. Das Modul aktualisiert sich frei, ohne Ihre Version anzurühren.

Theme-Overrides gewinnen uneingeschränkt. Wenn ein Modul sein Template patcht, um einen XSS-Bug zu beheben, und Ihr Theme eine sechs Monate alte Kopie hat, rendert weiterhin die alte Version, XSS und alles. Vergleichen Sie Ihre Modul-Overrides mindestens einmal pro Quartal per Diff mit den aktuellen Modulversionen. Wir machen das als Teil der vierteljährlichen Wartung jedes Shops.

Übersetzungen innerhalb von Child-Themes

Reihenfolge der Übersetzungssuche:

1. Datenbank-Übersetzungen (Back Office > International > Übersetzungen)
2. translations/-Verzeichnis des Child-Themes
3. translations/-Verzeichnis des Parent-Themes
4. Modul-Übersetzungen
5. Kern-Übersetzungen

Verwenden Sie für einmalige String-Änderungen einfach den Übersetzungseditor im Back Office. Für alles, was Sie in Git haben möchten, erstellen Sie XLIFF-Dateien unter 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>

Mehrsprachige Shops erhalten ein Verzeichnis pro Locale: translations/fr-FR/, translations/de-DE/. Leeren Sie den Cache nach Änderungen. Übersetzungen werden aggressiv gecacht: php bin/console cache:clear.

Anpassungen, die wir auf den meisten Shops am Ende vornehmen

Umstrukturierter Header

{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}

Eigene Schriften richtig gemacht

WOFF2-Dateien in assets/fonts/, referenziert aus dem 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; }

Setzen Sie immer font-display: swap. Ohne es verbirgt der Browser den Text, bis die Schrift geladen ist, und Ihr Largest Contentful Paint wird von den Core Web Vitals abgestraft. Laden Sie die kritische Schrift per Preload: <link rel="preload" as="font" type="font/woff2" crossorigin>. Wir haben zugesehen, wie LCP-Werte auf Shops um 30 Punkte gestiegen sind, die nur diesen einen Fix umgesetzt haben.

Die vollständige Beschreibung aus den Tabs herausnehmen

{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} {* aus Tabs entfernt *}

Was sich bei PS-9-Themes geändert hat

• Hummingbird ist der Standard bei frischen PS-9.1-Installationen. Aktualisierte Shops behalten ihr vorheriges Theme. Classic wird weiterhin ausgeliefert und funktioniert, aber neue Funktionen erscheinen zuerst auf Hummingbird.
• Smarty bleibt für das Front Office. Twig wird im Admin verwendet (zunehmend, auch wenn die Migration nicht zu 100 % abgeschlossen ist). Ihre {extends}- und {block}-Overrides im Front Office funktionieren unverändert weiter.
• Bootstrap 5.3 statt Bootstrap 4. Wenn Sie ein Classic-Child auf Hummingbird migrieren, ist der Bootstrap-Migrationsleitfaden die Seite, die Sie geöffnet haben möchten.
• CSS Layers verändern, wie sich die Spezifität auflöst. Hören Sie auf, nach !important zu greifen.
• WebP ist das Standard-Bildformat. Neuer framework-Schlüssel in theme.yml: bootstrap-v5.3.3.
• Einige alte JS-Globals sind verschwunden. Alles, was sich in das alte Classic-JS eingeklinkt hat, muss getestet werden.

Twig könnte in einem künftigen Major-Release schließlich auch das Front Office erreichen. Halten Sie Ihre Overrides minimal und Ihre Blocknamen vernünftig, dann haben Sie einen leichteren Übergang, wenn es so weit ist.

Theme-Probleme debuggen

Erster Schritt, immer: php bin/console cache:clear. Setzen Sie für die Entwicklung den Template-Cache auf „Kompilierung erzwingen“ und schalten Sie CCC unter Erweiterte Einstellungen > Leistung aus. Alles andere und Sie debuggen gecachte Dateien, nicht Ihren Code.

Wenn Sie ein Template ändern und die Änderung nicht sehen, belügt Sie der Cache. Optimieren Sie nicht weiter am Template, leeren Sie den Cache, erzwingen Sie die Kompilierung und schauen Sie dann erneut. Die Hälfte der „mein Override funktioniert nicht“-Tickets, die wir erhalten, beginnt mit einem vergessenen Compile-Cache.

Hängen Sie an jede Frontend-URL ?SMARTY_DEBUG an, um ein Pop-up zu erhalten, das jedes geladene Template und jede Variable im Scope zeigt. Setzen Sie _PS_SMARTY_FORCE_COMPILE_ und _PS_SMARTY_CONSOLE_ in config/defines.inc.php auf 1, um es über Reloads hinweg aktiv zu halten.

Die Fehler, auf die Sie tatsächlich stoßen werden

Wenn der Cache wirklich festhängt, löschen Sie var/cache/prod/smarty/compile/ und var/cache/prod/smarty/cache/ von Hand. Wir tun das öfter, als wir zugeben möchten.

Upgrade: wo sich das Child-Theme endgültig auszahlt

Wenn das Parent-Theme aktualisiert wird, passiert mit jeder Datei Folgendes:

• Nur im Parent: wird normal aktualisiert, das Child erbt die neue Version automatisch.
• Im Child überschrieben: die Version Ihres Childs gewinnt weiterhin. Das Parent-Update ist für Ihren Shop unsichtbar.
• Eigene, nur im Child vorhandene Dateien: vollständig unangetastet.

Bevor Sie ein Parent-Update auslösen: Sichern Sie alles, listen Sie Ihre Overrides auf (find themes/my-child/templates -name "*.tpl"), führen Sie das Update in Staging aus (wir haben dafür eine Anleitung im Leitfaden zur lokalen Entwicklung), vergleichen Sie geänderte Parent-Templates per diff mit Ihren Overrides und testen Sie dann jede angepasste Seite auf echten Geräten. Lassen Sie einen dieser Schritte aus und Sie finden es um 8 Uhr morgens am falschen Montag heraus.

Gezielte {extends}-Overrides schlagen Vollkopien jedes Mal. Wenn das Parent einen neuen Block hinzufügt, erbt Ihr {extends}-Child ihn automatisch. Eine Vollkopie verpasst ihn vollständig, und Sie finden es erst heraus, wenn ein Kunde sich beschwert, dass die neue Funktion nicht da ist.

Checkliste vor dem Launch

Konfiguration: theme.yml hat das korrekte parent: und einen kleingeschriebenen name: ohne Leerzeichen. use_parent_assets: true ist gesetzt. Falls enthalten, wird preview.png korrekt angezeigt. Der Kompatibilitätsbereich passt zur PS-Version, mit der Sie ausliefern.

Templates: Jeder Override verwendet {extends file='parent:...'}, wo immer möglich. Blocknamen stimmen Zeichen für Zeichen mit dem Parent überein. var/logs/ ist sauber. Modul-Overrides wurden per Diff mit den aktuellen Modulversionen verglichen. nofilter ist auf jeder HTML-Variablen gesetzt, die kein erneutes Escaping benötigt.

Assets: Eigenes CSS lädt nach dem des Parents (hohe priority oder der richtige @layer). Kein !important verstreut. Schriften sind WOFF2 mit font-display: swap. Keine JS-Konsolenfehler. CCC wurde aktiviert und die Site rendert weiterhin.

Testen: Desktop in Chrome, Firefox, Safari, Edge. Mobil in iOS Safari und Android Chrome. Jeder responsive Breakpoint. Auf Touch-Geräten: Startseite, Kategorien, Produkt, Warenkorb, Checkout, Kundenkonto, CMS, Suche, 404.

Wartung: Das Child-Theme ist in Git. Die Overrides sind irgendwo dokumentiert, wo ein Mensch sie finden kann. Der Build-Prozess ist schriftlich festgehalten (siehe unseren Leitfaden zu den Entwicklungswerkzeugen). Das Team weiß, dass es keine Parent-Dateien bearbeiten darf.

Weiterführende Lektüre

• So migrieren Sie auf PrestaShop 9: Vollständiger Upgrade-Leitfaden: Theme-Änderungen beim Sprung auf PS 9
• PrestaShop Hooks & Overrides: Entwickler-Referenzleitfaden: wann Sie zu einem Hook statt zu einem Theme-Override greifen sollten
• PrestaShop SEO: URLs, Schema, Sitemaps & Core Web Vitals: SEO-freundliche Theme-Anpassungen
• Child-Themes in PrestaShop: Warum Sie niemals das Parent-Theme bearbeiten sollten
• So wählen Sie das richtige PrestaShop-Theme für Ihr Unternehmen

Verwandte Module

• HTML Blocks: fügen Sie konfigurierbare Inhaltsblöcke hinzu, statt Templates zu bearbeiten
• Mega Menu: bauen Sie einen fortgeschrittenen Header/eine Navigation ohne Theme-Hacks
• Product Extra Info Tabs: fügen Sie Produktseiten-Tabs hinzu, ohne Templates zu überschreiben

Passende Fragen

• CSS-Änderungen, die ich vornehme, erscheinen nicht im Frontend.
• Die Modulübersetzung funktioniert nicht. Text bleibt auf Englisch.
• Override funktioniert nicht. Mein Custom Template wird ignoriert.
• Kostenlose vs. Premium PrestaShop-Themes: Was Sie wirklich bekommen
• Was prüft das Theme Suitability Review?
• Können Sie ein Theme prüfen, das ich bereits gekauft oder auf dem ich aufgebaut habe?