README

Hält die Konfiguration des Contao Theme-Managers im Repository statt in der Datenbank – und sorgt dafür, dass das Backend das auch anzeigt.

Warum das Paket existiert

Farben, Schriften und Abstände eines Themes gehören zum Code: sie werden im Editor geändert, sind im Git nachvollziehbar und gehen mit dem Deploy mit. Der Theme-Manager pflegt sie dagegen in tl_theme.themeConfig, also in der Datenbank – und die wird beim Deploy nicht gemerged, sondern überschrieben oder gar nicht angefasst.

Der naheliegende Ausweg ist eine _config-overrides.scss, die die Variablen einfach neu setzt. Das funktioniert auch – aber nur fürs Stylesheet. Der Theme-Compiler baut das SCSS in dieser Reihenfolge zusammen (FileCompiler::compile()):

$content = $scssConfigContent   // 1. die _config.scss der Pakete, alles !default
         . $tableConfigContent  // 2. aus tl_theme.themeConfig, OHNE !default
         . $content;            // 3. projekt.scss und damit die eigenen Overrides

Position 3 gewinnt. Das Frontend zeigt also die Werte aus dem Repo, die Backend-Maske aber weiter die alten aus der Datenbank. Und mit ihr alles, was nur aus der Datenbank liest und den Override nie zu sehen bekommt:

Was	Woher es liest
Die Maske unter Themes → Theme-Manager	`tl_theme.themeConfig`
Farbkacheln im Style-Manager-Dropdown (`_backendColors.css`)	`ConfigGenerator::generateBackendCss()`
`style-manager-tm-config.xml` – Seitenverhältnisse, Artikel-Höhen, Hintergrundgrößen, Display-Utilities	`ConfigGenerator`

Praktisch heißt das: Im Backend steht bei $primary ein Blau, während die Seite rot ist. Wer die Kachelfarben im Style-Manager zur Orientierung nutzt, wird in die Irre geführt. Und niemand kann sehen, dass die Felder wirkungslos sind.

Dieses Paket schließt die Lücke – ohne die Datenbank zur Quelle zu machen.

Was es tut

Liest die SCSS-Datei und löst Verweise auf ($link-color-regular: $primary → #dd3333). Die Feldnamen der Maske sind identisch mit den Variablennamen, übersetzt werden muss nur das Werteformat.
Schreibt die Werte nach tl_theme – beim Öffnen der Maske und vor jedem Kompilieren. Damit stimmen Anzeige, Backend-Farben und XML wieder mit dem Repo überein.
Sperrt die betroffenen Felder und schreibt in die Feldbeschreibung, woher der Wert kommt. Gesperrte Felder sehen aus wie offene – die Farbvorschau des Colorpickers bleibt erhalten, sie lässt sich nur nicht mehr öffnen.

Variablen ohne Gegenstück in der Maske (Hilfsfarben etwa) bleiben unberührt und wirken wie bisher nur im Stylesheet.

Installation

composer require ex-akt/ctm-theme-config

Ohne weitere Konfiguration wird layout/styles/_config-overrides.scss gelesen – dieselbe Stelle, an der der Theme-Compiler das Projekt-SCSS ohnehin erwartet. Die Datei muss über projekt.scss vor @import "theme" eingebunden sein, sonst greifen die Overrides im Stylesheet nicht.

Konfiguration

# config/config.yaml
ex_akt_ctm_theme_config:
    source_file: 'layout/styles/_config-overrides.scss'

    # Nur nötig, wenn eine Installation mehrere Themes hat.
    # Schlüssel ist die ID aus tl_theme.
    themes:
        2: 'layout-zweitmarke/styles/_config-overrides.scss'

Wie es sich verhält

Änderung sichtbar machen: Maske neu laden genügt – die Datei wird bei jedem Aufruf frisch gelesen. Fürs Frontend braucht es weiterhin einen Compile-Lauf.

Reihenfolge: egal. Wer die SCSS-Datei ändert und direkt kompiliert, bekommt dieselben Werte, als hätte er vorher die Maske geöffnet.

Datei fehlt: nichts passiert. Kein Fehler, die Felder bleiben offen – etwa auf einem Server, auf dem layout/ noch nicht hochgeladen wurde.

Wert nicht abbildbar (calc(100% - 2rem) in einem Feld für Zahl+Einheit, gemischte Einheiten in einem TRBL-Feld): Der Wert wandert unverändert in die Datenbank. Der Compiler macht daraus wieder genau den Ausdruck aus der SCSS-Datei; nur das Backend zeigt ihn dann roh an.

Lizenz

LGPL-3.0-or-later

ex-akt / ctm-theme-config

Maintainers

Package info

Statistics

Security