Child-Themes in PrestaShop: Warum Sie das Parent-Theme nie direkt bearbeiten sollten

Aktualisiert im Juni 2026, behandelt Child-Themes sowohl für Hummingbird (PrestaShop 9, SCSS-Pipeline) als auch für Classic (PrestaShop 8). Der Override-Mechanismus ist bei beiden Parent-Themes identisch.

Das ist der Moment, in dem aus einem zufriedenen PrestaShop-Händler ein frustrierter wird: Sie haben ein Premium-Theme gekauft und wollten drei kleine Dinge ändern, eine andere Schrift für Überschriften, Ihre Markenfarbe auf den Schaltflächen, eine Anpassung am Layout der Produktseite. Also haben Sie /themes/your-theme/templates/catalog/product.tpl geöffnet und direkt bearbeitet. Es sah perfekt aus. Sechs Wochen später veröffentlichte der Theme-Autor Version 2.1 mit einem Sicherheitsfix und einer schnelleren Produktgalerie. Sie klickten auf Aktualisieren. Jede Ihrer Änderungen war weg: überschrieben und nicht wiederherstellbar, außer Sie hatten zufällig ein Backup, mit dem Sie vergleichen konnten.

Das ist die häufigste selbst verursachte Panne bei PrestaShop-Anpassungen, und es gibt dafür seit Jahren eine saubere Lösung: das Child-Theme. Genau darum geht es in diesem Leitfaden. Was ein PrestaShop-Child-Theme auf Dateisystem-Ebene tatsächlich ist, wie die Override-Auflösung entscheidet, welche Datei gewinnt, wie Sie eines auf Basis von Hummingbird oder Classic erstellen und wo die klare Grenze zwischen „Child-Theme verwenden“ und „dafür braucht es ein Modul“ verläuft. Wenn Sie eigentlich nur ein CSS-Snippet oder ein Tracking-Skript hinzufügen möchten, ohne irgendetwas zu forken, ist das ein enger umrissener Fall mit eigener Antwort, siehe benutzerdefiniertes CSS und JavaScript ohne Update-Bruch, und wir verweisen Sie weiter unten an der passenden Stelle noch einmal darauf.

Was ein Child-Theme tatsächlich ist (auf Dateiebene)

Ein Child-Theme ist ein separates Theme-Verzeichnis, das in seiner config/theme.yml ein parent deklariert und alles davon erbt, jedes Template, jedes Asset, jeden Konfigurationswert, während Sie einzelne Dateien überschreiben können. Es ist keine Kopie des Parent-Themes. Es ist eine schlanke Schicht, die darüberliegt. Jede Datei, die Sie nicht im Child-Theme ablegen, wird aus dem Parent-Theme ausgeliefert; jede Datei, die Sie im Child-Theme ablegen, hat Vorrang.

Das „Was bringt mir das?“ ist der Kern der ganzen Technik: Weil das Child-Theme in seinem eigenen Verzeichnis liegt, berührt ein Update des Parent-Themes nur das Parent-Theme und lässt Ihre Arbeit in Ruhe. Das Parent-Theme wird auf v2.1 aktualisiert, Ihre Overrides laufen weiter darüber, und Sie verbringen den Abend nicht damit, Anpassungen aus dem Gedächtnis nachzubauen. Sie bekommen die Fehlerbehebungen und Performance-Verbesserungen des Theme-Autors und Ihr Branding. Statt sich zwischen beidem entscheiden zu müssen.

Die Override-Auflösung. Die Mechanik, die das Ganze möglich macht

Damit Sie Child-Themes vertrauen können, müssen Sie genau wissen, wie PrestaShop entscheidet, welches Template gerendert wird. Wenn ein Controller ein Template anfordert, sucht die Theme-Rendering-Schicht in einer festen Reihenfolge und stoppt beim ersten Treffer:

Deshalb funktioniert „kopieren Sie die eine Datei, die Sie brauchen, und bearbeiten Sie die Kopie“, ohne alles andere zu beschädigen: PrestaShop löst jedes Template unabhängig auf. Überschreiben Sie product.tpl, und der Rest des Shops wird weiterhin aus dem Parent-Theme gerendert. Es gibt keinen Alles-oder-nichts-Schalter, das Child-Theme fängt nur die exakten Pfade ab, die Sie befüllen, und fällt für alles andere auf das Parent-Theme zurück. Dieser Fallback ist die Stärke, keine Einschränkung: Je weniger Dateien Sie abfangen, desto mehr Updates des Parent-Themes fließen direkt in Ihren Shop.

