Child Theme bei einem Block Theme mit dem Plugin „Create Block Theme“ erstellen
Bei neuen Projekten verwenden wir mittlerweile immer Block Themes. Block Themes sind unglaublich flexibel und durch die ständige Erweiterung des Block Editors kann man nach meiner Meinung mittlerweile fast jedes Design erstellen. Warum es sinnvoll sein kann, direkt ein Child Theme zu erstellen und welche Dinge zu beachten sind, wenn man das Plugin Create Block Theme verwendet, ist Thema in diesem Beitrag.
Was ist ein Child Theme?
Wenn wir mit einem Projekt beginnen, installieren wir zunächst als Parent Theme ein Block Theme unserer Wahl. In letzter Zeit verwenden wir gerne das Block Theme Ollie.
Ein Child Theme basiert auf einem Parent Theme und enthält nur die geänderten Dateien – alle anderen werden vom Parent Theme geerbt. Bei Block Themes ist das besonders sinnvoll, da du so Anpassungen wie Templates, Template Parts, Patterns (Vorlagen) oder theme.json-Einträge dauerhaft speichern kannst, ohne dass Updates des Parent Themes deine Arbeit überschreiben. Es schützt deine Änderungen und ermöglicht einfache Wiederverwendung, z. B. für Kundenprojekte mit einem Block Theme wie Ollie.
Mit dem Plugin „Create Block Theme“ erstellst du ein Child Theme direkt im Site Editor: Wenn du das Plugin installiert und aktiviert hast, erscheint unter Design eine zusätzliche Option „Block Theme erstellen“. Nach einem Klick auf „Block Theme erstellen“, erscheinen vier Optionen. Hier wählt man die Option „Create a Child of Theme„. Bei Theme wird der Name des Themes genannt. In unserem Fall wäre das „Ollie“.
Im nachfolgenden Modal muss man eine Bezeichnung für das Child Theme eingeben. Optional können Metadaten wie Autor oder Beschreibung angegeben werden. Anschließend klickt man auf „Create Child Theme“. Das Plugin überträgt deine aktuellen Editor-Änderungen (Styles, Templates, Assets) automatisch ins neue Child Theme, das sofort aktiviert wird – inklusive theme.json-Anpassungen und Screenshot-Generierung. Der Screenhot kann übrigens natürlich durch einen eigenen Screenshot ersetzt werden. Dazu muss ein eigener Screenshot erstellt und per FTP in den Ordner des Child Themes kopiert werden.
Im Video erscheint die Meldung „Du versuchst ein Element zu bearbeiten, welches nicht existiert. Möglicherweise wurde es gelöscht?“. Das ist eine Meldung, die leider aktuell bei WordPress-Instanzen erscheinen, die bei WordPress Playground erstellt werden. WordPress Playground verwende ich gerne zum Testen von Plugins oder zur Erstellung von Videos. Bei „normalen“ WordPress-Instanzen erscheint diese Meldung nicht.
Eine weitere Möglichkeit zur Erstellung eines Child Themes besteht darin, wenn man nach Installation und Aktivierung des Plugins unter Design > Editor z. B. auf „Templates“ klickt, ein beliebiges Template auswählt und anschließend auf das Schraubenschlüssel-Icon oben rechts klickt.

Danach passen wir das Child Theme an, wie z. B. Farben unter Design > Editor > Stile:

