Arbeitsumgebungen (local, dev, staging) in WordPress definieren und verwenden

Von: Konstantin, Jonas

In der Konfigurationsdatei von WordPress lassen sich Arbeitsumgebungen definieren, die eine gezielte Kontrolle über Funktionen und Features je Umgebung ermöglichen.

Aktualisiert von 2021 – 2024 5 Kommentare

Bei der Entwicklung von Themes für WordPress verwenden wir mehrere Instanzen des CMS, die jeweils unterschiedliche Funktionen im Arbeitsablauf und deshalb unterschiedliche Anforderungen an ihre Konfigurationen haben. Die lokale Installation befindet sich beispielsweise auf dem eigenen Computer, die Development-Umgebung steht online zur Einsicht für Kunden bereit und die Production-Umgebung ist die fertige Website auf dem Live-System. Das Definieren der Arbeitsumgebung in der Datei wp-config.php ermöglicht uns die Kontrolle über Funktionen und Features für die verschiedenen Zwecke.

Umgebung definieren und abfragen

Um eine Umgebung in WordPress zu definieren, wird in der Datei wp-config.php die Konstante WP_ENVIRONMENT_TYPE angelegt:

define('WP_ENVIRONMENT_TYPE', 'development');

Mit der Funktion wp_get_environment_type() können wir den Wert der Umgebungskonstante auslesen. Ist keine Umgebung definiert, liefert die Funktion den Wert production. Andere mögliche Werte sind local, development und staging. Damit haben wir ein praktisches Werkzeug, um in verschiedenen Umgebungen unterschiedlichen Code auszuspielen.

switch (wp_get_environment_type()) {
   case 'production':
      do_production_thing();
      break;
   case 'staging':
      do_staging_thing();
      break;
   case 'development':
   case 'local':
   default:
      do_development_thing();
      break;
}

Eine andere, veraltete Lösung

Was wir in der wp-config.php machen, ist im Grunde nur das Anlegen einer PHP-Konstante, mit deren Hilfe wir dann eine Fallunterscheidung durchführen können. Diese Konstante kann praktisch jeden beliebigen Namen tragen. Das wurde in der Vergangenheit auch so praktiziert: Lange war es in der WordPress-Entwicklung gängige Praxis, eine Konstante WP_LOCAL_DEV zu definieren und ihr, je nach Umgebung, einen Wert true oder false zuzuweisen (der konkrete Name ist unerheblich; MY_DEV_ENV würde z.Bsp. genauso funktionieren). Durch eine einfache if-Abfrage konnte so zwischen verschiedenen Umgebungen unterschieden werden. Der Nachteil dieser Variante ist, dass die Konstante das Geheimnis des Entwicklers bleibt und dadurch anderen Komponenten des WordPress-Ökosystems nicht zur Verfügung steht.

Mit der Einführung von WP_ENVIRONMENT_TYPE in WordPress 5.5 wurde das Prinzip standardisiert und ist dadurch nun z. B. auch für Plugins zugänglich.

Anwendungsbeispiele

Ein anschauliches Beispiel für den Umgang mit verschiedenen Umgebungen bietet die Konfiguration des WordPress-Debug-Modus in der Datei wp-config.php. Das Beispiel zeigt die folgende Konstellation:

• Lokal sowie in der Development-Instanz soll der Debug-Modus aktiv sein und Fehler direkt im Screen angezeigt werden.
• In der Staging-Instanz soll der Debug-Modus aktiv sein, Fehler aber nicht im Screen gezeigt, sondern nur in die Log-Datei geschrieben werden.
• In der Production-Instanz soll der Debug-Modus vollständig ausgeschaltet sein.

switch (wp_get_environment_type()) {
   case 'production':
      define('WP_DEBUG', false);
      break;
   case 'staging':
      define('WP_DEBUG', true);
      define('WP_DEBUG_DISPLAY', false);
      define('WP_DEBUG_LOG', true);
      break;
   case 'development':
   case 'local':
   default:
      define('WP_DEBUG', true);
      define('WP_DEBUG_DISPLAY', true);
      define('WP_DEBUG_LOG', true);
   break;
}

Die Umgebungsvariable steht systemweit zur Verfügung, kann also auch auf Theme-Ebene abgefragt und somit im Kontext der functions.php verwendet werden.

In unseren Projekten nutzen wir u.a. das Tool »Issue Collector«, welches das Erstellen von Support- und Fehlertickets in unserer Projektmanagementsoftware Jira ermöglicht. Dieses Tool soll nicht in unseren lokalen Arbeitsumgebungen und nicht in der Production-Instanz angezeigt werden, sondern ausschließlich dem Kunden in der Entwicklungsinstanz zur Verfügung stehen. Mit dem folgenden Snippet spielen wir den Issue Collector nur in der Development-Umgebung aus:

if (wp_get_environment_type() === 'development') {
   <script src="path/to/jira-issue-collector.js"></script>
}

Diesem Prinzip folgend kann der Code für eine Besucheranalysesoftware (Google Analytics, Matomo etc.) nur auf der Production-Instanz ausgespielt werden. Dadurch wird vermieden, dass die Analysedaten durch zusätzliches Erfassen von Aktivitäten in den Entwicklungsumgebungen verfälscht werden.

if (wp_get_environment_type() === 'production') {
    <script src="path/to/visitor-analytics.js"></script>
}

Geschrieben von:

Konstantin Hanke

Konstantin arbeitet als Webentwickler bei kulturbanause. Seine Hauptaufgabe ist die technische Umsetzung von klaren, soliden und effizienten Webauftritten und Website-Komponenten. Darüber hinaus kümmert er sich um die Wartung, Optimierung und Weiterentwicklung von bestehenden Websites. Sein besonderes Interesse gilt der Idee von quelloffener, freier Software.

Jonas Hellwig

Jonas ist Gründer der Agentur kulturbanause und des kulturbanause Blogs. Er arbeitet an der Schnittstelle zwischen UX/UI Design, Frontend und Redaktion und hat zahlreiche Fachbücher und Video-Trainings veröffentlicht. Jonas Hellwig ist regelmäßig als Sprecher auf Fachveranstaltungen anzutreffen und unterstützt mit Seminaren und Workshops Agenturen und Unternehmen bei der Planung, der Gestaltung und der technischen Umsetzung von Web-Projekten.

Jonas Hellwig bei Xing