Themes und Storefront-Architektur

Themes und Storefront-Architektur

0:00 Ein Theme auszuwählen fühlt sich an wie eine Designentscheidung. Man sieht Vorschaubilder, wählt das schönste, fertig. Tatsächlich wählen Sie damit eine Struktur — und die entscheidet, was Ihre Redaktion in zwei Jahren noch selbst ändern kann und wofür sie jedes Mal die Entwicklung braucht. Deshalb sehen wir uns in diesem Modul an, wie ein Theme aufgebaut ist, wie Templates, Sections und Blocks zusammenspielen und wo die Grenze zwischen Einstellung und Code verläuft.

0:25 Am Ende bauen Sie drei Seiten aus denselben Bausteinen.

Themes und Storefront-Architektur

0:29 Willkommen zu Tag zwei. Gestern ging es um Plattform, Verwaltung und Daten — heute wird das alles sichtbar. Wir starten mit dem Aufbau eines Themes, gehen dann eine Ebene tiefer zu Templates, Sections und Blocks, klären danach, wie Sie Gestaltungsänderungen sicher ausliefern, und schließen mit der Frage, die jedes Theme über die Jahre entscheidet: Bleibt es updatefähig?

0:51 Die Übung ist eine kleine Storefront für Steglicht — Startseite, Kollektionsseite, Produktseite, aus wiederverwendbaren Teilen.

Aufbau eines Shopify-Themes

0:59 Sehen wir uns zuerst an, woraus ein Theme überhaupt besteht. Acht Ordner, jeder mit einer klaren Aufgabe — und einer davon ist als einziger zwingend. Ein Theme ist ein Verzeichnis mit fester Struktur, vergleichbar mit einem Bauplan, bei dem jeder Raum eine festgelegte Funktion hat. Es gibt Layout, Templates, Sections, Blocks, Snippets, Assets, Config und Locales.

1:22 Zwingend ist allein das Layout mit der Datei theme.liquid — sie umschließt alle Templates und trägt die wiederkehrenden Elemente wie Kopf- und Fußbereich. Alles andere ist optional, aber praktisch immer vorhanden. Der Wert dieser Festlegung liegt in der Wiedererkennbarkeit: Wer ein Shopify-Theme kennt, findet sich in jedem anderen zurecht.

1:43 Lesen Sie diese Tabelle nicht als Dateiliste, sondern als Zuständigkeitsverteilung. Das Layout trägt, was auf jeder Seite gleich ist. Templates bestimmen, wie eine Seitenart gerendert wird — Produkt, Kollektion, Seite. Sections sind die wiederverwendbaren Inhaltsmodule, Blocks die Bausteine darin. Snippets sind kleine Code-Fragmente für Wiederkehrendes, Config hält die Einstellungen als JSON, Locales die Übersetzungen.

2:09 Der Ordner assets trägt Bilder, CSS und JavaScript — und mit der Endung Punkt liquid sogar dynamisch erzeugte Dateien. Das ist eine Besonderheit, die man selten braucht und dann sehr schätzt. Hier steckt eine Falle für Projekte mit Bestandsshops. Shopify unterscheidet drei Theme-Generationen, und die Unterschiede sind erheblich.

2:30 Vintage-Themes bekommen nur noch Sicherheitsaktualisierungen, keine Funktionen mehr — wer so eines anpasst, investiert in eine Sackgasse. Online Store 2.0 brachte Sections auf allen Seiten und JSON-Templates. Die neueste Generation ergänzt Theme Blocks, die über Sections hinweg wiederverwendbar sind. Und jetzt der Punkt, den man leicht übersieht: Die Architektur-Version hängt am einzelnen Theme, nicht am Shop. Zwei Themes im selben Shop können in verschiedenen Welten leben.

2:59 Der erste Punkt ist eine ausdrückliche Empfehlung von Shopify: Themes nicht außerhalb des Theme Store beziehen. Das klingt nach Marktschutz, hat aber praktische Gründe — Qualität, Kompatibilität, Aktualisierung. Der zweite ist der eben besprochene: ein Vintage-Theme anpassen, statt es abzulösen. Der dritte ist eine Frage, die in Bestandsprojekten am Anfang stehen sollte und es fast nie tut: In welcher Architektur-Version lebt das vorhandene Theme?

3:26 Und der vierte beschreibt, wie Themes über Jahre unwartbar werden — Anpassungen landen in Snippets, die niemand mehr einem Template zuordnet.

Templates, Sections und Blocks

3:35 Jetzt eine Ebene tiefer. Vier Ebenen bauen jede Seite zusammen, und nur zwei davon bekommt die Redaktion je zu Gesicht. Die Hierarchie ist einfach: Layout umschließt Templates, Templates rendern Sections, Sections enthalten Blocks. Ein wichtiger Zusatz: JSON-Templates sind reine Hüllen für Sections — der eigentliche Code steckt in Liquid-Templates.

