Eigenes CSS in Nextcloud: vom Notbehelf zur Gestaltungsstrategie
Es gibt diese Momente in der Administration einer Nextcloud, in denen die Funktionalität längst passt, aber das Erscheinungsbild gegen die eigenen Vorstellungen arbeitet. Vielleicht ist es der Blauton, der nicht zum Corporate Design passt. Vielleicht die Schriftgröße in der Dateiliste, die auf einem 27-Zoll-Monitor zu klein wirkt. Oder es ist schlicht der Wunsch, die Login-Seite so umzubauen, dass Nutzer nicht mehr raten müssen, ob sie auf der richtigen Instanz gelandet sind. Genau hier kommt Custom CSS ins Spiel — also eigenes Stylesheet-Material, das sich über die Standardgestaltung von Nextcloud legt.
Man kann darüber streiten, ob das eine saubere Lösung ist. Ich halte fest: Custom CSS ist kein Ersatz für ein durchdachtes Design-System, sondern ein Werkzeug für gezielte Eingriffe. Wer es beherrscht, kann eine Instanz innerhalb weniger Stunden so weit anpassen, dass sie sich wie ein eigenständiges Produkt anfühlt. Wer es unbedacht einsetzt, baut sich eine Wartungsbombe, die beim nächsten Major-Upgrade hochgeht. Der Unterschied liegt weniger im technischen Können als in der Disziplin, mit der man arbeitet.
Wie Nextcloud seine Styles überhaupt ausliefert
Um zu verstehen, wo eigenes CSS ansetzen kann, lohnt ein Blick darauf, wie die Software ihre Gestaltung zusammensetzt. Bis einschließlich Nextcloud 24 geschah das im Wesentlichen über SCSS-Dateien, die pro Theme kompiliert wurden. Wer damals ein Theme anpassen wollte, konnte einen Ordner unter themes/ anlegen und dort Variablen überschreiben. Das war mächtig, aber auch langsam: Jede Theme-Änderung zog eine Kompilierung nach sich, und die Zahl der Variablen war überschaubar.
Mit Nextcloud 25 hat sich das grundlegend geändert. Die SCSS-Kompilierung pro Theme ist weitgehend verschwunden, an ihre Stelle sind CSS-Custom-Properties getreten — also Variablen, die direkt im Browser ausgewertet werden. Das ist ein wichtiger Unterschied, denn es bedeutet: Ein Großteil der Farben, Abstände und Radien lässt sich heute überschreiben, ohne eine einzige Zeile Kompilierungslogik anzufassen. Man setzt eine Variable neu, und die gesamte Oberfläche folgt.
Parallel dazu existiert weiterhin die Theming-App im Kern von Nextcloud. Sie ist der offizielle Weg, Logo, Farbe, Slogan und einige Basisparameter zu setzen. Alles, was sie abdeckt, sollte man auch über sie lösen — nicht über CSS. Das gilt für die Primärfarbe, das Hintergrundbild der Login-Seite, das Logo in der Kopfzeile und den Text unter dem Anmeldeformular. Wer diese Dinge per CSS erzwingt, obwohl die Theming-App sie ohnehin anbietet, handelt sich Probleme bei Updates und inkonsistente Anzeigen in Clients ein.
Custom CSS beginnt also genau dort, wo die Theming-App aufhört: bei Abständen, Typografie, einzelnen Komponenten, Sichtbarkeiten, Sonderfällen. Es ist die Feinarbeit nach dem groben Pinselstrich.
Drei Wege, eigenes CSS einzubringen
In der Praxis haben sich drei Vorgehensweisen etabliert, die sich deutlich in Aufwand, Haltbarkeit und Risiko unterscheiden.
Der Weg über eine Custom-CSS-App
Im Nextcloud-App-Store finden sich mehrere Erweiterungen, die unter Namen wie „Custom CSS“ firmieren. Sie bieten in der Regel ein Textfeld in den Administrations-Einstellungen, in das man beliebiges CSS schreiben kann. Der Vorteil liegt auf der Hand: kein Zugriff auf das Dateisystem nötig, keine Änderung an config.php, und der Inhalt überlebt Upgrades, solange die App kompatibel bleibt. Für kleinere Anpassungen ist das der pragmatischste Weg.
Der Nachteil: Man ist von der Pflege der App abhängig. Wird sie nicht rechtzeitig für die nächste Major-Version freigegeben, steht man ohne Eingabefeld da. Wer den Inhalt dann nicht extern versioniert hat, sucht ihn mühsam im Datenbank-Dump zusammen. Es lohnt sich also, das CSS zusätzlich in einem Git-Repository zu halten — auch wenn das zunächst nach Übererfüllung klingt.
Der Weg über eine eigene App
Wer ohnehin eine eigene Nextcloud-App betreibt, kann dort ein Stylesheet registrieren. In PHP geschieht das über die Klasse OCP\Util mit einem Aufruf wie Util::addStyle('meineapp', 'custom') innerhalb des entsprechenden Event-Listeners oder Controllers. Das Stylesheet liegt dann unter apps/meineapp/css/custom.css und wird von Nextcloud mit ausgegeben.
<?php
// in apps/meineapp/lib/AppInfo/Application.php
use OCP\Util;
Util::addStyle('meineapp', 'custom');
Das ist die sauberste Variante aus Entwicklersicht, weil sie sich in die übliche Asset-Pipeline einfügt, versioniert wird und beim Deployment mitkommt. Sie setzt allerdings voraus, dass man eine eigene App unterhält — für eine reine Optik-Anpassung ist das oft zu viel Maschinerie.
Der Weg über die Theming-App plus Ergänzung
In manchen Versionen und in Kombination mit entsprechenden Erweiterungen findet sich direkt in den Administrations-Einstellungen unter „Design“ ein zusätzliches Feld für eigenes CSS. Das ist keine konstante Größe über alle Versionen hinweg, sondern hängt von der Installationsbasis ab. Wer es vorfindet, kann es nutzen; wer nicht, greift zu einer der beiden anderen Varianten. Wichtig ist in jedem Fall, den eingefügten Block mit einem Kommentar zu datieren und den Zweck zu notieren.
Die Design-Tokens von Nextcloud im Detail
Das Herzstück moderner Anpassungen sind die CSS-Variablen, die Nextcloud im :root definiert. Sie sind der Hebel, mit dem sich Farbwelten in wenigen Zeilen umlegen lassen. Zur Familie gehören unter anderem:
:root {
--color-primary: #0082c9;
--color-primary-text: #ffffff;
--color-primary-element: #0082c9;
--color-primary-element-text: #ffffff;
--color-main-background: #ffffff;
--color-main-background-rgb: 255,255,255;
--color-main-text: #222222;
--color-text-maxcontrast: #767676;
--color-text-light: #555555;
--color-border: #ededed;
--color-border-dark: #c7c7c7;
--color-background-dark: #ededed;
--color-background-hover: rgba(0,0,0,.05);
--color-error: #e9322d;
--color-warning: #eca700;
--color-success: #46ba61;
--border-radius: 3px;
--border-radius-large: 10px;
--border-radius-pill: 100px;
--default-clickable-area: 44px;
}
Diese Liste ist nicht abschließend, und sie verändert sich zwischen Versionen. Wer eine Variable überschreibt, die es nicht mehr gibt, bemerkt das nicht sofort — es passiert einfach nichts. Deshalb gehört zur Arbeit mit Custom CSS immer ein Blick in die Entwicklerwerkzeuge des Browsers, um zu prüfen, welche Variable an der betreffenden Stelle tatsächlich greift.
Ein interessanter Aspekt: Einige Variablen existieren in Varianten mit dem Suffix -rgb, in denen die Farbkanäle ohne rgb()-Hülle stehen. Das macht es möglich, Alpha-Werte dynamisch zu setzen, etwa rgba(var(--color-main-background-rgb), .5). Wer das nicht weiß, wundert sich, warum halbtransparente Overlays nach einer Farbänderung plötzlich falsch aussehen.
Nicht zuletzt gibt es Variablen, die eher struktureller Natur sind: --header-height, --navigation-width, --body-container-margin. Auch sie lassen sich anpassen. Man sollte dabei aber bedenken, dass die interne Layoutlogik von festen Annahmen ausgeht. Wer die Kopfzeile von 50 auf 80 Pixel streckt, muss damit rechnen, dass Icons oder Dropdown-Menüs nicht mehr sauber sitzen.
Selektoren finden, ohne im Minified-Chaos zu ertrinken
Der schwierigste Teil der Arbeit ist nicht das Schreiben von CSS, sondern das Finden der richtigen Ankerpunkte. Nextcloud liefert seine Stylesheets komprimiert aus, Klassennamen sind teils generiert, teils historisch gewachsen. Die gute Nachricht: Es gibt stabile Strukturen, auf die man sich verlassen kann.
Ganz oben steht die ID #body-user am <body>-Element für angemeldete Nutzer, #body-login für die Anmeldeseite und #body-public für öffentliche Freigaben. Diese drei IDs sind seit Jahren konstant und eignen sich hervorragend als Scope für kontextspezifisches CSS.
#body-login .wrapper {
background-image: linear-gradient(160deg, #0b2b3c 0%, #134a63 100%);
}
#body-user #header {
box-shadow: 0 1px 0 rgba(0,0,0,.08);
}
Innerhalb dieser Scopes finden sich weitere stabile Anker: #app-navigation für die linke Navigationsspalte, #app-content für den Hauptbereich, #app-sidebar für die rechte Detailleiste, #header für die Kopfzeile, #content als Container. Diese IDs haben sich über viele Versionen gehalten und sind deutlich verlässlicher als die vielen Utility-Klassen.
Bei einzelnen Komponenten wird es unübersichtlicher. Die Dateiliste etwa hat in den vergangenen Jahren mehrfach ihre Struktur geändert. Hier empfiehlt es sich, auf data-Attribute auszuweichen, sofern vorhanden. Attribute wie [data-cy-files-list], [data-cy-files-list-row] oder allgemeiner [aria-label] werden von den Entwicklern bewusst als Test- und Zugänglichkeitsanker gepflegt und ändern sich seltener als Klassennamen. Ich halte das für einen der wichtigsten Praxistipps überhaupt, denn er entscheidet darüber, ob ein Stylesheet ein Upgrade übersteht oder am Tag nach dem Update zerbricht.
Spezifität und die Versuchung des !important
Wer zum ersten Mal versucht, eine Nextcloud-Regel zu überschreiben, landet schnell bei !important. Das funktioniert. Es funktioniert sogar so gut, dass man es überall einsetzt — und dann irgendwann nicht mehr weiß, warum ein Element auf einer bestimmten Seite nicht mehr reagiert. !important ist kein Werkzeug, sondern eine Notbremse. Der bessere Weg ist, den Selektor gezielter zu wählen: eine zusätzliche ID, ein Kontext-Präfix, ein Attributselektor. Damit erreicht man dieselbe Wirkung, ohne die Kaskade dauerhaft zu verbiegen.
Ein Beispiel: Statt
.button { background: #c00 !important; }
besser
#body-user .button.primary { background: #c00; }
Das ist nicht nur sauberer, sondern auch nachvollziehbarer für die Kollegin, die in zwei Jahren den Block liest.
Konkrete Anwendungsfälle aus der Praxis
Die Anmeldeseite als Visitenkarte
Die Login-Seite ist der Ort, an dem Nutzer am häufigsten eine falsche Erwartungshaltung entwickeln. Ein klar erkennbares Branding hilft enorm. Die Theming-App setzt Farbe und Logo, aber für einen Verlaufshintergrund oder ein subtiles Muster braucht man CSS.
#body-login {
background: #0d1b2a;
background-image:
radial-gradient(circle at 20% 20%, rgba(0,130,201,.35), transparent 55%),
radial-gradient(circle at 80% 70%, rgba(0,201,167,.25), transparent 50%);
}
#body-login .guest-box,
#body-login .login-box {
border-radius: var(--border-radius-large);
box-shadow: 0 20px 60px rgba(0,0,0,.35);
}
Wichtig: Die Klassennamen der Anmeldebox haben sich zwischen Versionen verschoben — früher war es .wrapper und .v-align, dann .guest-box, in aktuellen Versionen teils .login-box. Man sollte beide Varianten im Selektor aufführen, das schadet nicht und erhöht die Haltbarkeit.
Kopfzeile und Navigation
Die Kopfzeile lässt sich gut an ein Corporate Design anpassen. Wenn die Primärfarbe über die Theming-App gesetzt ist, übernimmt sie bereits den Hintergrund. Für einen Verlauf oder eine Trennlinie braucht es zusätzliches CSS.
#header {
background-image: linear-gradient(90deg, var(--color-primary) 0%, #005a8c 100%);
border-bottom: 1px solid rgba(255,255,255,.08);
}
#header .header-right .menu {
border-radius: var(--border-radius-pill);
}
Bei der Navigation ist Vorsicht geboten. Sie ist stark von internen Breitenannahmen abhängig. Anpassungen an --navigation-width funktionieren, können aber dazu führen, dass lange App-Namen abgeschnitten werden. Hier empfiehlt sich ein Test mit den tatsächlich installierten Apps, nicht nur mit der Standardinstallation.
Dateiliste und Tabellen
In der Dateiliste wünschen sich viele Administratoren mehr Zeilenhöhe oder deutlichere Trennlinien. Beides ist machbar, solange man nicht in die virtuelle Scroll-Logik eingreift. Nextcloud rendert große Verzeichnisse virtualisiert; wer hier mit Pseudo-Elementen arbeitet, kann die Höhenberechnung durcheinanderbringen.
[data-cy-files-list-row] {
border-bottom: 1px solid var(--color-border);
}
[data-cy-files-list-row]:hover {
background-color: var(--color-background-hover);
}
Das ist bewusst zurückhaltend gehalten. Sicherer ist immer die Anpassung von Farben und Rahmen als die von Höhen und Abständen.
Talk, Deck und andere Apps
Viele zusätzliche Apps bringen eigene Stylesheets mit. Sie nutzen zwar die Design-Tokens, setzen aber eigene Klassennamen und teils eigene Farbwelten. Wer hier anpassen will, sollte immer app-spezifisch arbeiten und die Regeln klar kommentieren. Ein Beispiel aus Talk: Die Sprechblasen haben eigene Klassen, die sich je nach Version ändern können. Ein zu aggressiver globaler Selektor wie [class*="message"] kann hier ungewollt andere Apps treffen.
Dark Mode und automatische Anpassung
Nextcloud unterstützt mehrere Themes gleichzeitig und schaltet sie abhängig von der Nutzereinstellung oder dem Betriebssystem um. Technisch geschieht das über Attribute am Body-Element, etwa data-themes="dark" oder data-themes="default". Für Custom CSS ist das entscheidend, denn eine Regel, die helle Hintergründe annimmt, sieht im Dark Mode katastrophal aus.
body[data-themes*="dark"] {
--color-main-background: #1b1b1b;
--color-main-text: #e6e6e6;
}
body[data-themes*="dark"] #app-navigation {
border-right: 1px solid rgba(255,255,255,.08);
}
Der Attributselektor mit *= ist hier bewusst gewählt, weil das Attribut mehrere Themes enthalten kann, etwa "dark dark-highcontrast". Wer exakt auf data-themes="dark" prüft, verpasst diese Fälle. Alternativ kann man mit prefers-color-scheme arbeiten — das greift aber nur, wenn die automatische Umschaltung aktiv ist, und sollte nur ergänzend verwendet werden.
Grundsätzlich gilt: Wer eigene Farben definiert, sollte sie konsequent aus Variablen beziehen, nicht aus festen Hex-Werten. Sonst entsteht ein Flickenteppich, bei dem einzelne Elemente im Dark Mode hell bleiben und andere korrekt umschalten.
Barrierefreiheit ist keine Kür
Ein Punkt, der in vielen Anleitungen fehlt: Kontrastverhältnisse. Die WCAG-Richtlinien verlangen 4,5:1 für normalen Text und 3:1 für große Schrift sowie für Bedienelemente. Wer eine Primärfarbe wählt, die zwar zum Logo passt, aber auf weißem Grund kaum lesbar ist, produziert eine Anwendung, die für einen Teil der Belegschaft schlicht unbenutzbar wird. Das ist nicht nur eine Frage der Höflichkeit — in öffentlichen Verwaltungen und vielen Unternehmen ist Barrierefreiheit mittlerweile eine Anforderung mit rechtlicher Relevanz.
Ebenso wichtig: Fokus-Indikatoren dürfen nicht entfernt werden. Der häufigste Fehler in Custom CSS ist ein outline: none auf Links oder Buttons, weil der blaue Ring „unschön“ wirkt. Damit macht man die Anwendung für Tastaturnutzer praktisch unbedienbar. Wer den Fokusring gestalten will, sollte ihn nicht abschalten, sondern ersetzen — etwa mit einer deutlich sichtbaren Box-Shadow-Variante.
:focus-visible {
outline: 2px solid var(--color-primary);
outline-offset: 2px;
}
Ein weiterer Aspekt betrifft die Schriftgröße. Nextcloud ist für eine Grundgröße um 15 Pixel ausgelegt. Wer sie erhöht, um Lesbarkeit zu verbessern, muss die Breiten der Navigation und Sidebars mitziehen. Wer sie verkleinert, um mehr Information auf den Schirm zu bringen, sollte sich fragen, ob das wirklich ein Problem ist, das man lösen muss.
Performance und Caching
Custom CSS wird bei jedem Seitenaufruf mitgeliefert. Bei einem kleinen Block von wenigen Kilobyte ist das irrelevant. Bei mehreren hundert Zeilen, die ungeprüft aus Forenbeiträgen zusammengesucht wurden, kann es spürbar werden — vor allem, wenn darin @import-Anweisungen stehen, die zusätzliche Roundtrips erzeugen.
Mehrere Punkte sind hier zu bedenken. Erstens: Externe Schriftarten sollten, wenn überhaupt, lokal ausgeliefert werden. Ein Verweis auf einen Font-Anbieter bringt nicht nur Datenschutzfragen mit sich, sondern kostet auch Zeit. Zweitens: CSS sollte nicht durch Inline-Styles ergänzt werden, wenn es vermeidbar ist. Drittens: Wenn die Instanz hinter einem CDN oder Reverse-Proxy mit Caching betrieben wird, muss der Cache nach einer Änderung invalidiert werden.
In vielen Anleitungen findet sich der Hinweis, den Cache-Buster der Theming-App über die Kommandozeile zu erneuern. Das ist ein brauchbarer Weg, um Clients zum Neuladen der Stylesheets zu bewegen:
occ config:app:set theming cachebuster --value=$(date +%s)
Danach ist ein Blick in den Browser-Cache nötig. Nicht selten sitzt das Problem nicht auf dem Server, sondern im Service Worker einer bereits geöffneten Sitzung. Ein Hard Reload oder das Leeren der Website-Daten schafft Klarheit.
Sicherheit: ein unterschätzter Aspekt
CSS gilt gemeinhin als ungefährlich. Das ist nur bedingt richtig. Zwei Angriffsflächen verdienen Beachtung.
Die erste ist die Datenexfiltration über url(). CSS kann Bilder nachladen, und über Attributselektoren wie input[value^="a"] lässt sich theoretisch Zeichen für Zeichen auslesen, indem man für jeden Treffer ein unterschiedliches Hintergrundbild nachlädt. Das ist kein theoretisches Konstrukt — es gibt entsprechende Proof-of-Concept-Angriffe. In einer Multi-Tenant-Umgebung, in der Nutzer ihr eigenes CSS einbringen dürfen, ist das eine reale Gefahr.
Die zweite Angriffsfläche ist die Content Security Policy. Nextcloud setzt standardmäßig eine recht strikte CSP, die externe Bildquellen blockiert. Wer diese Policy aufweicht, um bestimmte Stylesheets zu ermöglichen, öffnet gleichzeitig das Tor für Tracking-Pixel und ähnliche Spielereien. Meiner Meinung nach gibt es kaum einen guten Grund, die CSP für optische Anpassungen zu lockern.
Die praktische Konsequenz daraus: Custom CSS gehört in die Hände der Administration, nicht der Nutzer. Wenn eine Anforderung nach nutzerspezifischem Styling aufkommt — etwa für eine Abteilung mit eigenen Farben — sollte man das über separate Instanzen oder über eine kontrollierte App lösen, nicht über frei zugängliche Eingabefelder.
Wartbarkeit über Upgrades hinweg
Hier entscheidet sich, ob Custom CSS ein Werkzeug bleibt oder zur Last wird. Die ehrliche Antwort: Ein Stylesheet, das heute ohne Probleme funktioniert, kann nach einem Major-Upgrade teilweise ins Leere laufen. Das ist kein Grund, es nicht zu tun — aber ein Grund, es ordentlich zu tun.
Bewährt hat sich ein Aufbau in vier Blöcken: ein Kopfkommentar mit Zweck, Zielversion und letzter Prüfung; ein Abschnitt mit Variablenüberschreibungen; ein Abschnitt mit strukturbezogenen Regeln; ein Abschnitt mit app-spezifischen Ausnahmen. Auf diese Weise sieht man auf einen Blick, welcher Teil bei einem Bruch verantwortlich ist.
/* ============================================
Custom CSS für Instanz cloud.example.org
Ziel: Corporate Design, Lesbarkeit
Geprüft mit: Nextcloud 30
Letzte Änderung: siehe Git-Historie
============================================ */
/* 1) Variablen */
/* 2) Struktur */
/* 3) Appspezifisch */
Ebenso hilfreich: eine kleine Testmatrix. Drei oder vier Ansichten, die man nach jedem Upgrade durchklickt — Anmeldeseite, Dateiliste, Talk, Einstellungen — genügen meist, um grobe Regressionen zu erkennen. Screenshot-Vergleiche lassen sich mit Playwright oder ähnlichen Werkzeugen automatisieren, aber für die meisten Installationen ist ein manueller Durchgang ausreichend.
Und noch ein Hinweis aus der Praxis: Wer Custom CSS einsetzt, sollte das dokumentieren. Nicht nur im Repository, sondern an der Stelle, an der Administratoren üblicherweise nachsehen. Ein Zweizeiler im internen Wiki erspart der Nachfolgekraft mitunter einen ganzen Nachmittag.
Wo Custom CSS an Grenzen stößt
Es wäre unseriös, die Grenzen zu verschweigen. Die wichtigste: Mobile Apps und Desktop-Clients lesen kein Custom CSS. Sie haben eigene Oberflächen, die lediglich einige Parameter — etwa die Primärfarbe über die Capabilities-Schnittstelle — übernehmen. Wer also ein durchgängiges Branding bis in die Android-App hinein möchte, wird mit CSS nicht weit kommen.
Die zweite Grenze betrifft E-Mail-Vorlagen. Mails werden von Mailclients gerendert, viele davon mit stark eingeschränkter CSS-Unterstützung. Was hier funktioniert, ist ein separater Bereich, der über die Theming-Einstellungen gesteuert wird. Eigenes CSS aus der Web-Oberfläche landet nicht in den Mails.
Die dritte Grenze betrifft gruppen- oder nutzerspezifisches Styling. Die Theming-App arbeitet global. Wer unterschiedliche Farben pro Mandant oder Abteilung braucht, landet schnell bei der Frage nach mehreren Instanzen — was häufig ohnehin die bessere Architektur ist, weil es auch Datenhaltung, Rechte und Backups sauber trennt.
Betrieb im Team
In kleineren Umgebungen kümmert sich meist eine Person um die Optik. In größeren Organisationen ist das anders: Da gibt es eine Designabteilung mit Vorstellungen, eine IT mit Betriebsverantwortung und manchmal eine Datenschutzstelle mit Bedenken. Custom CSS sitzt genau zwischen diesen Zuständigkeiten und wird deshalb gerne zum Streitthema.
Was hilft, ist eine klare Zuständigkeit und eine gemeinsame Ablage. Konkret: Das Stylesheet liegt versioniert in einem Repository, Änderungen laufen über einen Pull Request, und die Designabteilung hat ein Vetorecht bei Farb- und Typografieentscheidungen. Das klingt bürokratisch für ein paar Zeilen CSS, spart aber erfahrungsgemäß viel Reibung — vor allem, wenn die Instanz von mehreren tausend Menschen genutzt wird.
Für die Ausbringung selbst bieten sich zwei Wege an. Bei wenigen Instanzen genügt es, den Inhalt per Copy-and-Paste in das Eingabefeld zu übernehmen. Bei mehreren Instanzen oder häufigen Änderungen lohnt sich ein Automatisierungslauf, der das CSS aus dem Repository zieht und über die Kommandozeile setzt. Der Befehl occ config:app:set funktioniert für App-Konfigurationen jeder Art und lässt sich in Ansible, Puppet oder ein eigenes Skript einbinden.
Ein Plädoyer für Zurückhaltung
Man kann in Nextcloud optisch fast alles erreichen. Die Frage ist, ob man es sollte. Ich habe Installationen gesehen, in denen die Oberfläche durch jahrelang gewachsene CSS-Anpassungen so weit vom Standard abwich, dass Support und Fehlersuche zur Qual wurden. Jede Meldung eines Nutzers begann mit der Rückfrage, ob das beschriebene Verhalten überhaupt dem Original entspricht.
Die bessere Strategie ist, sparsam zu arbeiten. Primärfarbe, Logo und Slogan gehören in die Theming-App. Alles, was dort gesetzt werden kann, sollte dort gesetzt werden. Custom CSS bleibt für die Fälle, in denen die Standardlösung nicht ausreicht: ein Verlauf auf der Login-Seite, eine etwas großzügigere Zeilenhöhe in der Dateiliste, ein dezenter Schatten unter der Kopfzeile. Kleine Eingriffe, klare Kommentare, regelmäßige Prüfung.
Wer so arbeitet, bekommt eine Instanz, die sich anfühlt wie ein eigenes Produkt — und die trotzdem bei jedem Upgrade ohne Panik hochgezogen werden kann. Das ist, bei aller Begeisterung für gestalterische Freiheit, am Ende das Kriterium, an dem sich der Einsatz messen lassen muss.