kulturbanause Blog

Responsive Design, WordPress, Konzeption, HTML, CSS, JS & UX/UI …

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.

Workshops & Schulungen von kulturbanause

Intensive Trainings mit hohem Praxisbezug.

Online-Schulungen (remote per Video)

Inhouse-Schulungen

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:

  • Lokal soll der Debug-Modus aktiv sein und Fehler direkt im Screen angezeigt werden.
  • In der Development-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 '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>
}

Jetzt bist du gefragt!

Hast du Anregungen, Ergänzungen, einen Fehler gefunden oder ist dieser Beitrag nicht mehr aktuell? Dann freuen wir uns auf deinen Kommentar.

Du kannst diesen Beitrag natürlich auch weiterempfehlen. Wir sind dir für jede Unterstützung dankbar!

Unterstützung bei WordPress-Projekten

Unsere WordPress Agentur ist auf die Entwicklung maßgeschneiderter WordPress-Themes und -Websites spezialisiert. Wenn du Unterstützung bei der Planung, Gestaltung und Entwicklung eines Projekts benötigst, helfen wir gerne weiter.
WordPress-Leistungsangebot →

Das könnte dich auch interessieren

2 Kommentare

  1. Ingo

    Verfasst am 7. Januar 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?

  2. Torben Korb | AW Media Werbeagentur

    Verfasst am 29. Januar 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

Schreibe einen Kommentar zu Torben Korb | AW Media Werbeagentur Antworten abbrechen

Dieser Blog lebt vom Feedback der Besucher! Also los, mach mit!
Bitte habe Verständnis dafür, dass Kommentare die mit dem Inhalt dieses Beitrags nichts zu tun haben, gelöscht werden.