3:56 Das erklärt, warum die Redaktion in modernen Themes so viel selbst umsortieren kann: Sie bewegt Sections in einer JSON-Datei, ohne Code anzufassen. Section Groups gehen noch einen Schritt weiter und machen auch Bereiche wie Kopf und Fuß im Editor umsortierbar. Früher waren das die Bereiche, für die man zwingend Entwicklung brauchte.

4:16 Diese Kette zeigt, in welcher Reihenfolge eine Seite entsteht — und damit auch, wo Sie ansetzen müssen, wenn etwas geändert werden soll. Soll sich etwas auf allen Seiten ändern, gehört es ins Layout. Betrifft es eine Seitenart, ist es das Template. Ist es ein wiederkehrender Inhaltsblock, eine Section. Und geht es um ein einzelnes Element darin, ist es ein Block.

4:38 Diese Zuordnung klingt akademisch, spart aber die häufigste Art von Arbeit: dieselbe Änderung an fünf Stellen zu pflegen, weil sie auf der falschen Ebene sitzt. Hier lohnt die Unterscheidung. Theme Blocks liegen als eigene Liquid-Dateien im Ordner blocks und sind über mehrere Sections hinweg wiederverwendbar — Sie bauen einen Block einmal und setzen ihn überall ein.

4:59 Section Blocks dagegen kennen nur eine Hierarchieebene und lassen sich nicht schachteln. Und ein Detail, das im Editor oft Fragen auslöst: Statische Blöcke können von der Redaktion ausgeblendet, aber nicht gelöscht werden. Das ist kein Fehler, sondern Absicht — manche Elemente sollen an ihrem Platz bleiben, auch wenn sie gerade nicht gebraucht werden.

5:19 Der erste Punkt ist die häufigste Ursache für unwartbare Themes: Für jede Seite entsteht ein eigenes Template, statt eine Section wiederzuverwenden. Der zweite nennt eine harte Grenze — ein Theme trägt höchstens 300 Theme Blocks. Das klingt nach viel, bis man den dritten Punkt liest: KI-erzeugte Blöcke zählen mit, auch wenn keine Section sie verwendet.

5:39 Wer mit erzeugten Blöcken experimentiert, sollte also aufräumen. Und der vierte ist der, der die Redaktion lähmt: Inhalte werden hart in Sections geschrieben und sind danach nur noch über die Entwicklung änderbar.

Theme Settings und Veröffentlichung

5:52 Kommen wir zur Arbeitsweise. Wie liefern Sie eine Gestaltungsänderung aus, ohne dass die Kundschaft beim Zusehen zuschaut? Theme Settings liegen als JSON im Ordner config und geben der Redaktion die Stellschrauben vor: Farben, Schriften, Abstände, Bildverhalten. Sie sind die Leitplanken des Themes — was dort nicht vorgesehen ist, verlangt Code.

6:13 Und beim Veröffentlichen gilt eine einfache Regel: Es ist immer genau ein Theme veröffentlicht, alle anderen bleiben Entwürfe. Diese Trennung ist Ihr wichtigstes Werkzeug. Sie erlaubt es, in Ruhe an einer Fassung zu arbeiten, während die alte weiter verkauft — und im Zweifel wieder zurückzuschalten. Der rote Faden: nie am Original arbeiten. Duplizieren Sie das veröffentlichte Theme und setzen Sie die Änderung im Duplikat um.

6:38 Dann prüfen Sie in der Vorschau — und zwar nicht nur am Desktop, sondern auf schmaler Breite und mit der Tastatur; warum, sehen wir in Modul acht. Danach veröffentlichen Sie das Duplikat und behalten das vorherige Theme als Entwurf. Und der letzte Schritt ist der, den alle überspringen: Nach dem Umschalten Startseite, Kollektion, Produkt und Warenkorb tatsächlich ansehen.

7:00 Das dauert zwei Minuten und findet erstaunlich viel. Diese vier Punkte beschreiben, warum die scheinbar mühsamere Lösung oft die günstigere ist. Einstellungen überleben ein Theme-Update, geänderter Code nicht zwangsläufig. Die Redaktion arbeitet ohne Entwicklung und ohne Freigabezyklus — das ist nicht nur billiger, es ist schneller. Änderungen sind im Editor sichtbar und damit nachvollziehbar.

7:24 Und der vierte Punkt ist der nüchternste: Jede Codezeile im Theme ist Pflegeaufwand bei jeder künftigen Version. Das ist kein Argument gegen Code. Es ist ein Argument dafür, ihn bewusst und sparsam einzusetzen. Der erste Punkt ist die Abkürzung, die jeder einmal nimmt: schnell etwas am veröffentlichten Theme ändern — und die Kundschaft sieht es sofort, inklusive der Zwischenstufen.

7:47 Der zweite ist der, der Nerven kostet: Das alte Theme wird nach dem Wechsel gelöscht. Damit ist der schnellste Rückweg weg. Der dritte ist tückisch: Einstellungen werden im Duplikat gesetzt und gehen beim nächsten Update unter, weil niemand sie übertragen hat. Und der vierte ist eine Illusion, die wir gleich in Modul acht zerlegen: Die Vorschau ersetzt die Prüfung auf echten Geräten nicht.

