Theme-Update ohne Verlust Deiner Anpassungen: Das Prüfsummen-Verfahren

Ein Theme-Update klingt nach einem Knopfdruck, und bei vielen Shops ist es das auch. Shopify legt die neue Version als Kopie in Deine Theme-Bibliothek und nimmt Deine Einstellungen aus dem Theme-Editor mit. Schwieriger wird es, wenn im Code des Themes viel geändert wurde.

So ein Fall ist FRANK ORIGINAL, ein Hersteller mit Händlerkunden. Der Shop baut auf dem gekauften Theme Maranello auf, das wir stark erweitert haben. Im Theme stecken das Ausblenden der Preise, die Anbindung der B2B-App SparkLayer und eine Reihe eigener Sections und Templates. Für dieses Theme habe ich ein Verfahren festgelegt, mit dem die Anpassungen auf eine neue Maranello-Version mitkommen.

Ich erkläre hier zuerst, was Shopify selbst kann, und danach das Verfahren für den Rest. Es ist ein Beispiel aus einem Projekt. Für viele Shops gibt es einfachere Wege, und die stehen mit ihren Grenzen in Abschnitt 6.

1Was Shopify bei einem Theme-Update selbst übernimmt

Shopify hat die Update-Funktion im Admin im Februar 2022 eingeführt. Damals galt sie nur für Themes, an deren Code weder Du noch eine App etwas geändert hatte. Inzwischen beschreibt das Help Center von Shopify mehr.

Gibt es für Dein Theme eine neue Version, zeigt Shopify das am Theme in der Bibliothek an. Du fügst die neue Version als Entwurf hinzu, und Shopify legt sie als eigene Kopie neben Dein Live-Theme. Der Live-Shop läuft so lange unverändert weiter, bis Du die Kopie veröffentlichst. Die Versionshinweise des Theme-Entwicklers kannst Du vorher lesen.

In diese Kopie übernimmt Shopify alles, was Du im Theme-Editor gemacht hast. Dazu gehören die Theme-Einstellungen, die Anordnung der Sections und Blöcke, eigene Templates und App-Einbettungen. Änderungen im Code kommen mit, solange sie nicht mit dem Update kollidieren. Dann meldet Shopify, dass die Code-Änderungen enthalten sind. Bei einem Konflikt steht dort, dass sie nicht übernommen werden konnten, und Du trägst sie in der neuen Version von Hand nach.

Fehlerbehebungen und Sicherheitskorrekturen spielt Shopify laut Help Center automatisch ein, ohne dass sich Aussehen oder Inhalt Deines Shops ändern. Die Update-Funktion gibt es allerdings nur für Themes aus dem Shopify Theme Store. Ein Theme, das Du woanders gekauft oder als Datei hochgeladen hast, bekommt keinen Update-Hinweis.

Wenn Du Dein Theme also nur im Theme-Editor angepasst hast, brauchst Du das Verfahren weiter unten nicht. Du fügst das Update hinzu, schaust Dir die Vorschau an und veröffentlichst. Wie sich gekaufte und eigene Themes bei Updates unterscheiden, steht im Beitrag zu Custom Theme oder gekauftem Theme.

2Wo die eingebaute Funktion aufhört

Die Funktion endet beim Konflikt. Shopify sagt Dir dann, dass Deine Code-Änderungen fehlen, führt die beiden Stände aber nicht für Dich zusammen. Das Help Center empfiehlt für diesen Fall, die eigenen Änderungen vorher mit einem Werkzeug aus dem App Store zu erfassen und sie danach in die neue Version zu kopieren.

Bei zwei oder drei geänderten Dateien ist das noch überschaubar. Du weißt ja, wo Du etwas geändert hast, und kopierst die Stellen hinüber. Bei einem stark erweiterten Theme sieht das anders aus. Dort gibt es eigene Dateien, die der Theme-Entwickler gar nicht kennt, und Originaldateien, in denen wir etwas geändert haben. Mit dem Update ändert der Entwickler einen Teil dieser Originaldateien ebenfalls.

Dabei kann man auf zwei Arten danebenliegen. Wer die neue Version nimmt und die Anpassungen aus dem Gedächtnis nachträgt, vergisst leicht eine. Bei einem Shop, der Preise nur eingeloggten Händlern zeigt, wäre so eine Lücke sofort sichtbar. Wer umgekehrt alle abweichenden Dateien aus dem alten Theme über die neue Version kopiert, überschreibt damit auch die Verbesserungen, für die er das Update eigentlich macht.

Für das Theme von FRANK ORIGINAL wollte ich deshalb einen Ablauf, der sich wiederholen lässt. Vor dem Schreiben soll feststehen, was mit jeder einzelnen Datei passiert.

3Das Prüfsummen-Verfahren: zwei Stände, vier Fälle

