Hallo zusammen!
Heute möchte ich ein Thema aufgreifen, das WordPress noch einmal deutlich flexibler macht: sogenannte Custom Post Types.
In WordPress gibt es standardmäßig vor allem Seiten und Beiträge. Seiten werden meistens für statische Inhalte wie Startseite, Kontakt, Über mich oder Leistungsseiten verwendet. Beiträge sind hingegen eher für Blog- oder News-Inhalte gedacht und werden automatisch in einem Archiv gesammelt.
Möchte man auf einer Website jedoch weitere eigene Inhaltsbereiche mit eigenem Archiv aufbauen – zum Beispiel für Projekte, Referenzen, Veranstaltungen oder Teammitglieder – kommt man mit den Standard-Inhaltstypen schnell an eine Grenze.
Genau hier kommen Custom Post Types ins Spiel. Damit lassen sich eigene Inhaltstypen erstellen, die im WordPress Backend separat verwaltet und auf der Website gesammelt ausgegeben werden können.
In diesem Beitrag zeige ich euch Schritt für Schritt:
- was ein Custom Post Type überhaupt ist
- wann ein Custom Post Type sinnvoll ist
- wie ihr einen eigenen Custom Post Type per Code erstellt
- welche Parameter dabei wichtig sind
- wie ihr eigene Kategorien und Schlagwörter hinzufügt
- worauf ihr bei den Permalinks achten solltet
- und was bei der Ausgabe auf der Website wichtig ist
Als Beispiel erstelle ich in diesem Beitrag einen Custom Post Type für Projekte. Das ist ein typischer Anwendungsfall und lässt sich später gut auf andere Bereiche wie Referenzen, Events oder Teammitglieder übertragen.
Da wir hier mit Code arbeiten, sollte dieser idealerweise im Child Theme eingebunden werden. Falls ihr noch kein Child Theme erstellt habt, findet ihr dazu bereits einen eigenen Beitrag auf meinem Blog.
Los geht’s!
#1 Was ist ein Custom Post Type?
Ein Custom Post Type (CPT) ist ein eigener Inhaltstyp in WordPress.
WordPress arbeitet im Hintergrund mit sogenannten Post Types. Standardmäßig gibt es zum Beispiel Seiten und Beiträge. Seiten werden meist für statische Inhalte wie Startseite, Kontakt, Über mich oder Leistungsseiten verwendet. Beiträge sind eher für klassische Blog- oder News-Inhalte gedacht.
Mit einem Custom Post Type kann man diese Struktur erweitern und eigene Inhaltstypen anlegen.
Das können zum Beispiel Projekte, Referenzen, Veranstaltungen, Teammitglieder, Immobilien oder Downloads sein.
Ein Custom Post Type erscheint im WordPress Backend als eigener Bereich und kann unabhängig von normalen Seiten oder Beiträgen verwaltet werden.
#2 Wann ist ein Custom Post Type sinnvoll?
Ein Custom Post Type ist dann sinnvoll, wenn mehrere gleichartige Inhalte gesammelt verwaltet und auf der Website als eigenes Archiv dargestellt werden sollen.
Ein einfaches Beispiel:
Wenn ich auf einer Website ein einzelnes Projekt vorstellen möchte, reicht dafür meistens eine normale Seite. Möchte ich aber regelmäßig neue Projekte veröffentlichen und diese gesammelt in einer Projektübersicht anzeigen, ist ein eigener Custom Post Type die sauberere Lösung.
Der Vorteil ist, dass man einmal die Struktur und Darstellung für diesen Inhaltstyp vorbereitet und danach im WordPress Backend immer wieder neue Einträge hinzufügen kann. Diese erscheinen dann automatisch im jeweiligen Archiv.
Das ist besonders praktisch bei Inhalten wie:
- Projekten
- Referenzen
- Veranstaltungen
- Immobilien
- Downloads
- Jobs
- Produkte
Kurz gesagt:
Eine normale Seite eignet sich gut für einzelne Inhalte.
Ein Custom Post Type eignet sich dann, wenn viele ähnliche Einträge verwaltet, sortiert und gesammelt dargestellt werden sollen.
Die Gestaltung des Archivs oder der einzelnen Detailseite passiert anschließend separat – zum Beispiel über das Theme, Elementor oder eigene Templates.
#3 Vorbereitung: Wohin kommt der Code?
Da ein Custom Post Type per PHP-Code registriert wird, muss dieser Code an einer geeigneten Stelle in WordPress eingebunden werden.
Eine saubere Möglichkeit ist die functions.php des Child Themes. So bleiben die Anpassungen vom eigentlichen Parent Theme getrennt und werden bei einem Theme-Update nicht überschrieben.
Alternativ könnte man für solche Funktionen auch ein eigenes Plugin oder ein Code-Snippet-Plugin verwenden. In diesem Beitrag gehe ich aber davon aus, dass der Code im Child Theme eingebunden wird.
#4 Custom Post Type erstellen
Jetzt erstellen wir den eigentlichen Custom Post Type.
In meinem Beispiel lege ich einen Inhaltstyp für Projekte an. Der technische Name lautet dabei „projekt“, im WordPress Backend wird der Bereich aber ganz normal als „Projekte“ angezeigt.
Im nächsten Punkt gehe ich genauer auf die einzelnen Parameter ein.
Der folgende Code kommt in die functions.php eures Child Themes:
function lumelab_register_projekte_cpt() {
$labels = array(
'name' => 'Projekte',
'singular_name' => 'Projekt',
'menu_name' => 'Projekte',
'name_admin_bar' => 'Projekt',
'add_new' => 'Neues Projekt',
'add_new_item' => 'Neues Projekt hinzufügen',
'new_item' => 'Neues Projekt',
'edit_item' => 'Projekt bearbeiten',
'view_item' => 'Projekt ansehen',
'all_items' => 'Alle Projekte',
'search_items' => 'Projekte suchen',
'not_found' => 'Keine Projekte gefunden',
'not_found_in_trash' => 'Keine Projekte im Papierkorb gefunden',
);
$args = array(
'label' => 'Projekte',
'description' => 'Eigener Inhaltstyp für Projekte.',
'labels' => $labels,
'public' => true,
'show_in_rest' => true,
'rewrite' => array('slug' => 'projekte', 'with_front' => false),
'has_archive' => true,
'menu_position' => 20,
'menu_icon' => 'dashicons-portfolio',
'supports' => array('title', 'editor', 'thumbnail', 'excerpt', 'revisions'),
);
register_post_type( 'projekt', $args );
}
add_action( 'init', 'lumelab_register_projekte_cpt' );
Nach dem Einfügen erscheint im WordPress Backend ein neuer Menüpunkt „Projekte“. Dort können anschließend einzelne Projekte angelegt und verwaltet werden.
Der technische Name projekt ist wichtig, weil WordPress diesen intern verwendet. Der sichtbare Name im Backend wird hingegen über die Labels gesteuert.
In diesem Beispiel bekommt der Custom Post Type außerdem ein eigenes Archiv mit dem Slug:
/projekte/
Die einzelnen Projekte wären später dann zum Beispiel unter folgenden URLs erreichbar:
/projekte/projektname/
Wichtig: Nachdem ein Custom Post Type mit eigenem Slug erstellt wurde, sollten die Permalinks in WordPress einmal neu gespeichert werden. Darauf gehe ich weiter unten noch genauer ein.
#5 Die wichtigsten Parameter erklärt
Im Code oben werden verschiedene Parameter verwendet, mit denen der Custom Post Type gesteuert wird. Damit das Ganze verständlicher wird, gehe ich die wichtigsten Punkte kurz durch.
Mit „labels“ werden die Bezeichnungen im WordPress Backend definiert. Also zum Beispiel wie der Menüpunkt heißt, welcher Text beim Hinzufügen eines neuen Eintrags angezeigt wird oder welche Meldung erscheint, wenn kein Projekt gefunden wurde.
Der Parameter „public“ legt fest, ob der Custom Post Type öffentlich sichtbar und grundsätzlich auf der Website abrufbar ist. In den meisten Fällen wird dieser Wert auf `true` gesetzt, wenn der Inhalt später auch im Frontend angezeigt werden soll.
Mit „show_in_rest` wird der Custom Post Type für den modernen WordPress Editor und die REST API verfügbar gemacht. Das ist heute in vielen Fällen sinnvoll, da Gutenberg, Elementor und andere moderne Funktionen darauf zurückgreifen können.
Über „rewrite“ wird der URL-Slug des Custom Post Types definiert. In meinem Beispiel lautet dieser „projekte“. Dadurch kann das Archiv später unter „/projekte/“ erreichbar sein und einzelne Projekte bekommen URLs wie „/projekte/projektname/“.
Mit „has_archive“ wird festgelegt, ob WordPress für diesen Custom Post Type automatisch ein Archiv bereitstellt. Da wir in diesem Beispiel alle Projekte gesammelt ausgeben möchten, steht dieser Wert auf „true“.
Die „menu_position“ steuert, an welcher Stelle der neue Menüpunkt im WordPress Backend angezeigt wird. Die Zahl „20“ platziert den Menüpunkt ungefähr im Bereich der normalen Seiten. Je nach Projekt kann dieser Wert natürlich angepasst werden. Einfach ausprobieren und den Wert gegebenenfalls erhöhen oder verringern um die Position zu verändern.
Über „menu_icon“ wird das Icon im WordPress Backend festgelegt. WordPress verwendet dafür sogenannte Dashicons. In meinem Beispiel nutze ich: menu_icon‘ => ‚dashicons-portfolio‘,
Eine Übersicht aller verfügbaren Dashicons findet ihr direkt in der offiziellen Dashicons-Übersicht von WordPress.
Mit „supports“ wird definiert, welche Felder und Funktionen der Custom Post Type im Backend unterstützen soll. In meinem Beispiel sind das: ’supports‘ => array( ‚title‘, ‚editor‘, ‚thumbnail‘, ‚excerpt‘, ‚revisions‘ ),
Damit stehen beim Projekt unter anderem Titel, Inhaltsfeld, Beitragsbild, Auszug und Revisionen zur Verfügung.
Möchte man also kein Beitragsbild oder keinen Auszug, löscht man ‚thumbnail‘ oder ‚excerpt‘ einfach aus dem array.
Der eigentliche Custom Post Type wird am Ende mit registriert: register_post_type( ‚projekt‘, $args );
Der erste Wert „projekt“ ist der technische Name des Custom Post Types. Dieser sollte möglichst kurz, eindeutig und kleingeschrieben sein. Die Einstellungen selbst werden über das „$args“ Array übergeben.
Damit WordPress den Custom Post Type zum richtigen Zeitpunkt lädt, wird die Funktion über den „init“ Hook eingebunden: add_action( ‚init‘, ‚lumelab_register_projekte_cpt‘ );
#6 Taxonomien und Kategorien hinzufügen
Ein Custom Post Type ist meistens erst dann wirklich praktisch, wenn man die einzelnen Einträge auch sortieren oder gruppieren kann.
Bei normalen WordPress-Beiträgen kennt man dafür Kategorien und Schlagwörter. Technisch gesehen sind das sogenannte Taxonomien.
Eine Taxonomie ist also eine Art Ordnungssystem innerhalb von WordPress. Die einzelnen Begriffe innerhalb dieser Taxonomie nennt man Terms. Bei klassischen Beiträgen wäre die Taxonomie zum Beispiel „Kategorie“ und die einzelnen Kategorien wären dann Begriffe wie „News“, „Tipps“ oder „Allgemein“.
Für unseren Custom Post Type „Projekte“ können wir nun ebenfalls eine eigene Taxonomie anlegen. In diesem Beispiel nenne ich sie „Projekt-Kategorien“.
Damit könnte man Projekte später zum Beispiel nach Webdesign, Printdesign, oder Corporate Design sortieren.
Der folgende Code ergänzt den bestehenden Custom Post Type um eigene Projekt-Kategorien:
function lumelab_register_projekt_taxonomy() {
$labels = array(
'name' => 'Projekt-Kategorien',
'singular_name' => 'Projekt-Kategorie',
'search_items' => 'Projekt-Kategorien suchen',
'all_items' => 'Alle Projekt-Kategorien',
'parent_item' => 'Übergeordnete Projekt-Kategorie',
'parent_item_colon' => 'Übergeordnete Projekt-Kategorie:',
'edit_item' => 'Projekt-Kategorie bearbeiten',
'update_item' => 'Projekt-Kategorie aktualisieren',
'add_new_item' => 'Neue Projekt-Kategorie hinzufügen',
'new_item_name' => 'Name der neuen Projekt-Kategorie',
'menu_name' => 'Projekt-Kategorien',
);
$args = array(
'labels' => $labels,
'hierarchical' => true,
'public' => true,
'show_ui' => true,
'show_admin_column' => true,
'show_in_rest' => true,
'rewrite' => array( 'slug' => 'projekt-kategorie' ),
);
register_taxonomy( 'projekt_kategorie', array( 'projekt' ), $args );
}
add_action( 'init', 'lumelab_register_projekt_taxonomy' );
Wichtig ist hier vor allem diese Zeile:
register_taxonomy( ‚projekt_kategorie‘, array( ‚projekt‘ ), $args );
Mit projekt_kategorie wird der technische Name der Taxonomie definiert. Über array( ‚projekt‘ ) wird festgelegt, dass diese Taxonomie mit unserem Custom Post Type „projekt“ verbunden wird.
Der Parameter hierarchical steht in diesem Beispiel auf true. Dadurch verhält sich die Taxonomie wie klassische Kategorien in WordPress. Man kann also übergeordnete und untergeordnete Begriffe anlegen.
Würde man hierarchical auf false setzen, würde sich die Taxonomie eher wie Schlagwörter verhalten.
Nach dem Einfügen erscheint im WordPress Backend unter dem Menüpunkt „Projekte“ ein neuer Bereich für die Projekt-Kategorien. Dort können anschließend Kategorien erstellt und den einzelnen Projekten zugewiesen werden.
#7 Schlagwörter für den Custom Post Type
Neben Kategorien kann es auch sinnvoll sein, einem Custom Post Type eigene Schlagwörter hinzuzufügen.
Der Unterschied liegt vor allem in der Struktur und in der späteren Verwendung. Kategorien sind hierarchisch aufgebaut. Man kann also Hauptkategorien und Unterkategorien erstellen. Dadurch eignen sie sich sehr gut, wenn Inhalte bewusst in größere Bereiche gegliedert werden sollen.
Gerade wenn man später eigene Archivseiten oder globale Archiv-Templates erstellt – zum Beispiel mit Elementor – sind Kategorien oft die bessere Grundlage. So kann man beispielsweise ein eigenes Archiv für eine bestimmte Projekt-Kategorie gestalten und dort automatisch alle passenden Einträge ausgeben lassen.
Schlagwörter sind hingegen nicht hierarchisch. Sie dienen eher dazu, Inhalte zusätzlich frei zu verschlagworten. Bei Projekten könnte man zum Beispiel Kategorien wie „Webdesign“, „Printdesign“ oder „Corporate Design“ verwenden und zusätzlich Schlagwörter wie „WordPress“, „Elementor“, „E-Commerce“ oder „Logo Design“ vergeben.
Das ist besonders dann praktisch, wenn sehr viele Einträge vorhanden sind und später eine Filter- oder Suchfunktion eingebaut werden soll. Schlagwörter können dabei helfen, Inhalte zusätzlich zu den Kategorien noch genauer einzugrenzen.
Auch Schlagwörter werden in WordPress als Taxonomie angelegt. Der entscheidende Unterschied zur vorherigen Projekt-Kategorie liegt hauptsächlich im Parameter hierarchical.
Bei Schlagwörtern steht dieser Wert auf false.
Der folgende Code ergänzt unseren Custom Post Type „Projekte“ um eigene Projekt-Schlagwörter:
function lumelab_register_projekt_tags() {
$labels = array(
'name' => 'Projekt-Schlagwörter',
'singular_name' => 'Projekt-Schlagwort',
'search_items' => 'Projekt-Schlagwörter suchen',
'popular_items' => 'Beliebte Projekt-Schlagwörter',
'all_items' => 'Alle Projekt-Schlagwörter',
'edit_item' => 'Projekt-Schlagwort bearbeiten',
'update_item' => 'Projekt-Schlagwort aktualisieren',
'add_new_item' => 'Neues Projekt-Schlagwort hinzufügen',
'new_item_name' => 'Name des neuen Projekt-Schlagworts',
'separate_items_with_commas' => 'Schlagwörter mit Kommas trennen',
'add_or_remove_items' => 'Schlagwörter hinzufügen oder entfernen',
'choose_from_most_used' => 'Aus häufig verwendeten Schlagwörtern wählen',
'not_found' => 'Keine Projekt-Schlagwörter gefunden',
'menu_name' => 'Projekt-Schlagwörter',
);
$args = array(
'labels' => $labels,
'hierarchical' => false,
'public' => true,
'show_ui' => true,
'show_admin_column' => true,
'show_in_rest' => true,
'rewrite' => array( 'slug' => 'projekt-schlagwort' ),
);
register_taxonomy( 'projekt_schlagwort', array( 'projekt' ), $args );
}
add_action( 'init', 'lumelab_register_projekt_tags' );
Wichtig ist hier wieder die Verbindung zum Custom Post Type: register_taxonomy( ‚projekt_schlagwort‘, array( ‚projekt‘ ), $args );
Mit „projekt_schlagwort“ wird der technische Name der Taxonomie definiert. Über „array( ‚projekt‘ )“ wird festgelegt, dass diese Schlagwörter dem Custom Post Type „projekt“ zugewiesen werden.
Der entscheidende Unterschied zu den Projekt-Kategorien ist dieser Parameter: ‚hierarchical‘ => false,
Dadurch verhält sich diese Taxonomie wie klassische Schlagwörter und nicht wie Kategorien.
Ob man zusätzlich zu Kategorien auch Schlagwörter benötigt, hängt immer vom jeweiligen Projekt ab. Für einfache Projektarchive reichen Kategorien oft völlig aus. Wenn Inhalte jedoch zusätzlich nach bestimmten Begriffen, Technologien oder Themen gefiltert werden sollen, können eigene Schlagwörter sehr praktisch sein.
#8 Permalinks neu speichern
Nachdem ein Custom Post Type oder eine neue Taxonomie erstellt wurde, sollten in WordPress einmal die Permalinks neu gespeichert werden.
Das ist wichtig, damit WordPress die neuen URL-Strukturen korrekt erkennt.
Dafür geht ihr im WordPress Backend einfach zu: Einstellungen → Permalinks
Dort müsst ihr keine Einstellung verändern. Es reicht, einmal auf „Änderungen speichern“ zu klicken.
Gerade wenn nach dem Erstellen eines Custom Post Types plötzlich eine 404-Seite erscheint, obwohl der Code korrekt ist, liegt es sehr oft daran, dass die Permalinks noch nicht neu gespeichert wurden.
Das ist ein kleiner Schritt, aber in der Praxis extrem wichtig.
#9 Custom Post Type auf der Website ausgeben
Mit dem bisherigen Code ist der Custom Post Type im WordPress Backend angelegt und kann verwendet werden. Das bedeutet aber noch nicht automatisch, dass die Projekte auf der Website bereits schön gestaltet ausgegeben werden.
Der Code erstellt zunächst nur die Inhaltsstruktur.
Wie das Archiv oder die einzelne Detailseite später aussieht, hängt vom verwendeten Theme und vom Aufbau der Website ab. In vielen Fällen wird die Ausgabe über das Theme, den Elementor Theme Builder oder eigene Templates gestaltet.
Bei unserem Beispiel könnte man zum Beispiel ein Projekt-Archiv erstellen, in dem alle Projekte automatisch gesammelt angezeigt werden. Zusätzlich kann für einzelne Projekte eine eigene Detailansicht gestaltet werden.
Der große Vorteil ist: Sobald diese Ausgabe einmal vorbereitet ist, müssen neue Projekte nur noch im WordPress Backend angelegt werden. Sie erscheinen dann automatisch im passenden Archiv.
Genau das macht Custom Post Types so praktisch für strukturierte Inhalte.
#10 Fazit
Custom Post Types sind eine wirklich praktische Möglichkeit, WordPress um eigene Inhaltsbereiche zu erweitern.
Gerade wenn Inhalte nicht nur einmalig als Seite angelegt, sondern regelmäßig ergänzt und gesammelt dargestellt werden sollen, sind CPTs eine sehr saubere Lösung. Ob Projekte, Referenzen, Veranstaltungen oder andere strukturierte Inhalte – mit einem eigenen Custom Post Type bleibt das WordPress Backend übersichtlich und die Ausgabe auf der Website lässt sich gezielt vorbereiten.
Natürlich ist das Thema etwas technischer als viele andere WordPress-Grundlagen. Wenn man die Logik dahinter aber einmal verstanden hat, eröffnen sich dadurch sehr viele Möglichkeiten.
Ich hoffe, ich konnte euch mit diesem Beitrag einen guten Überblick geben und zeigen, wie sich ein eigener Custom Post Type inklusive Kategorien und Schlagwörtern per Code erstellen lässt.
– Stefan