Seit Version 5.5 gibt es eine Funktion, mit der man angeben kann, in welchem Kontext sich eine WordPress-Installation befindet. Läuft die Website auf einer lokalen Installation auf meinem Computer? Ist es eine Staging-Site auf einem Server? Oder ist es eine „echte“ Live-Site?

Wenn ich an einer Website arbeite, dann gibt es die Website in der Regel in drei Varianten. Eine Variante wohnt auf meinem lokalen Computer, eine zweite Variante liegt in einer Staging-Umgebung auf einem externen Server. Die dritte Variante ist die Live-Version der Website. Also das, was man sieht, wenn man die jeweilige URL aufruft.

In der lokalen Umgebung entwickle ich. Ich probiere Sachen aus, verwerfe sie wieder und so weiter. Bin ich zufrieden mit dem Ergebnis, exportiere ich meinen Code auf den Staging-Server. Jetzt können mehrerer Leute draufgucken und man kann gemeinsam testen, ob alles wie gewünscht funktioniert. Wenn alles klappt, geht’s eins weiter zur Live-Site.

Welche Umgebungen gibt es?

Die Funktion wp_get_environment_type() kennt vier Umgebungen:

  1. Local
  2. Development
  3. Staging
  4. Production

Wobei production der default-Wert ist. Wenn man also nichts anderes definiert, gilt dieser Wert.

Die Umgebung wird in der wp-config.php festgelegt. Die wp-config.php ist in jeder WordPress-Installation individuell. Das ist praktisch, weil man so nicht versehentlich etwas überschreiben kann.

Damit WordPress weiß, dass wir uns auf einer lokalen Installation befinden, trage ich in der wp-config.php meiner lokalen Installation diese Zeile ein:

define ( 'WP_ENVIRONMENT_TYPE', 'local');Code-Sprache: JavaScript (javascript)

Was kann man damit machen?

In der lokalen Variante der Website probiere ich viel herum. Auch gibt es die eine oder andere Hilfsfunktion. Das sind alles Dinge, die ich nicht auf der Live-Site sehen will. Es besteht aber immer die Gefahr, dass sich so etwas doch mal auf die Live-Site verirrt, wenn ich versehentlich eine falsche Datei hochlade. Das ist dann etwas unangenehm.

Mit der neuen Funktion wp_get_environment_type() kann ich genau das verhindern.

Ich kann in der functions.php so etwas machen:

/* Funktionen nur für die lokale Installation; 
gilt nur, wenn in der wp-config.php die Umgebung auf 'local' gesetzt ist */

if ('local' === wp_get_environment_type()) {
    require get_stylesheet_directory() . '/dev-only/dev-only-functions.php';
}Code-Sprache: JavaScript (javascript)

Man könnte die if-Abfrage auch umdrehen. Übersetzt heißt das Beispiel unten: „Nur wenn das hier NICHT die production-Umgebung ist, lade bitte meine Dev-Funktionen“.

if ('production' !== wp_get_environment_type()) {
    require get_stylesheet_directory() . '/dev-only/dev-only-functions.php';
}Code-Sprache: JavaScript (javascript)

Mit der Funktion wird eine Datei geladen, die Funktionen enthält, die ausschließlich in der lokalen Installation wirksam sein sollen. Das können ganz verschiedene Dinge sein. Ich kann z.B. eine Body-Class ‚local‘ definieren oder ich kann CSS-Dateien und JavaScripts laden, die mir beim Entwickeln und Testen helfen.

Jetzt kann ich ganz entspannt arbeiten und muss keine Angst haben, dass spät Abends etwas auf dem Live-Server landet, das da nicht hin soll.