{% style %}
#Overlay-{{ section.id }}::after {
opacity: {{ section.settings.overlay_opacity | divided_by: 100.0 }};
}
{% endstyle %}
{% schema %}
{ "settings": [
{ "type": "range", "id": "overlay_opacity", "unit": "%", "default": 40 }
] }
{% endschema %} Schluss mit Einmal-Code: Shopify-Anpassungen bauen, die dein Team wirklich selbst ändern kann
Kurze Antwort: Eine „füg diesen Code ein”-Lösung funktioniert — bis du den Wert ändern willst, und dann musst du jedes Mal wieder in den Code-Editor. Dieselbe Änderung als Theme-Editor-Setting zu bauen kostet ein paar Minuten mehr und gibt dir (oder deinem Kunden) einen Regler, den du für immer selbst verstellst, ganz ohne Entwickler. Das ist der Unterschied zwischen einem Wegwerf-Hack und einer Anpassung, die dir wirklich gehört.
Wenn du je die Shopify-Foren nach einer kleinen Änderung durchsucht hast — etwas mehr Abstand, ein dunkleres Bild-Overlay, eine andere Button-Farbe — kennst du das Muster. Die Top-Antwort ist fast immer „füg dieses CSS in dein Theme ein”. Es funktioniert. Du fügst ein, speicherst, sieht gut aus. Und einen Monat später willst du das Overlay einen Tick heller, und schon suchst du wieder in theme.liquid nach der Zeile. Bei Shopatch bauen wir das andersherum — hier ist der Ansatz, mit echtem Code, den du sofort nutzen kannst.
Warum kosten dich „füg diesen Code ein”-Lösungen später?
Ein eingefügtes Snippet kostet dich jede spätere Änderung, weil es einen Wert hartkodiert, den du mit ziemlicher Sicherheit ändern willst — und jede Änderung heißt: wieder den Code-Editor öffnen. Storefront-Anpassungen sind selten einmalig: Abstände werden neu justiert, wenn sich das Design ändert, ein Overlay wird für ein neues Hero-Bild nachgezogen, eine Button-Farbe wechselt mit der Saison-Kampagne. Über einen aktiven Shop und ein kleines Team wird diese Bequemlichkeit leise zur Wartungssteuer — meist bezahlt von dem, der sich im Code am wenigsten wohlfühlt.
Es gibt einen besseren Standard, und er steckt in jedem modernen Shopify-Theme (Online Store 2.0, Horizon inklusive): Leg den Wert hinter ein Setting, und er erscheint im Theme-Editor als Bedienelement, das jeder benutzen kann.
Wie machst du aus einer hartkodierten Lösung ein editierbares Theme-Setting?
Aus einer hartkodierten Lösung wird ein editierbares Setting, indem du den Wert im {% schema %} einer Section oder eines Blocks definierst — Shopify rendert ihn dann als Bedienelement im Theme-Editor. Unten ein häufiger Wunsch — ein einstellbares Bild-Overlay (eine dunkle Ebene, die Text über einem Foto lesbar hält) — in drei Stufen, von eingefrorenem CSS bis zum Live-Regler. Der eingebaute Bild-Banner hat diesen Regler schon; Multicolumn, Collection und Custom-Image-Sections meist nicht — genau deshalb landet der Wunsch ständig in den Foren.
Stufe 1 — Custom CSS (schnell, aber eingefroren und global)
Stufe 1 ist reines CSS, eingefügt in den Theme-Code — theme.liquid oder das Haupt-Stylesheet des Themes. Es funktioniert sofort:
.multicolumn-card__image-wrapper { position: relative; }
.multicolumn-card__image-wrapper::after {
content: ""; position: absolute; inset: 0;
background: rgba(0, 0, 0, 0.4);
}
Funktioniert — trifft aber jedes passende Element auf der Seite, die 0.4 ist hartkodiert, und zum Ändern musst du wieder in den Code. Für einen echten Einzelfall okay, in der Pflege mühsam.
Stufe 2 — Custom Liquid, gescopet, aber noch hartkodiert
Stufe 2 verschiebt dasselbe CSS in einen Custom-Liquid-Block, über die id auf genau diese Instanz begrenzt, damit es nicht auf alle Karten überschwappt:
<div class="overlay-{{ block.id }}">
<!-- dein Bild / Inhalt -->
</div>
{% style %}
.overlay-{{ block.id }} { position: relative; }
.overlay-{{ block.id }}::after {
content: ""; position: absolute; inset: 0;
background: rgba(0, 0, 0, 0.4);
}
{% endstyle %}
Das ist besser — keine Theme-Datei-Edits, wirkt nur auf diesen Block. Aber ein Custom-Liquid-Block hat keine eigenen Settings, also bleibt 0.4 im Code eingefroren. Hier hören die meisten „füg das ein”-Lösungen auf.
Stufe 3 — Eine Section mit eigenen Settings (der Editor-Regler)
Stufe 3 legt den Wert als range-Setting ins {% schema %} einer Section — Shopify macht daraus einen Regler im Theme-Editor, der Online-Store-2.0-Weg. Erstelle eine Section-Datei unter sections/image-with-overlay.liquid (Code bearbeiten → Sections → Neue Section hinzufügen):
{% style %}
#Overlay-{{ section.id }} { position: relative; display: grid; place-items: center;
min-height: {{ section.settings.min_height }}px; overflow: hidden; }
#Overlay-{{ section.id }} .overlay-media { position: absolute; inset: 0;
width: 100%; height: 100%; object-fit: cover; }
#Overlay-{{ section.id }}::after { content: ""; position: absolute; inset: 0;
background: {{ section.settings.overlay_color }};
opacity: {{ section.settings.overlay_opacity | divided_by: 100.0 }}; }
#Overlay-{{ section.id }} .overlay-content { position: relative; z-index: 1;
color: {{ section.settings.text_color }}; text-align: center; padding: 2rem; }
{% endstyle %}
<div id="Overlay-{{ section.id }}">
{% if section.settings.image %}
{{ section.settings.image | image_url: width: 2000 | image_tag:
class: 'overlay-media', loading: 'lazy', widths: '600,1000,1500,2000' }}
{% endif %}
<div class="overlay-content">
{% if section.settings.heading != blank %}<h2>{{ section.settings.heading }}</h2>{% endif %}
{{ section.settings.text }}
</div>
</div>
{% schema %}
{
"name": "Bild mit Overlay",
"settings": [
{ "type": "image_picker", "id": "image", "label": "Bild" },
{
"type": "range",
"id": "overlay_opacity",
"min": 0, "max": 100, "step": 5,
"unit": "%",
"label": "Overlay-Deckkraft",
"default": 40
},
{ "type": "color", "id": "overlay_color", "label": "Overlay-Farbe", "default": "#000000" },
{ "type": "color", "id": "text_color", "label": "Textfarbe", "default": "#ffffff" },
{
"type": "range",
"id": "min_height",
"min": 200, "max": 800, "step": 20,
"unit": "px",
"label": "Section-Höhe",
"default": 400
},
{ "type": "text", "id": "heading", "label": "Überschrift", "default": "Deine Überschrift" },
{ "type": "richtext", "id": "text", "label": "Text" }
],
"presets": [{ "name": "Bild mit Overlay" }]
}
{% endschema %}
Jetzt zieht der Merchant Overlay-Deckkraft im Editor und fasst nie wieder Code an.
Warum taucht meine Custom-Section nicht im Theme-Editor auf?
Eine Custom-Section fehlt fast immer, weil ihrem {% schema %} der presets-Schlüssel fehlt — genau dieser Schlüssel macht eine Section unter Section hinzufügen auswählbar. Zwei weitere Details lassen die Settings zu Editor-Bedienelementen werden:
- Jeder Eintrag unter
"settings"wird zum Bedienelement im Section-Panel:rangeist ein Regler,colorein Farbwähler,text/richtextsind Textfelder,checkboxist ein Schalter. - Scope das CSS auf
#Overlay-{{ section.id }}, damit du die Section zehnmal mit zehn verschiedenen Overlays einsetzen kannst, ohne dass etwas kollidiert.
Ein kleiner Stolperstein: Ein range liefert eine Zahl von 0 bis 100, für CSS-Deckkraft also durch 100 teilen — | divided_by: 100.0. Nimm 100.0 mit Komma, sonst rechnet Liquid ganzzahlig und rundet deine Deckkraft auf 0 ab.
(Fortgeschritten: Dasselbe Schema funktioniert als Theme-Block in /blocks/. Dort ebenfalls "presets" setzen und in jede Section einbauen, die "blocks": [{ "type": "@theme" }] deklariert und {% content_for 'blocks' %} rendert; dann block.settings… referenzieren.)
Welche Shopify-Anpassungen sollten Settings statt Code sein?
Jede Anpassung, deren Wert du je wieder ändern könntest, sollte ein Setting statt hartkodiertem Code sein. Die häufigsten Beispiele in den Shopify-Foren sind Abstände zwischen Sections, Schriftgrößen mobil versus Desktop, Button- und Hover-Farben, ein Sold-out-Badge ausblenden und ein Sticky-Header — jedes ist ein fester Wert, der sauber auf ein range, checkbox oder color abbildet. Tausch die hartkodierte Zahl gegen ein range, das An/Aus gegen ein checkbox, die Farbe gegen ein color, und die Anpassung ist keine Entwickler-Aufgabe mehr, sondern ein Bedienelement auf der Seite.
Wann ist ein schnelles Snippet trotzdem richtig?
Ein Snippet einzufügen ist richtig, wenn der Wert sich wirklich nie ändert — ein globaler Reset oder ein dauerhafter Marken-Fix. Faustregel: Wenn du dir vorstellen kannst, dass irgendwer den Wert je ändern will, investier die paar Extra-Minuten, um ihn zu einem editierbaren Setting zu machen. Es zahlt sich schon beim ersten Mal aus, wenn du den Code-Editor gerade nicht öffnen musst.
Löscht ein Theme-Update meine Anpassungen?
Ja — ein Shopify-Theme-Update kann Anpassungen löschen, weil ein Theme-Update eine frische Kopie des Themes installiert, statt deine Änderungen zusammenzuführen. Jeder Code, den du direkt in den Kern-Dateien des Themes bearbeitet hast — seine Sections, Snippets und Assets — wird beim Veröffentlichen der neuen Version nicht übernommen. Bei einem stark angepassten Theme ist das der häufigste Weg, wie wochenlange Arbeit still verschwindet.
Vier Gewohnheiten verhindern das:
- Halte Custom-Code in eigenen Dateien. Neue Sections, Blocks und Snippets, die du hinzufügst (wie die Image-with-overlay-Section oben), sind in sich abgeschlossen — du kopierst sie in Minuten in die neue Theme-Version, statt verstreute Edits in den Kern-Dateien neu nachzuziehen.
- Erfasse so viel wie möglich als Settings, nicht als Code. Werte, die als Theme-Settings gespeichert sind, liegen in den JSON-Templates und der Config und sind weit portabler als Inline-Code-Edits — noch ein Grund, warum der Regler-Ansatz hier sich auszahlt.
- Stell das Theme unter Versionskontrolle. Verbinde es via Shopify CLI oder GitHub-Integration mit Git, sodass jede Änderung nachvollziehbar und diffbar ist — die Migration auf eine neue Version wird zu „diese bekannten Änderungen anwenden” statt Rätselraten.
- Aktualisiere nie das Live-Theme direkt. Dupliziere es, spiel die neue Version auf der Kopie ein, migriere und teste deine Anpassungen dort, und veröffentliche erst dann.
Der rote Faden ist derselbe wie im ganzen Beitrag: Je mehr deine Anpassungen als Settings und eigenständige Dateien leben statt als verstreute Code-Edits, desto weniger kann ein Theme-Update dir wegnehmen.
Soll das direkt in deinem Shop stecken?
Genau das machen wir bei Shopatch — Anpassungen, die dein Team wirklich selbst bedienen kann, statt fragiler Snippets, die dich für jede Kleinigkeit wieder zum Entwickler schicken. Wenn dein Shop aus lauter „füg das ein”-Lösungen zusammengesetzt ist, machen wir aus den wichtigen davon saubere, editierbare Settings, die Theme-Updates überleben. Melde dich und erzähl uns, was du immer wieder ändern musst.