Es ist schon sehr lästig, wenn man eine WordPress-Instanz auf unterschiedlichen Servern laufen lassen möchte und dann ständig die Zugangsdaten für die Datenbank – aber auch andere Einstellungen – in der wp-config.php anpassen muss.
Bei der Entwicklung heißt das:
- Entwicklung auf dem Development-Server
- Ausgabe aller Fehler und Probleme auf dem Bildschirm
- Logging aller Fehler und Probleme als Datei
- Keine Konkatenation von CSS und Javascript
- Eigene Datenbankeinstellungen
- Ggf. Änderungen an Plugins und Themes via Editor – obwohl generell keine gute Idee, im Entwicklungsumfeld unkritisch
- Deployment auf dem Staging-Server zum Test unter Realbedingungen
- Ausgabe aller Fehler und Probleme auf dem Bildschirm
- Logging aller Fehler und Probleme als Datei
- Konkatenation von CSS und Javascript
- Eigene Datenbankeinstellungen
- Auf keinen Fall Änderungen an Plugins und Themes via Editor!
- Deployment auf dem Live-Server
- Auf gar keinen Fall Ausgabe aller Fehler und Probleme auf dem Bildschirm!
- Logging aller Fehler und Probleme als Datei
- Konkatenation von CSS und Javascript
- Eigene Datenbankeinstellungen
- Auf keinen Fall Änderungen an Plugins und Themes via Editor!
Natürlich gibt es noch zahlreiche weitere Einstellungen, die man über die wp-config.php fein granulieren kann, aber das soll an dieser Stelle keine Rolle spielen. Vielmehr geht es darum, die nötigen Einstellungen einmalig zu treffen und sich beim Deployment dann nicht jedes mal einen Kopf machen und die Einstellungen an die jeweilige Umgebung anpassen zu müssen.
Dabei gibt es zwei Ansätze:
- Alles in einer Datei via Variablen abarbeiten
- Die Settings in verschiedene Dateien verteilen und auf Vorhandensein prüfen
Lösung mittels verschiedener Dateien
Etwas aufgeräumter mag die Lösung mittels verschiedener Dateien wirken, zumindest auf den ersten Blick. Das Problem dabei ist, dass man beim Upload darauf achten muss, welche Config übertragen wird.
Das im unten stehenden GIST definierte Modell greift von unten nach oben – Dev => Staging => Live-Server. Ist die Config für den Dev-Server vorhanden, greift sie und alle folgenden werden ignoriert. Ist die für den Staging-Server vorhanden (und die für den Dev-Server nicht), greift sie usw.
Genug geredet, zum Gist:
Der Vorteil besteht darin, dass man in unterschiedlichen Dateien sehr aufgeräumt arbeiten kann und ansonsten einen Standard-Fall für den Live-Server definiert.
Lösung über eine einzige wp-config.php
Wie gesagt, kann man das Ganze auch über eine einzige wp-config.php lösen. Hier besteht der Vorteil darin, dass man direkt alle Konfigurationsmöglichkeiten auf einen Blick einsehen kann und letztendlich nicht darauf Rücksicht nehmen muss, welche wp-config grade aktiv ist bzw. hochgeladen wurde, da hier auf den Host geprüft wird. Meiner Meinung nach ist dies die intelligentere Methode, aber das ist eine rein subjektive Meinung. Ich bevorzuge normalerweise diese Methode.
