Alte Hasen lernen nicht aus.
Auch als erfahrener WordPress-Entwickler lernt man immer noch Basics dazu denn WordPress ist eine umfangreiche Toolbox.
Wir sind jetzt schon jahrelang im Geschäft, eigentlich schon über ein Jahrzehnt.
Dennoch kommt es immer wieder vor, dass man über Probleme mit Basics stolpert.
In diesem Fall geht es um get_post_type().
Custom Post Type Archive und get_post_type();
Um diese Kombination geht es beim Problem mit get_post_type().
Wenn es keine Posts im Custom Post Type Archiv gibt,
dann kann get_post_type „false“ oder einen anderen Wert zurückgeben!
Das ist wichtig. Das möchte ich dringend hervorheben.
Warum? Weil es eine sehr blöde Fehlerquelle ist, die man sich auf den ersten Blick gar nicht erklären kann.
Auch wenn man schon jahrelang WordPress Entwicklung macht, dauernd Code für Themes und Plugins schreibt, übersieht man das gerne.
Verschlimmernd kommt hinzu, dass wir uns in der Firma sogar schon mal mit dem Thema beschäftigt haben, siehe:
Wir schreiben Artikel oft als Zusammenfassung, wenn uns ein Problem unterkommt.
Da wird in Git-Issues zuvor darüber diskutiert, es erfolgt ein Austausch um aus Fehlern oder Problemen anderer zu lernen.
In dem Fall haben wir über das Thema also schon mal diskutiert und ist bei uns im Code vor Jahren deshalb auch so eingeflossen:
Die Problematik mit get_post_type() und Custom Post Type Archiven sollte mir also bekannt sein, dennoch hat mich die Funktion in den letzten Tage fast zur Verzweiflung gebracht.
Wo liegt also das Problem mit Custom Post Types und get_post_type()?
Warum ist das so?
Wie holt get_post_type() den Post Type?
Die Funktion braucht eine befüllte globale Variable $post.
Wenn die globale Variable $post aber leer ist, kann da aber nichts zurückgegeben werden.
Schauen wir uns das an, wenn wir get_post_type() ohne Parameter aufrufen:
Die Funktion get_post_type() holt sich den Post mit get_post().
In get_post() wird die globale Variable $post geholt, wenn es da aber nichts gibt, wird NULL!!! zurückgegeben.
Hier in der (globalen )WP_Query]}** erkennt man folgendes:
- Es gibt einen Custom Post Type wbm_customer
- Dieser wird aus der Datenbank abgefragt
- Es gibt aber keine Posts für diesen Custom Post Type
- Also ist der Wert „posts“ in der wp_query]}** leer!
Ergebnis:
Damit läuft get_post_type() komplett in’s Leere! :((((((((
Die Verwirrung: query monitor!
Gute Entwickler verwenden query monitor beim Erstellen von Themes und Plugins.
In dem Fall verwirrt uns der query monitor anfangs ein bisschen:
Die Info vom Query Monitor sagt uns eindeutig, dass wir einen Custom Post Type bekommen, sogar den richtigen!
Das verwirrt. Query Monitor bestätigt uns, dass wir „beim richtigen Custom Post Type“ sind, aber get_post_type() gibt uns NULL zurück.
Warum wir NULL zurück bekommen, haben wir oben geklärt.
Warum weiß Query Monitor aber, dass wir hier beim richtigen CPT sind???
Vorhang auf für get_queried_object()!
WordPress macht aus einer URL eine Abfrage.
Es wird also versucht, aus den Informationen einer URL eine Datenbank-Abfrage zu erstellen, eben eine Datenbank Query zu erzeugen.
Und hier sind wir wieder bei der wp_query]}**!
Wir sehen in den Screenshots oben, dass die wp_query]}** ja weiß, dass wir nach dem Post Type „wbm_customer“ suchen.
Das weiß die wp_query]}** ja aus der URL.
Wenn das die wp_query]}** weiß, dann brauchen wir die WP_QUERY]}** nur fragen, wie der Post Type heißt.
Genau das macht get_queried_object()!
In unserem Fall sieht man das auch, wenn man sich die WP_Query]}** ausgeben lässt:
Bingo! Es ist ein Custom Post Type! Wir haben es geschafft :)