Verglichen werden zwei Themes im selben Shop. Das eine ist das Live-Theme mit allen Anpassungen. Das andere ist die frische neue Version des Theme-Entwicklers, die als unveröffentlichtes Theme daneben liegt und an der noch niemand etwas geändert hat.

Für jede Datei eines Themes liefert die Admin GraphQL API von Shopify eine MD5-Prüfsumme, das Feld heißt checksumMd5. Eine Prüfsumme ist ein kurzer Fingerabdruck des Dateiinhalts. Haben zwei Dateien dieselbe Prüfsumme, ist ihr Inhalt gleich. Ich lese deshalb zuerst nur die Dateinamen und Prüfsummen beider Themes und noch keine Inhalte. Das geht auch bei einem großen Theme schnell, weil ja noch kein Inhalt geladen wird.

Aus dem Vergleich der beiden Listen ergibt sich für jede Datei einer dieser Fälle.

Die Einteilung macht ein kleines Skript. Sie ist reine Mechanik, und so kommt bei jedem Lauf dasselbe heraus. Die ersten drei Fälle erledigen sich damit von allein. Eigene Dateien wandern hinüber, neue Dateien des Entwicklers bleiben, und was gleich ist, braucht niemand anzufassen.

Der vierte Fall braucht ein Urteil

Weicht die Prüfsumme ab, weiß man erstmal nur, dass die Datei in beiden Themes verschieden ist. Offen ist, wer sie geändert hat. Für jede dieser Dateien lese ich deshalb den Inhalt aus beiden Themes und sehe mir die Unterschiede an.

Trägt der Unterschied die Merkmale unserer Anpassungen, kommt die Datei aus dem Live-Theme in die neue Version. Bei FRANK ORIGINAL erkennt man das zum Beispiel an den Aufrufen der B2B-App oder an der Stelle, an der die Preise ausgeblendet werden. Diese Merkmale stehen in einer Liste, die zum Projekt gehört. Stammt der Unterschied nur vom Theme-Entwickler, bleibt die neue Datei. Haben beide Seiten dieselbe Datei geändert, führe ich die Änderungen zusammen, zum Beispiel mit git merge-file. Was sich dabei nicht sauber auflösen lässt, wird markiert und kommt in den Bericht.

Das Verfahren hat eine Grenze. Ohne eine unangetastete Kopie der alten Theme-Version lässt sich im vierten Fall nicht beweisen, ob eine Änderung von uns oder vom Entwickler kommt. Man erkennt es nur an den Merkmalen, und deshalb gehört jede dieser Dateien in den Bericht. Wer bei jeder Installation eine unberührte Kopie der eingesetzten Version aufbewahrt, hat es beim nächsten Update leichter.

4Der Freigabe-Bericht und das Schreiben ins neue Theme

Bevor irgendetwas geschrieben wird, gibt es einen Bericht. Darin steht, wie viele Dateien in welchen Fall gehören und welche eigenen Dateien übernommen werden. Jede Datei aus dem vierten Fall ist einzeln aufgeführt, mit der Einordnung und einem Satz Begründung. Offene Konflikte stehen am Ende. Erst wenn dieser Bericht bestätigt ist, wird geschrieben.

Geschrieben wird ausschließlich in das neue, unveröffentlichte Theme. Das Live-Theme fasst das Verfahren nicht an, und veröffentlicht wird auch nicht automatisch. Das macht am Ende ein Mensch von Hand. Technisch läuft das Schreiben über die Mutation themeFilesUpsert, die laut Dokumentation höchstens 50 Dateien je Aufruf annimmt. Größere Mengen gehen deshalb in mehreren Stapeln hinüber. Danach lese ich die Prüfsummen des neuen Themes noch einmal und vergleiche sie mit dem, was hineingeschrieben werden sollte.

Was im Shop selbst liegt, ist von alldem nicht betroffen. Produkte, Kollektionen, Menüs, Metafelder und die Daten Deiner Apps bleiben bei einem Theme-Update ohnehin erhalten. Übertragen wird nur, was im Theme liegt.

Was davon ein KI-Assistent übernimmt

Ich mache das halb automatisiert mit einem KI-Assistenten, der über die Admin-API auf den Shop zugreifen darf. Er liest die beiden Dateilisten, lässt das Skript für die Einteilung laufen, bildet die Unterschiede für den vierten Fall und schreibt den Bericht. Die Einordnung schlägt er vor, die Entscheidung treffe ich. Geschrieben wird auch hier erst nach meiner Freigabe.

