Eigener Code (CSS & JavaScript)

Die Karte „Eigener Code — nur vertrauenswürdige Administratoren" bietet drei Felder, um eigenes CSS und JavaScript einzuschleusen — für schnelle Anpassungen und für Tracking-/Tag-Manager-Snippets, ohne dafür das Theme neu bauen zu müssen. Der Code gilt auf jeder Storefront-Seite.

Das ist vollständige Codeausführung

Die Inhalte werden absichtlich ungefiltert ausgegeben. JavaScript läuft mit den Möglichkeiten der Storefront im Browser aller Besucher: Es kann Inhalte und Formulare lesen oder verändern, Anfragen im Kontext der Sitzung auslösen und Daten an Dritte übertragen. Trag hier ausschließlich geprüften Code aus einer vertrauenswürdigen Quelle ein.

Wo finde ich die Felder

Erweiterungen → Meine Erweiterungen → Indigo7 Boutique-Theme → ••• → Konfiguration → Karte „Eigener Code — nur vertrauenswürdige Administratoren".

Wer darf diese Felder verändern?

Shopware schützt die Felder über seine globalen Rechte für die Systemkonfiguration:

Aktion	benötigte ACL-Rechte
Konfiguration anzeigen	`system_config:read`
Konfiguration speichern	`system_config:create`, `system_config:update` und `system_config:delete`

Administratoren besitzen diese Rechte automatisch. Eine eingeschränkte Rolle kann die Felder speichern, sobald sie die genannten globalen Schreibrechte hat. Die Freigabe ist nicht auf das Boutique-Theme beschränkt: Die Rolle kann damit auch andere System- und Plugin-Konfigurationen verändern. Vergib diese Rechte daher nur an Personen, denen du auch vollständigen Storefront-Code anvertrauen würdest.

Die Felder sind ohne Inhalt inaktiv; separate Aktivierungsschalter gibt es bewusst nicht. Ein zusätzlicher Schalter würde bestehende Installationen beim Update entweder unerwartet deaktivieren oder ohne Sicherheitsgewinn standardmäßig aktiv bleiben.

Die drei Felder im Überblick

Feld	Wird eingefügt …	Wofür	Eigenes `<script>` nötig?
Eigenes CSS	als `<style>` im `<head>`, nach dem Theme-CSS	Style-Overrides, schnelle Fixes	Nein — nur CSS
Eigenes Head-JS	im `<head>`, läuft vor dem Seiteninhalt	Analytics, Tag-Manager, Consent	Ja
Eigenes Footer-JS	direkt vor `</body>`, nach dem DOM	Widgets, unkritische Skripte	Ja

So gibt man es richtig ein

CSS — nur CSS, kein `<style>`

Das CSS-Feld wird automatisch in ein <style>-Tag gefasst. Trag also nur die Regeln ein:

css

.product-detail-name { letter-spacing: .02em; }

Da das CSS nach dem Theme-Stylesheet eingefügt wird, gewinnt es im Zweifel und überschreibt Theme-Styles.

Head-JS & Footer-JS — immer mit eigenem `<script>`

Diese beiden Felder werden unverändert ausgegeben. Du gibst dein eigenes <script>-Tag an. Dadurch lassen sich fertige Analytics-/Tag-Manager-Snippets 1:1 einfügen, Attribute nutzen (async, defer, src) und mehrere Skripte kombinieren.

Beispiel Head-JS (Google-Tag / GA4 — komplettes Snippet inkl. eigener Tags):

html

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

Beispiel Footer-JS (läuft, wenn das DOM steht):

html

<script>
  document.addEventListener('DOMContentLoaded', () => {
    // … hier auf Elemente der Seite zugreifen …
  });
</script>

Kein <script>? Dann läuft nichts.

Gibst du im Head- oder Footer-Feld rohes JavaScript ohne <script> ein (z. B. nur console.log('hi');), erscheint es als Text im Quelltext und wird nicht ausgeführt. Immer ein <script>…</script> drumherum.

Nicht doppelt wrappen

Spiegelbildlich beim CSS: kein zusätzliches <style> ins CSS-Feld geben — das Feld wrappt bereits selbst. Ein <style>…</style> im CSS-Feld bzw. ein fehlendes <script> im JS-Feld ist der häufigste Grund, warum „nichts passiert".