Erweiterung und Updatefähigkeit

8:10 Bleibt die Frage, wie Funktionen ins Theme kommen, ohne dass es beim nächsten Update auseinanderfällt. Theme App Extensions sind die Antwort, die Shopify darauf gibt. Apps binden ihre Funktionen als App Blocks ein, ohne den Theme-Code zu verändern. Der Vorteil steht wörtlich in der Dokumentation: Weil diese Apps den Theme-Code nicht bearbeiten, sinkt das Risiko, beim Aktualisieren etwas zu zerbrechen.

8:34 Dazu kommt ein praktischer Nebeneffekt, der im Alltag mehr zählt als die Technik: Die Redaktion setzt diese Blöcke selbst im Editor, an der Stelle, an der sie sie haben will. Kein Ticket, kein Release. Diese Tabelle hat bewusst eine dritte Spalte mit der Überschrift Preis — weil jeder Weg einen hat. Die Theme-Einstellung ist updatefest und kommt ohne Entwicklung aus, kann aber nur, was vorgesehen ist.

8:58 Der App Block greift nicht in den Theme-Code ein, schafft aber eine Abhängigkeit vom Anbieter. Und eigener Code in Liquid, CSS oder JavaScript kann alles, kostet dafür Pflege bei jedem Update. Ein technischer Hinweis, der Vertrauen schafft: App-Erweiterungen werden versioniert und über das CDN von Shopify ausgeliefert. Sie sind also kein Fremdkörper.

9:19 Der erste Punkt ist der teuerste Rest, den Projekte hinterlassen: Ein App-Skript wird von Hand ins Theme kopiert und bleibt nach der Deinstallation liegen. Es lädt weiter, kostet Ladezeit und niemand weiß, wozu es gehört. Der zweite ist der Grund, warum Theme-Wechsel so teuer werden — Anpassungen sind nicht dokumentiert, und die Liste fehlt.

9:39 Der dritte ist ein Versprechen, das man nicht halten kann: Updatefähigkeit bei einem Theme mit zwanzig Eingriffen. Und der vierte ist Planungsarbeit: Der App Block sitzt in einem Template, das beim nächsten Relaunch entfällt.

Übung

9:52 Jetzt bauen Sie. Drei Seiten für Steglicht — und die eigentliche Aufgabe besteht darin, sie eben nicht dreimal zu bauen. Steglicht braucht drei Seitenarten. Eine Startseite mit Themenblöcken, eine Kollektionsseite für Arbeitsplätze und eine Produktseite mit Variantenauswahl, Lieferzeit und Vertrauenshinweisen. Alle drei sollen aus denselben Bausteinen entstehen.

10:14 Das ist die Übung, und es ist auch der Test: Wenn Sie hinterher eine Änderung an einem gemeinsamen Element vornehmen und sie an drei Stellen sichtbar wird, haben Sie richtig gebaut. Wenn Sie dieselbe Änderung dreimal machen müssen, wissen Sie, woran Sie beim nächsten Mal arbeiten. Das Lernziel bringt es auf den Punkt: Eine Storefront so zusammensetzen, dass die Wiederholung im Theme landet und nicht in der Redaktion.

10:38 Erfolgreich sind Sie, wenn die drei Seiten stehen, mindestens zwei Sections auf mehreren Seiten im Einsatz sind und Sie je Anpassung notiert haben, ob Einstellung, App Block oder Code nötig war. Diese Notiz ist wichtiger, als sie aussieht — sie ist der Anfang der Dokumentation, die beim nächsten Theme-Wechsel fehlt. Und wer früh fertig ist, prüft die drei Seiten zusätzlich mit der Tastatur.

11:00 Fünfzig Minuten. Duplizieren Sie zuerst das veröffentlichte Theme — das ist nicht Bürokratie, das ist die Übung. Dann skizzieren Sie die drei Seiten auf Papier und markieren, was sich wiederholt. Diese wiederkehrenden Bereiche bauen Sie als Sections und setzen sie überall ein. Notieren Sie je Anpassung den gewählten Weg und seinen Pflegeaufwand. Und zum Schluss zeigen Sie das Ergebnis in der Vorschau und begründen, was Sie warum wiederverwendet haben.

11:26 Die Begründung ist das, was Sie mitnehmen — die Seiten bleiben hier. Vier Muster, die Sie gleich beobachten können. Erstens: Jede Seite wird einzeln gebaut, und die Wiederholung fällt erst auf, wenn man etwas ändern soll. Zweitens: Die Produktseite wird um Inhalte ergänzt, die eigentlich als Metafeld gehören — erinnern Sie sich an Modul drei.

11:47 Drittens: Das Duplikat wird am Ende nicht veröffentlicht, und die ganze Arbeit bleibt unsichtbar. Und viertens: Die Anpassungen werden nicht notiert. Dann beginnt beim nächsten Theme alles von vorn — und zwar bei null, nicht bei den Erkenntnissen von heute.