Ganz automatisch würde ich es nicht laufen lassen. Ob eine Änderung von uns stammt, muss jemand beurteilen, der das Projekt kennt, und ein Fehler landet in einem Theme, das später live geht. Dazu kommt eine technische Hürde. Wer das über eine eigene App nachbauen will, braucht den Zugriff write_themes. Shopify verlangt laut Dokumentation für Apps, die Theme-Dateien ändern, zusätzlich eine Ausnahmegenehmigung.

5Was nach dem Update geprüft wird

Das neue Theme hat eine Vorschau, und dort wird geprüft, bevor es live geht. Die Prüfliste ergibt sich aus den Anpassungen. Für das Theme von FRANK ORIGINAL stehen diese Punkte darauf.

• Eingeloggte Händler sehen ihre B2B-Preise.
• Ohne Login sind die Preise ausgeblendet.
• Die eigenen Produkt-Templates zeigen ihre Inhalte.
• Der Weg vom Warenkorb in den Checkout funktioniert.
• In den strukturierten Daten der Seite stehen keine Preise.
• Die App-Einbettungen sind im neuen Theme aktiv.

Für Deinen Shop sähe die Liste natürlich anders aus. Ein Prüfpunkt je Anpassung ist ein guter Anfang, und eine Testbestellung schadet auch nicht. Wenn alles passt, wird das neue Theme veröffentlicht. Das alte bleibt in der Theme-Bibliothek liegen, und Du kannst es wieder veröffentlichen, falls doch etwas fehlt.

In der Checkliste für Black Friday beginnt Mitte Oktober der Freeze, und ab dann gibt es keine Theme-Umbauten mehr. Ein Theme-Update gehört für mich in die Zeit davor oder danach.

6Andere Wege und wann sie besser passen

Das Verfahren ist für ein Theme mit viel eigenem Code gedacht. Für viele Shops ist einer der folgenden Wege einfacher, und ein paar davon kosten nichts.

Die Update-Funktion im Admin

Mit ihr würde ich anfangen, auch bei einem Theme mit Code-Änderungen. Das Update landet als Kopie in der Bibliothek, am Live-Shop ändert sich dadurch also nichts. Meldet Shopify, dass alle Code-Änderungen enthalten sind, reicht ein Blick in die Vorschau.

Eine Updater-App

Im App Store gibt es die App Theme Updater & Backups von Out of the Sandbox. Sie überträgt laut Beschreibung auch Code-Änderungen auf die neue Version und legt Sicherungen an. Unterstützt werden Dawn und die Themes einiger Entwickler, darunter Archetype, Clean Canvas, Krown, Pixel Union und Troop. Es gibt eine kostenlose Stufe, die Pro-Stufe kostet 9 US-Dollar im Monat (Stand 1. Oktober 2026). Bei komplexen Anpassungen kann laut Beschreibung der Support der App nötig sein. Maranello stand am 1. Oktober 2026 nicht in der Liste der unterstützten Themes.

Von Hand aus dem Changelog

In der laufenden Migration eines Fachhändlers bauen wir auf dem kostenlosen Theme Horizon auf. Updates übernehmen wir dort von Hand. Wir lesen den Changelog von Shopify und tragen nach, was für den Shop wichtig ist. Das passt, wenn ein Theme ohnehin als eigenes Theme weiterentwickelt wird. Es braucht dann aber auch jemanden, der die Changelogs verfolgt.

Das Theme in Git führen

Wer sein Theme in einem Git-Repository führt, bekommt ein Update als Merge. Git zeigt Konflikte Zeile für Zeile, und die GitHub-Integration von Shopify hält einen Branch und ein Theme in beide Richtungen synchron. In Entwicklerteams ist das ein verbreiteter Weg. Er setzt voraus, dass das Theme im Repository liegt und jemand im Team mit Git umgehen kann. Die Dateien holt und schreibt die Shopify CLI mit theme pull und theme push. Beim Holen löscht sie lokale Dateien, die es im Theme nicht gibt, wenn Du das Flag --nodelete weglässt.

Anpassungen, die nicht im Theme-Code liegen

Am wenigsten Arbeit macht ein Update, wenn die Anpassung gar nicht im Code des Themes steht. Apps, die mit App Blocks und App-Einbettungen arbeiten, bringen ihren Code in einer eigenen Erweiterung mit, das Theme selbst bleibt unverändert. Worauf es bei der Auswahl von Apps sonst ankommt, steht im Beitrag zu den Apps.

Kleine optische Korrekturen passen in das Feld für eigenes CSS im Theme-Editor. Es fasst laut Shopify 1.500 Zeichen für das ganze Theme und 500 Zeichen je Section. Nach einem Update solltest Du dieses CSS prüfen, weil sich die Selektoren im Theme geändert haben können. Und wenn schon Code nötig ist, hilft eine eigene Section in einer eigenen Datei mehr als ein Umbau der Originaldatei. Sie zählt beim nächsten Update als eigene Datei und wandert einfach mit.