Jeder kennt das Problem: Man hat stundenlang an einem Stylesheet auf dem Staging-Server rumgebastelt, will es nun auf den Live-Server kopieren und die Änderung ist nicht sichtbar. Die Fehlersuche beginnt. Man prüft den Cache. Vom Browser. Vom Server. Ist man überhaupt auf dem richtigen Server? Hat der Upload geklappt? Und so weiter. Eric Meyer hat das ganze Dilemma 2009 treffend beschrieben und auch eine Lösung mitgeliefert, von der ich noch nicht gehört habe:
Nutze doch einfach die HTTP-Header um deine Staging- und Live-Umgebung eindeutig voneinander zu unterscheiden. Der Link-Parameter im HTTP-Header nämlich auch die Angabe von Style-Sheet-Dateien. Und das sieht dann so aus:
1Header add Link "</staging.css>;rel=stylesheet;type=text/css;media=all"
In nginx kann man das folgendermaßen im Server-Block implementieren:
1add_header Link "</wp-content/themes/nickyreinert/style.header.css>;rel=stylesheet;type=text/css;media=all";
Wer Apache nutzt, setzt den “CSS-Header” folgendermaßen:
1Header add Link "</wp-content/themes/nickyreinert/style.header.css>;rel=stylesheet;type=text/css;media=all"
Natürlich habe ich die Spielerei gleich bei mir eingebaut:
CSS-Datei im HTTP-Header ausgeliefert
Damit lässt sich grundsätzlich auch das Stylesheet deines Wordpress-Themes ausliefern: Da WordPress aber die style.css nutzt, um Theme-Informationen zu verarbeiten, musst du auf dieses kleine Feature dann verzichten. Außerdem wird CSS im Link-Header nicht von jedem Browser unterstützt.
Zusammenfassung
Ein kurzer technischer Tipp für Web-Entwickler, der zeigt, wie man eine CSS-Datei über den HTTP 'Link'-Header lädt. Diese Methode kann genutzt werden, um eine Staging-Umgebung visuell von einer Live-Umgebung zu unterscheiden und so Verwechslungen zu vermeiden. Der Artikel enthält Konfigurationsbeispiele für Nginx und Apache.
Hauptthemen: CSS HTTP Web-Development Server-Konfiguration Nginx Apache
Schwierigkeitsgrad: intermediate
Lesezeit: ca. 5 Minuten