config/theme.yml, die Datei, die die Beziehung deklariert

Die gesamte Vererbung hängt an einer Datei im config/-Verzeichnis Ihres Child-Themes: config/theme.yml. Der Schlüssel parent sagt PrestaShop: „Liefere alles aus diesem Theme aus, solange ich es nicht überschreibe.“ Ein minimales Child-Theme auf Basis von Hummingbird sieht so aus:

parent: hummingbird
name: my-store-child
display_name: My Store Child
version: 1.0.0
assets:
  use_parent_assets: true

Der Wert von parent muss dem Verzeichnisnamen des Parent-Themes entsprechen (und das Parent-Theme muss tatsächlich installiert sein. Ein Child-Theme kann nicht von einem Theme erben, das auf dem Server nicht vorhanden ist). name muss eindeutig sein und dem eigenen Verzeichnisnamen Ihres Child-Themes entsprechen. Ist eines davon falsch, fällt PrestaShop entweder still auf das Parent-Theme zurück oder verweigert die Aktivierung des Themes, beides lässt sich deutlich leichter diagnostizieren, wenn man weiß, dass fast immer ein Namenskonflikt in dieser Datei dahintersteckt.

Ein Child-Theme Schritt für Schritt erstellen

Ein Child-Theme bewirkt nichts, solange es nicht als aktives Theme ausgewählt ist.

• Verzeichnis erstellen, zum Beispiel /themes/my-store-child/, darin ein config/-Verzeichnis. Kopieren Sie nicht die Dateien des Parent-Themes hinein. Ein minimales Child-Theme kann sehr klein sein, muss aber eine gültige config/theme.yml enthalten, die parent, name, display_name und version deklariert, mit dieser Datei rendert es identisch zum Parent-Theme.
• config/theme.yml hinzufügen unter /themes/my-store-child/config/theme.yml mit der oben gezeigten Parent-Referenz.
• Nur die Dateien kopieren, die Sie tatsächlich ändern, und dabei den relativen Pfad beibehalten. Um die Produktseite anzupassen, kopieren Sie /themes/hummingbird/templates/catalog/product.tpl nach /themes/my-store-child/templates/catalog/product.tpl und bearbeiten ausschließlich die Kopie im Child-Theme.
• Aktivieren Sie es im Backoffice unter Design → Theme & Logo. Das Verzeichnis allein bewirkt nichts, solange Sie das Child-Theme hier nicht auswählen und verwenden, liefert der Shop weiterhin das Parent-Theme aus. Das ist die häufigste Supportfrage nach dem Muster „Warum wird meine Änderung nicht angezeigt?“, und die Antwort lautet fast immer: Das Child-Theme wurde nie aktiviert.

Die Verzeichnisstruktur des Child-Themes spiegelt das Parent-Theme exakt. Ein Template muss im Child-Theme unter demselben relativen Pfad liegen wie im Parent-Theme, über diese Pfadübereinstimmung ordnet der Resolver die Dateien einander zu.

Was in ein Child-Theme gehört, und was nicht

Templates (.tpl). Ja, dafür ist es das richtige Werkzeug

Strukturelle Markup-Änderungen, Produktseitenblöcke neu anordnen, einen eigenen Infobereich hinzufügen, die Ausgabe des Headers ändern, sind genau der Zweck von Template-Overrides. Kopieren Sie das Parent-Template in den passenden Child-Pfad und bearbeiten Sie es dort. Auch das Überschreiben eines Front-Templates eines Moduls (eine Datei unter /themes/[theme]/modules/[module]/views/templates/front/[template].tpl) ist eine dokumentierte Technik, aber beachten Sie: Gerade mit Child-Themes ist das eine bekannte Schwachstelle. Die PrestaShop-Dokumentation zu Child-Themes deckt Modul-Template-Overrides nicht ab, und es gibt offene Berichte, dass sie aus einem Child-Theme heraus uneinheitlich aufgelöst werden (Template-Caching kann stattdessen die Kopie des Parent-Themes ausliefern). Wenn Sie die Ausgabe eines Moduls neu gestalten müssen und ein Child-Theme verwenden, testen Sie das sorgfältig mit Ihrer Version oder legen Sie den Override direkt im aktiven Theme ab, statt sich auf das Parent/Child-Fallback zu verlassen.

CSS und JavaScript, meistens die falsche Ebene

