Für mich eine sehr spannende Frage. Immerhin habe ich mich gerade wieder (leider nicht zum ersten Mal) dabei erwischt, eine WordPress Template-Datei namens taxonomy-shiny_recipe_course.php zu erstellen. Prinzipiell ist daran natürlich nichts Verwerfliches. Die Datei folgt den Konventionen von Template-Files, die WordPress vorgibt und sie tut auch genau das, was sie soll (Sie gibt ein Template für alle Seiten vor, die aus einer meiner Rezept-Kategorien stammen.).
Nur in meinem Fall ist der Einsatz solch einer Datei eben nicht sinnvoll, denn erstens gibt es die WordPress-Funktion get_template_part() und zweitens ist die oben erwähnte .php Datei nur eine von jetzt insgesamt 26 Template-Dateien. Diese Anzahl sollte sich drastisch eindampfen lassen, wenn man die Funktion sinnvoll einsetzt. Wie es zu der großen Anzahl an Dateien gekommen ist, ob ich sie reduzieren kann und ob dieser Ansatz nützlich ist, möchte ich in diesem und in dem folgenden Artikel klären. Doch zuerst muss ich dazu erklären, was es mit der Funktion überhaupt auf sich hat.

get_template_part()ist eine WordPress Funktion, die innerhalb des Loops in einer Template Datei aufgerufen werden kann. Wie Konstantin Kovshenin in seinem Artikel erwähnt ist sie eigentlich eine PHP require() bzw. include() Funktion „on steroids“.
Sie dient dazu, vordefinierte Template-Bereiche einzubinden und funktioniert auch mit Child-Themes.
Sie nimmt bis zu zwei Parameter entgegen <?php get_template_part( $slug, $name ); ?> und sucht dann das den Parametern entsprechende File im Template-Ordner. Am einfachsten erklärt sich das mit einem Beispiel aus der Praxis. Wer schon einmal in die Themes Twentyfifteen und Twentyfourteen hineingeschaut hat, wird an einigen Stellen sowas hier finden:
<?php get_template_part('content', 'image' ); ?>Diese Funktion bindet die Datei content-image.php ein. Beide Parameter können aber auch anders aussehen: Wie wäre es z.B. mit:
<?php get_template_part('navigation', 'above' ); ?>So ließe sich der (in der navigation-above.php zu definierende) Code einbinden um beispielsweise eine Beitrags-Navigation über einem Beitrag einzubringen. Und weil es so schön ist, ruft man gleich unterhalb der Beiträge noch die Funktion
<?php get_template_part('navigation', 'below' ); ?> auf. Theoretisch lässt sich so das gesamte WordPress-Theme in kleine, wiederverwertbare Teile aufbrechen, die jederzeit eingebunden werden können. Dabei können die Dateien auch in einem Unterordner liegen. Hierfür schreibt man dann:
<?php get_template_part('unterordner/navigation', 'below' ); ?>Das ist die etwas statischere Möglichkeit, Template-Bereiche einzubinden, es gibt noch andere.

Die flexiblere Art, Content einzubinden

<?php get_template_part('content', get_post_format() ); ?>ist eine etwas flexiblere Art. Der Parameter get_post_format() ist wiederum selbst ein Funktionsaufruf, der zurückgibt, welches Post-Format der gerade betrachtete und einzubindende Beitrag hat. Im Beispiel: Die Funktion wird im Loop der archive.php aufgerufen. Im Archiv befinden sich aber nicht nur normale Text-Beiträge, sondern auch Image-Beiträge, Status-Meldungen etc. Nun findet die Funktion get_post_format() für uns das Post-Format des gerade auszugebenden Posts heraus, und gibt sie an get_template_part() weiter. So könnten dann die Loop Durchläufe folgende Ergebnisse bringen:

  1. get_template_part(‚content‘, ‚post‘ ); //ruft an der Stelle die content-post.php auf
  2. get_template_part(‚content‘, ‚image‘ ); //ruft an der Stelle die image-post.php auf
  3. get_template_part(‚content‘, ’status‘ ); //ruft an der Stelle die status-post.php auf

get_post_format findet für uns nicht nur Standard Post-Formate heraus, sondern gibt auch selbst erstellte Custom Post Types zurück. In den aufgerufenen content-xxx.php wird dann noch definiert, wie ein einzelner Post-Beitrag der entsprechenden Art auszusehen hat und schon ist man für alles gerüstet. Oder?

Achtung! es gibt einen Haken!

Und was passiert, wenn content-image.php nicht gefunden werden kann? Dann sucht die Funktion als nächstes einfach nach einer content.php. Grundsätzlich ist es auch möglich, nur einen Parameter an die Funktion zu übergeben: <?php get_template_part( $slug ); ?> sucht nur nach slug.php. Wenn es diese Dateien aber nicht gibt, gibt die Funktion keinen Rückgabewert und auch keine Warnung aus. Es wird also einfach nichts angezeigt! Wenn ich dementsprechend keine rezepte.php definiert habe, sie aber versuche mit <?php get_template_part( ‚rezepte‘ ); ?> aufzurufen, sehe ich keine Ausgabe im Loop. Es muss also schon vor der Template-Erstellung gut überlegt werden, welche Art von Content anzeigt werden soll und es müssen ensprechende Template-Files angelegt werden.

Verwendung im Child-Theme

Ein Child-Theme baut auf einem Parent-Theme auf und bietet die Möglichkeit, einzelne Bereiche zu „überschreiben“. Zum besseren Verständnis empfehle ich den WordPress-Codex-Eintrag zum Theme zu lesen. Wird die Funktion <?php get_template_part( $slug ); ?> in einem Child-Theme aufgerufen, so wird sie erst im Child-Theme Ordner nach einer entsprechenden Datei slug.php zur Anzeige suchen. Nutzt man allerdings die Funktion mit zwei Parametern <?php get_template_part( $slug, $name ); ?> sieht die Logik des Suchens und Einbindens ein bisschen anders aus:

  1. slug-name.php // im Child Theme
  2. slug-name.php // im Eltern Theme
  3. slug.php // im Child Theme
  4. slug.php // im Eltern Theme

Referenzen und Quellen

WordPress Codex – Funktions Referenz "get_template_part()"
WordPress Codex – Child Themes
https://kovshenin.com/2013/get_template_part/