Head-JS läuft so früh wie möglich, noch bevor die Seite sichtbar wird. Richtig für Consent-Manager, Tag-Manager und Tracking, das Seitenaufrufe zählt.
Footer-JS läuft zuletzt, wenn das DOM geladen ist. Richtig für Widgets und Interaktionen, die HTML-Elemente brauchen, und für unkritische Skripte, die das Rendern nicht ausbremsen sollen.

Content Security Policy (CSP)

Das Theme erzeugt selbst keinen Content-Security-Policy-Header und keine Nonce. Eine strikte CSP blockiert die hier erzeugten Inline-Blöcke zunächst:

Inhalt	passende CSP-Strategie
Eigenes CSS im `<style>`-Block	exakten Hash in `style-src` aufnehmen
JavaScript innerhalb eines `<script>`-Blocks	exakten Hash des Inhalts zwischen den Tags in `script-src` aufnehmen
externes `<script src="…">`	Quelle in `script-src` freigeben; einen zusätzlichen Inline-Initialisierer separat per Hash erlauben
nachgeladene APIs, Bilder, Frames oder Fonts	je nach Snippet zusätzlich `connect-src`, `img-src`, `frame-src` oder `font-src` anpassen

Für statische Snippets ist ein SHA-256-, SHA-384- oder SHA-512-Hash die praktische Lösung. Der Hash muss exakt zum Inhalt passen; schon geänderte Leerzeichen oder Zeilenumbrüche erfordern einen neuen Hash. Ändere deshalb Snippet und CSP-Header gemeinsam und teste die neue Richtlinie zunächst mit Content-Security-Policy-Report-Only.

Eine Nonce muss kryptografisch zufällig, für jede Response neu erzeugt und identisch im CSP-Header sowie als nonce-Attribut des jeweiligen <script>- oder <style>-Elements gesetzt werden. Ein fester Nonce-Wert in der Plugin-Konfiguration ist unsicher. Da die bestehenden Felder keinen dynamischen Nonce-Platzhalter besitzen, benötigt diese Variante eine serverseitige Integration und eine Anpassung der beiden Storefront-Templates.

'unsafe-inline' würde die Blöcke pauschal erlauben, schwächt den XSS-Schutz aber erheblich und ist daher keine empfohlene Lösung. Wo möglich, legst du eigenen Code stattdessen in einer gebauten Theme-Datei oder einer externen Datei auf einer gezielt freigegebenen Quelle ab. Technische Details zu Hashes, Nonces und Inline-Prüfung stehen in der CSP-Level-3-Spezifikation.

Gut zu wissen

Gilt überall. Der Code wird auf jeder Storefront-Seite ausgegeben — Startseite, Kategorie, Produkt, Suche, Checkout usw.
Änderungen sichtbar machen. Im Live-Betrieb mit HTTP-Cache kann es nötig sein, den Cache zu leeren, damit Änderungen erscheinen (Einstellungen → Caches & Indizes → Cache leeren).
Datenschutz (DSGVO). Tracking- und Analytics-Skripte gehören hinter die Cookie-Einwilligung. Lade sie erst nach erteiltem Consent (z. B. über deinen Consent-Manager), nicht ungefragt beim ersten Seitenaufruf.
Sorgfalt. Prüfe Änderungen mindestens im Staging-System. Ein nicht geschlossenes <script>, ein Tippfehler oder eine unvollständig aktualisierte CSP kann die Storefront auf jeder Seite stören.

Häufige Fehler

❌ Falsch	✅ Richtig
Head-JS: `console.log('hi');` (ohne Tag) → erscheint als Text	`<script>console.log('hi');</script>`
CSS: `<style>.x{…}</style>` → doppelt gewrappt, wirkungslos	`.x { … }`
Tracking ungefragt geladen	Tracking erst nach Cookie-Consent laden

Eigener Code (CSS & JavaScript) ​

Wo finde ich die Felder ​

Wer darf diese Felder verändern? ​

Die drei Felder im Überblick ​

So gibt man es richtig ein ​

CSS — nur CSS, kein <style> ​

Head-JS & Footer-JS — immer mit eigenem <script> ​

Head-JS oder Footer-JS — was wann? ​

Content Security Policy (CSP) ​

Gut zu wissen ​

Häufige Fehler ​