Wenn Ihre Änderung rein visuell ist, Farben, Schriften, Abstände, ein Element ausblenden, ist das Überschreiben eines ganzen Templates der schwerfällige Weg, und Sie müssen dieses Template bei jedem Parent-Update erneut zusammenführen. Schlanker und updatesicherer ist ein Stylesheet oder Skript, das nach den Assets des Parent-Themes geladen wird und keinerlei Template-Logik dupliziert. Das ist ein eigener Anwendungsfall mit eigenem Leitfaden: benutzerdefiniertes CSS und JavaScript in PrestaShop ohne Update-Bruch. Als Faustregel gilt: Greifen Sie nur dann zu einem Template-Override, wenn Sie wirklich das Markup ändern müssen; alles, was CSS leisten kann, gehört in CSS.

Geschäftslogik. Weder noch; das ist ein Modul

Die harte Grenze: Wenn Ihre Änderung das Verhalten betrifft. Wie Preise berechnet werden, wie der Versand ausgewählt wird, was an der Kasse passiert. Ist ein Child-Theme der völlig falsche Ort. Templates zeigen Daten an; sie dürfen sie nicht verarbeiten. Sobald Sie echte PHP-Logik in eine .tpl-Datei schreiben, haben Sie Geschäftslogik in die Darstellungsschicht gelegt, wo sie sich weder sauber testen noch wiederverwenden oder aktualisieren lässt. Diese Arbeit gehört in ein Modul (oder in eine Override-Klasse), nicht ins Theme. Ein Theme entscheidet, wie der Warenkorb aussieht; ein Modul entscheidet, wie sich der Warenkorb verhält.

Warum „schlank“ eine feste Regel ist, keine Nettigkeit

Jede Datei, die Sie überschreiben, ist eine Datei, die keine Korrekturen des Parent-Autors mehr erhält. Wenn das Parent-Theme in v2.1 eine korrigierte, barrierefreiere product.tpl liefert und Sie Ihre eigene Kopie haben, bekommen Sie diese Korrektur nicht. Ihre Kopie bleibt beim Markup von v2.0 eingefroren, bis Sie den Unterschied manuell zusammenführen. Jeder Override bringt also laufenden Wartungsaufwand mit sich, und die Rechnung kommt bei jedem Parent-Update.

Die Disziplin, die diesen Aufwand klein hält: Überschreiben Sie die kleinste Einheit, die die Aufgabe erfüllt. Müssen Sie einem Element eine Klasse hinzufügen? Überschreiben Sie genau dieses eine Template, nicht dessen übergeordnetes Layout, nicht den gesamten catalog-Ordner. Brauchen Sie eine Farbänderung? Das ist CSS, kein Template. Ein Child-Theme mit vier Override-Dateien ist in fünf Minuten aktualisiert; eines mit vierzig wird bei jedem Parent-Update zum Projekt.

Ein Parent-Theme-Update überstehen

Wenn der Parent-Autor eine neue Version veröffentlicht, bleibt die Routine kurz, weil die Architektur die Hauptarbeit übernimmt:

• Aktualisieren Sie das Parent-Theme. Ihr Child-Theme ist ein separates Verzeichnis, also wird nichts überschrieben, was Sie geschrieben haben.
• Vergleichen Sie Ihre Overrides mit den neuen Parent-Versionen. Vergleichen Sie für jede kopierte Datei Ihre eingefrorene Child-Kopie mit der neuen Parent-Kopie, mit einem beliebigen Diff-Werkzeug. Genau hier wird der Wartungsaufwand fällig, und er ist immer nur so groß wie die Zahl Ihrer Overrides.
• Führen Sie alles zusammen, was sich zu übernehmen lohnt, einen Bugfix, ein neues Feld, eine Verbesserung der Barrierefreiheit, die der Autor in ein Template eingebaut hat, das Sie überschreiben, in Ihre Child-Kopie.
• Testen Sie die betroffenen Seiten, insbesondere die Seiten, deren Templates Sie überschreiben, davor und danach.

Dateien, die Sie nicht überschrieben haben, brauchen nichts davon, sie wurden automatisch in dem Moment aktualisiert, in dem Sie das Parent-Theme aktualisiert haben. Genau diese Asymmetrie ist der Nutzen der Technik: Sie machen Diff- und Merge-Arbeit nur proportional zu dem, was Sie angepasst haben, und bekommen den Rest ohne Zusatzaufwand.

Hummingbird oder Classic, welches Parent-Theme im Jahr 2026?