Änderungen in Child Theme speichern
Um diese Änderungen am Child Theme zu speichern, klickt man auf „Save Changes to Theme“ im selben Block Theme Panel: Das Plugin wandelt Editor-Änderungen (die normalerweise in der Datenbank landen) in Theme-Dateien um, löscht die DB-Änderungen und macht sie permanent. Es überschreibt Dateien wie theme.json, templates/.html oder parts/.html und macht Strings übersetzungsready, während Bilder in /assets/ landen. Es ist nicht ratsam, diese Option zu nutzen, wenn man kein Child Theme erstellt hat, weil damit Anpassungen im Parent Theme durchgeführt werden, die möglicherweise beim nächsten Update des Parent Themes wieder überschrieben werden bzw. nicht einfach rückgängig gemacht werden können.
Im nachfolgenden Video zeige ich exemplarisch ein paar Änderungen, die ich im Child Theme vornehme. Diese Änderungen sollen dann in das Child Theme gespeichert werden.
Optionen bei „Save Changes to Theme“
Wenn ich die Optionen bei „Save Changes to Theme“ sehe, muss ich ehrlich gesagt immer neu darüber nachdenken, was wohl damit gemeint ist und welche Auswirkungen das wohl haben wird.
Aus dem Grund habe ich recherchiert und versuche nachfolgend eine deutlichere Erklärung für die einzelnen Optionen zu erstellen. Hilfreich ist hier besonders die folgende Quelle: https://github.com/WordPress/create-block-theme
- „Save Fonts“:
Aktivierte Schriftarten aus der Schriftartenbibliothek im Design speichern. Deaktivierte Schriftarten aus dem Design entfernen. - „Save Style Changes“:
Die im Editor festgelegten globalen Stilwerte wie z. B. die Farben und Layout-Änderungen, die ich vorgenommen habe, werden im Design gespeichert. Aktualisierttheme.jsonmit Global Styles, Farben, Typografie. - „Save Template Changes“:
Speichert alle Templates/Template Parts als HTML-Dateien. Die im Editor vorgenommenen Änderungen an Vorlage und Vorlagenteil werden im Design gespeichert. - „Process Only Modified Templates“:
Verarbeitet werden nur die Templates, die im Editor geändert wurden. Alle anderen Templates bleiben unverändert. - „Save Patterns“:
Alle im Editor erstellten Patterns (Vorlagen) werden in das Theme übernommen. - „Localize Text“:
Diese Option macht Texte in Templates und Patterns übersetzungsready. Sie ersetzt statischen Text durch<!-- wp:paragraph --><p><?php echo esc_html__( 'Dein Text', 'textdomain' ); ?></p><!-- /wp:paragraph -->-Strukturen, wobei die Textdomain automatisch aus dem Theme-Namen generiert wird. Das ermöglicht i18n-Unterstützung für Mehrsprach-Websites oder Theme-Verteilung – ohne diese Option bleiben Texte hardcoded und nicht übersetzbar. - „Localize Images“:
Bilder aus Templates/Patterns werden in den Theme-Ordner/assets/kopiert und relativ referenziert (/assets/image.jpg). Externe URLs (z.B. von Unsplash) werden lokalisiert, wodurch das Theme unabhängig von externen Servern wird. Ohne diese Option brechen Bilder bei Theme-Export, da externe Links offline sind. - „Remove Navigation Refs“:
Entfernt Navigation-Referenzen austheme.jsonund Templates, stellt Site-Editor-Navigations auf Default-Zustand zurück. Nützlich, wenn custom Navigation Menus (per ID/Name referenziert) beim Theme-Export nicht funktionieren sollen oder du beim Zielort eigene Menus erwartest. Verhindert „leere Navigation“-Fehler auf frischen Installationen. - „Remove Taxonomy Query“:
Löschttaxonomy-Queries aus Query Loop Block-Attributen in Templates. Query Loops mit spezifischen Taxonomien (z.B.post_type: post&taxonomy: category) werden zu generischen Loops zurückgesetzt. Sinnvoll für wiederverwendbare Themes, da Taxonomie-Queries oft site-spezifisch sind und auf neuen Installationen fehlschlagen würden.
Diese Optionen erscheinen beim „Save Changes to Theme“ und bereiten das Theme für Distribution vor – aktiviere sie gezielt je nach Use Case (Export vs. lokale Weiterentwicklung).
Standardmäßig sind die letzten vier Optionen deaktiviert, weil diese Optionen eher beim Export des Themes bzw. Weiterentwicklung für andere Projekte verwendet werden. Im Video ist auch zus sehen, wie man ein Child Theme exportieren kann.
Mögliche Probleme mit „Save Changes to Theme“
Nachfolgend einige Dinge, die ich meistens auch selbst bei Auswahl der Option erlebt habe:
- Es kann Custom Block Style Variations oder pluginbasierte Styles löschen, wenn sie nicht korrekt in
theme.jsonlanden. - Kategorien von Templates/Patterns gehen verloren und landen in „Allgemein“, da das Plugin keine Editor-Organisation speichert. Das ist mir übrigens auch mit großgeschriebenen Kategorien (also z. B. „Haurand“ statt „haurand“) und bei Verwendung von Umlauten bei Templates, Patterns (Vorlagen) und oder Kategorien schon passiert.
- Farben werden nicht korrekt zugeordnet: In manchen Fällen hatte ich das Problem, dass ich eine Hintergrundfarbe bei Design > Stile > Farben > Hintergrund angegeben habe, die aber nach Klick auf den Button „Änderungen speichern“ nicht übernommen wurde.
- Nach dem Speichern erscheinen Templates als „gesperrt“ (Schloss-Symbol), was die Bearbeitung erschwert. Insofern ist es ratsam, die Option Save Template Changes erst dann zu wählen, wenn die Templates komplett angepasst sind. Eine mögliche Lösung, wenn man die Templates noch mal bearbeiten möchte, besteht darin, dass man die Dateien direkt editiert. Dazu muss man allerdings die Dateien per FTP runterladen, lokal bearbeiten und wieder hochladen – ein mühsamer Prozess, zumal man dabei durchaus auch leicht Fehler machen kann.
Einfacher ist evtl. in dem Fall die folgende Variante, die ich selbst – so weit ich das noch in Erinnerung habe – durchgeführt habe:
Im Editor das Template öffnen > Drei-Punkte-Menü > „Duplizieren“. Bearbeite das Duplikat. Die gesperrte Version habe ich dann per FTP gelöscht.
Nachfolgend ein Video, bei dem einige der genannten Probleme nach „Save Changes to theme“ aufgetreten sind:
Erwartet hatte ich, dass die Hintergrundfarbe weiß bleibt und die Farben der Palette durch die von mir erstellte individuelle Farbe (gelb) ergänzt wird. Wie man sehen kann, ist das leider nicht der Fall.
Daher ändere ich sicherheitshalber mittlerweile immer die gewünschten Farben direkt in der theme.json des Child-Themes.
Hier ein entsprechender Ausschnitt aus einer theme.json mit den geänderten Farben und Layout:
{
"$schema": "https://schemas.wp.org/wp/6.9/theme.json",
"version": 3,
"settings": {
"color": {
"palette": [
{
"color": "#E7EFEB",
"name": "mintgruen",
"slug": "custom-mintgruen"
},
{
"color": "#ffffff",
"name": "weiss",
"slug": "custom-weiss"
},
{
"color": "#FAF8F5",
"name": "hellbeige",
"slug": "custom-hellbeige"
},
{
"color": "#F6F4EE",
"name": "mittelbeige",
"slug": "custom-mittelbeige"
},
{
"color": "#F3E8E2",
"name": "rosa",
"slug": "custom-rosa"
},
{
"color": "#437059",
"name": "dunkelgruen",
"slug": "custom-dunkelgruen"
},
{
"color": "#C2C9B0",
"name": "gruen",
"slug": "custom-gruen"
},
{
"color": "#3B332B",
"name": "dunkelbraun",
"slug": "custom-dunkelbraun"
},
{
"color": "#CC976F",
"name": "hellbraun",
"slug": "custom-hellbraun"
},
{
"color": "#000000",
"name": "schwarz",
"slug": "custom-schwarz"
}
]
},
"layout": {
"contentSize": "1024px",
"wideSize": "1280px"
}
}
....
}Wann du auf ein Child Theme verzichten kannst
- Rein editorbasierte Änderungen für eine einzelne Seite/Instanz
Wenn du nur Global Styles (also Farben, Schriften, etc.), ein paar Templates und Navigationsstrukturen im Site Editor anpasst und nicht vorhast, die Ergebnisse als „eigenes Theme“ weiterzugeben, kann man auch evtl. auf ein Child Theme verzichten - Kleine Experimente oder Testumgebungen
In einer Spiel- oder Demo‑Instanz, die du jederzeit resettest, ist ein Child Theme nicht zwingend nötig.
Warum das Plugin „Create Block Theme“ hilfreich ist
- Child Theme bequem erzeugen
Das Plugin bietet explizit die Option „Create child of ‹Theme›“, um aus dem aktiven Block Theme ein Child Theme zu erstellen; dabei werden deine aktuellen Editor‑Anpassungen übernommen. - Sicheres Arbeiten im „Entwicklungsmodus“
Du kannst erst im Site Editor gestalten und dann via Create Block Theme alles (Templates,theme.json, Assets) als Child Theme exportieren. So arbeitest du visuell, erhältst aber am Ende eine saubere Dateibasis.
Peter Müller hat mich noch auf zwei spezielle Links für das Theme Ollie hingewiesen:
- Ein speziell für Ollie vorbereitetes Child Theme: https://olliewp.com/docs/general/resources/#child-theme
- Ein kurze Beschreibung, wie Styles bei Ollie deaktivieren kann:
https://olliewp.com/docs/ollie-block-theme/disable-ollie-styles/#how-to-disable-styles
Fazit
Das Plugin „Create Block Theme“ ist ein sinnvolles Werkzeug zur Erstellung von Child Themes, das aber mit Bedacht und mit entsprechenden vorherigen Sicherungen durchaus hilfreich ist. Wenn es nur um moderate, einmalige Anpassungen im Site Editor geht, kannst du auch ohne Child Theme auskommen und dich auf Editor‑Änderungen bzw. Stil‑Variationen beschränken.
Links, Quellen und aktuelle Infos
- https://learn.wordpress.org/lesson/use-the-create-block-theme-plugin-for-exports-and-theme-variations/
- https://learn.wordpress.org/lesson-plan/create-a-basic-child-theme-for-block-themes/
- https://olliewp.com/lesson/export-changes-with-create-block-theme/
- https://de.wordpress.org/plugins/create-block-theme/
- https://github.com/WordPress/create-block-theme
- https://de.wordpress.org/themes/ollie/
- https://kinsta.com/blog/customize-block-in-child-theme/
- https://haurand.com/plugin-create-block-theme-am-beispiel-twenty-twenty-three/
- https://haurand.com/block-themes-eine-einfuehrung/
- https://haurand.com/live-umstellung-von-classic-theme-zum-block-theme/
- https://einstieg-in-wp.de/block-theme-anpassen/
- https://de.wordpress.org/plugins/shrinking-logo-sticky-header/
- https://learn.wordpress.org/lesson-plan/create-a-basic-child-theme-for-block-themes/
Weitere Beiträge zum Thema (Block Neueste Beiträge)
- Child Theme mit Create Block Theme erstellen
- Block Theme: Template-Teil in Template einfügen
- theme.json: Globale Blöcke wie Buttons bei Block Themes gestalten
- Block Themes: Template mit geänderter Darstellung beim Beitragsbild (featured Image)
- Live auf der FrOSCon 2025: Umstellung von Classic Theme auf Block Theme
Wir freuen uns über eine Kontaktaufnahme
Was hältst du davon?
Wir hoffen, dieser Beitrag hat dir gefallen und wir würden uns über einen Kommentar freuen. Auch über Erweiterungen, Korrekturen, Hinweise oder sonstige Anmerkungen freuen wir uns sehr.
Newsletter: Wenn du über unsere neuesten Beiträge und Neuigkeiten rund um WordPress informiert werden möchtest, kannst du dich gerne bei unserem kostenlosen Newsletter anmelden. Hier die bisher versendeten Newsletter
Blog: Auf der folgenden Seite findest du weitere interessante Beiträge sortiert nach Kategorien und Schlagwörtern.

Schreibe einen Kommentar