Zur Suche springen Zur Navigation springen Zum Hauptinhalt springen Zum Footer springen

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

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 'local':
    case 'development':
    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 Debug-Modus in WordPress. Das Beispiel zeigt die folgende Konstellation:

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

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 Code 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

Benutzerbild

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.

Feedback & Ergänzungen – 3 Kommentare

  1. Christoph
    schrieb am 08.09.2021 um 16:40 Uhr:

    Mich würde sehr interessieren, wie ihr die Datenbanken zwischen den verschiedenen Instanzen bzw. Umgebungen synchronisiert. Habt ihr vielleicht dazu auch einen Beitrag geplant?

    Antworten
  2. Torben Korb | AW Media Werbeagentur
    schrieb am 29.01.2021 um 23:13 Uhr:

    Sehr guter Tipp, wusste das bisher nicht. Macht doch immer wieder Sinn die Doku von WP (oder gute Blogbeiträge) eingehend zu lesen.

    Vielen Dank!

    PS: Ein Deployment Workflow würde mich auch sehr interessieren für WordPress

    Antworten
  3. Ingo
    schrieb am 07.01.2021 um 13:29 Uhr:

    Super Thema, genau damit habe ich mich über die Feiertage auch beschäftigt. Danke dafür! Was noch interessant wäre, wäre ein Artikel über die Arbeit mit WP und Git. Was habt Ihr da für einen Workflow?

    Antworten

Kommentar zu dieser Seite

Wir freuen uns über Anregungen, Ergänzungen oder Hinweise zu Fehlern. Wir lesen jeden Eintrag, veröffentlichen aber nur, was den Inhalt sinnvoll ergänzt.

WordPress-Projekte mit kulturbanause

Wir wissen wovon wir reden. Wir setzen WordPress seit über 10 Jahren erfolgreich ein und realisieren maßgeschneiderte Websites auf Basis dieses großartigen CMS.

WordPress-Leistungsangebot →

Schulungen von kulturbanause

Wir bieten Seminare und Workshops zu den Themen Konzept, Design und Development. Immer up-to-date, praxisnah, kurzweilig und mit dem notwendigen Blick über den Tellerrand.

Übersicht Schulungsthemen →