Hummingbird ist die moderne offizielle Theme-Richtung von PrestaShop für die PS-9-Ära, während Classic weiterhin verbreitet und verfügbar ist, besonders bei PS 8 und älteren Shops. Der Child-Theme-Mechanismus ist unabhängig vom Parent-Theme identisch, dieselbe config/theme.yml, dieselbe Auflösungsreihenfolge, aber das gewählte Parent-Theme verändert Ihren Asset-Build:

Wenn Sie von PrestaShop 8 mit einem Classic-basierten Child-Theme upgraden, müssen Sie nicht am ersten Tag auf Hummingbird migrieren. Classic bleibt als separater Download verfügbar, aber ein neuer Aufbau sollte mit Hummingbird starten. Da Hummingbirds Stylesheet-Pipeline auf SCSS basiert, unterscheidet sich die Kompilierung von eigenem CSS von Classic; die Wahl des Parent-Themes betrifft daher vor allem Ihren Styling-Workflow, nicht die Override-Logik. Das richtige Basis-Theme gleich zu Beginn bewusst zu wählen, lohnt sich, wir behandeln das in so wählen Sie das richtige PrestaShop-Theme für Ihr Unternehmen.

Häufige Fehler, die trotzdem noch passieren

• Das Child-Theme wurde nie aktiviert. Verzeichnis und config/theme.yml existieren, aber der Shop liefert weiterhin das Parent-Theme aus, weil niemand das Child-Theme unter Design → Theme & Logo ausgewählt hat. Immer zuerst prüfen.
• Namenskonflikt in config/theme.yml. name passt nicht zum Verzeichnis, oder parent verweist auf ein Theme, das nicht installiert ist. Das Child-Theme fällt still zurück oder lässt sich nicht aktivieren.
• Override-Wildwuchs. Vierzig kopierte Templates, weil „es einfacher war, den ganzen Ordner zu kopieren“. Jedes einzelne davon ist jetzt bei jedem Parent-Update ein manueller Merge. Halten Sie die Struktur bewusst schlank.
• Keine Versionskontrolle. Ein Child-Theme ist eigener Code. Es gehört mit aussagekräftigen Commit-Nachrichten in Git, damit ein schlechter Merge nach einem Parent-Update mit einem Revert erledigt ist. Statt zum Ratespiel zu werden.
• „Nur dieses eine Mal“ am Parent-Theme. Es gibt kein „nur dieses eine Mal“. Eine direkte Änderung am Parent-Theme wird zu zwanzig, und dann ist das Update, das Sie nicht mehr einspielen können, ausgerechnet das Sicherheitsupdate, das Sie am dringendsten gebraucht hätten. Jede Änderung, so klein sie auch ist, gehört ins Child-Theme.

Das Fazit

Ein Child-Theme ist in etwa zehn Minuten eingerichtet, ein Verzeichnis, eine config/theme.yml, der korrekt geschriebene Parent-Name, Aktivierung im Backoffice, und es verwandelt künftige Parent-Updates von einer Gefahr für Ihre Anpassungen in einen normalen Vorgang. Es ist keine fortgeschrittene Technik und keine optionale Best Practice; in PrestaShop ist es schlicht der richtige Weg, jedes Theme anzupassen, das Sie nicht selbst geschrieben haben. Wenn Sie aktuell Dateien des Parent-Themes direkt bearbeiten, ist der nächste Schritt unabhängig davon, wie klein Ihre Änderungen wirken: Erstellen Sie heute ein Child-Theme und verschieben Sie Ihre Overrides dorthin, bevor das nächste Update sie überschreibt. Danach halten Sie es schlank, reine Gestaltung in CSS und JS, die Updates überstehen, Verhalten in Module, und Template-Overrides nur für Markup-Änderungen, die sie wirklich benötigen.

Häufig gestellte Fragen

Muss ich das gesamte Parent-Theme in mein Child-Theme kopieren?

Nein, und Sie sollten es nicht tun. Ein Child-Theme erbt standardmäßig alles vom Parent-Theme; Sie kopieren nur die konkreten Dateien hinein, die Sie ändern, und behalten deren relativen Pfad bei. Ein minimales Child-Theme kann einfach ein Verzeichnis mit gültiger config/theme.yml sein und rendert identisch zum Parent-Theme. Je weniger Dateien Sie kopieren, desto mehr Parent-Updates fließen direkt in Ihren Shop.

Mein Child-Theme sieht genauso aus wie das Parent-Theme, und keine meiner Änderungen erscheint. Warum?

