Mehrere WordPress Entwicklungsumgebungen mit unterschiedlichen Konfigurationseinstellungen nutzen

Wie ich ja schon immer mal wieder erwähnt habe, nutze ich ja zur Zeit recht intensiv die Versionskontrolle mit Hilfe von GIT. Darüber hinaus habe ich mehr als eine weitere Testumgebung für die Homepage eingerichtet, mit eigener MySQL Datenbank und Datenbanknutzern.

Man wächst ja mit seinen Aufgaben und deshalb habe ich bei meinem aktuellen Arbeitgeber dafür gesorgt, dass nicht mehr direkt an der Liveseite rumgebastelt wird. Das (von mir?) so genannte Cowboy Coding hatte regelmäßig zur Folge, dass die Seite einen White Screen of Death oder andere Fehlermeldungen, aber nicht mehr den normalen Inhalt anzeigte. Das ist für eine Live-Seite natürlich nicht sonderlich schön.

Deshalb gibt es parallel eine Testseite, auf der ich Bugs behebe, Features einbaue, Updates einspiele und was man eben sonst so macht, wenn man an einer Webseite rumschraubt. Hier kann ich separat programmieren, ohne dass die echte Webseite in irgend einer Form berührt wird. Die Änderungen kann ich dann mit Hilfe der Versionskontrolle einfach in die Live-Seite einspielen, wenn sie ausführlich getestet sind und ihre Funktionalität bestätigt ist.

Doppeltes Netz und Boden

Um die Trennung der Testumgebung und der Liveseite in vollem Umfang sicher zu stellen, habe ich für die Testseite auch eine eigene Datenbank angelegt (aus der Original-Datenbank kopiert), sowie eigene Datenbanknutzer angelegt, die nur auf diese Datenbank zugreifen und so nicht aus Versehen in die Original-Datenbank schreiben und diese gar möglich kaputt machen zu können.

Das hat natürlich zur Folge, dass ich die Konfigurationsdateien für jede WordPress-Testumgebung (es gibt insgesamt drei) ändern muss, damit sie auch die eigenen Datenbank benutzen. Die Versionskontrolle hat diese Änderungen natürlich immer fleißig angezeigt. Weil mich das aber irgendwann nervte, habe ich die Konfigurationsdateien in die Liste der zu ignorierenden Dateien aufgenommen.

Das Ignorieren der der Konfigurationsdateien tat ich nur widerwillig. Denn eigentlich möchte ich ja gerade diese sensiblen Dateien kontrollieren, ob daran Änderungen vorgenommen wurden und wenn ja, was genau dort geändert wurde. Der TYPO3-Pharma-Hack, den ich vor einer Weile hatte, hat mich da sensibel gemacht.

Wie du in WordPress eine lokale Datenbankverbindung benutzt, ohne die Versionskontrolle für die Konfigurationsdatei auszuschalten

Zuerst hatte ich versucht, die .gitgnore-Datei selbst zu ignorieren und dann auf jeder Testumgebung die wp-config.php ignoriert. Das erwies sich aber auch nicht wirklich als praktikabel, denn so wurde doch auch auf der Live-Seite die wp-config.php ignoriert – oder ich habe es nicht richtig gemacht.

Jetzt stieß ich zufällig über eine durchaus charmante und funktionierende Möglichkeit, für jede Testumgebung eine lokale Datenbank über eine separate Konfigurationsdatei zu implementieren. Diese lokale Konfigurationsdatei kann dann von der Versionskontrolle ausgeschlossen werden. Das ist durchaus clever, denn so kann ich für jede Testumgebung eine eigene Datenbankeinstellung haben und muss die Datei nur einmal ändern. Der Code hierfür ist denkbar einfach und muss in der wp-config.php eingefügt werden bzw. den originalen Teil ersetzen.

1
2
3
4
5
6
7
8
9

if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
  include( dirname( __FILE__ ) . '/local-config.php' );
  define( 'WP_LOCAL_DEV', true ); // Dazu später mehr
} else {
  define( 'DB_NAME',     'production_db'       );
  define( 'DB_USER',     'production_user'     );
  define( 'DB_PASSWORD', 'production_password' );
  define( 'DB_HOST',     'production_db_host'  );
}

Dieser Code-Schnipsel fragt ab, ob eine Datei Namens local-config.php existiert und falls ja, wird diese einbezogen. Falls nicht, werden die folgenden Datenbank-Zugangsdaten benutzt.

Deshalb brauchst du dann nur noch in den lokalen Entwicklungsumgebungen die local-config.php anlegen und mit den Zugangsdaten für die Entwicklungs-Datenbank füttern. Diese Datei wird dann einfach in die .gitignore aufgenommen (oder was auch immer) und braucht dann nicht mehr geändert werden.

Plugins die nur auf der Live-Seite laufen sollen

Es gibt einige WordPress-Plugins, die in einer lokalen Entwicklungsumgebung einfach keinen Sinn machen. Dazu gehören zum Beispiel die meisten Caching-Plugins. Aber auch so etwas wie WordPress Backup To Dropbox ist wenig nützlich und sogar eher kontraproduktiv. Dafür haben wir oben in Der Abfrage die Konstante WP_LOCAL_DEV definiert. Mit dieser Konstante und einem super kleinem, leichtgewichtigen Plugin kannst du Plugins in der lokalen Entwicklungsumgebung direkt ausschließen und deren Aktivierung verhindern.

Also jedes mal, wenn du lokal arbeitest und die local-config.php verwendet wird, werden die definierten Plugins nicht geladen.

Quelle: WordPress local dev tips: DB & plugins | Mark on WordPress