Fast immer liegt es an einem von zwei Dingen: Das Child-Theme wurde nie unter Design → Theme & Logo aktiviert (das Verzeichnis allein bewirkt nichts), oder es gibt einen Namenskonflikt in config/theme.yml, name passt nicht zum Verzeichnis des Child-Themes, oder parent verweist auf ein Theme, das nicht installiert ist. Prüfen Sie zuerst die Aktivierung, danach das YAML.

Kann ich mein eigenes CSS und JavaScript ins Child-Theme legen?

Das können Sie, aber bei rein visuellen Änderungen, Farben, Schriften, Abstände, ein Element ausblenden, ist das Überschreiben eines ganzen Templates schwerfällig und erzwingt bei jedem Parent-Update einen erneuten Merge. Ein Stylesheet oder Skript, das nach den Assets des Parent-Themes geladen wird, ist schlanker und dupliziert keine Template-Logik. Nutzen Sie Template-Overrides nur für echte Markup-Änderungen; alles, was CSS leisten kann, gehört in CSS. Siehe benutzerdefiniertes CSS und JavaScript ohne Update-Bruch.

Überleben meine Overrides ein Update des Parent-Themes?

Ja. Das Child-Theme liegt in seinem eigenen Verzeichnis, daher berührt ein Parent-Update es nicht. Die eine Aufgabe, die bleibt: Vergleichen Sie jede Datei, die Sie überschrieben haben, mit der neuen Parent-Version und übernehmen Sie sinnvolle Änderungen (einen Bugfix, eine Verbesserung der Barrierefreiheit). Dieser Aufwand hängt nur von der Anzahl der kopierten Dateien ab, genau deshalb zahlt es sich aus, die Zahl der Overrides klein zu halten.

Kann ein Child-Theme ein Front-End-Template eines Moduls überschreiben?

Das ist eine dokumentierte Technik, aber gerade mit Child-Themes eine bekannte Schwachstelle. Es gibt offene Berichte, dass Modul-Template-Overrides aus einem Child-Theme heraus uneinheitlich aufgelöst werden, weil Template-Caching stattdessen die Kopie des Parent-Themes ausliefern kann. Wenn Sie die Ausgabe eines Moduls neu gestalten müssen und ein Child-Theme verwenden, testen Sie das sorgfältig mit genau Ihrer Version oder legen Sie den Override direkt im aktiven Theme ab, statt sich auf das Parent/Child-Fallback zu verlassen.

Die Änderung, die ich möchte, betrifft Verhalten, nicht Darstellung. Gehört sie ins Child-Theme?

Nein. Wenn Sie ändern, wie Preise berechnet werden, wie der Versand ausgewählt wird oder was an der Kasse passiert, ist das Geschäftslogik und gehört in ein Modul oder eine Override-Klasse, niemals in eine .tpl-Datei. Templates zeigen Daten an; sie dürfen sie nicht verarbeiten. Ein Theme entscheidet, wie der Warenkorb aussieht; ein Modul entscheidet, wie sich der Warenkorb verhält.

Sollte ein Child-Theme unter Versionskontrolle stehen?

Ja. Ein Child-Theme ist eigener Code und gehört mit aussagekräftigen Commit-Nachrichten in Git. Der Nutzen zeigt sich nach einem Parent-Update: Wenn ein Merge schiefgeht, sind Sie nur einen Revert von einem bekannten guten Zustand entfernt, statt raten zu müssen, was Sie geändert haben. Außerdem sehen Sie sofort, welche Parent-Dateien Sie geforkt haben und daher beim nächsten Update vergleichen müssen.

Brauchen Hummingbird und Classic unterschiedliche Child-Theme-Setups?

Der Override-Mechanismus ist identisch, dieselbe config/theme.yml, dieselbe Auflösungsreihenfolge, daher ändert die Parent-Wahl nicht die Logik. Sie verändert Ihren Styling-Workflow: Hummingbirds Stylesheet-Pipeline basiert auf SCSS, Classic ist einfacher aufgebaut, daher unterscheidet sich die Kompilierung von eigenem CSS. Wählen Sie Hummingbird für neue Builds und Classic, wenn Sie ein bestehendes Classic-basiertes Child-Theme pflegen.

Weiterführende Leitfäden

• Benutzerdefiniertes CSS und JavaScript in PrestaShop ohne Update-Bruch
• So wählen Sie das richtige PrestaShop-Theme für Ihr Unternehmen
• HTML-Blöcke: Benutzerdefinierte Inhalte überall in Ihrem PrestaShop-Shop hinzufügen