Einen Custom Post Type in WordPress erstellen

WordPress wird standardmäßig mit Beiträgen und Seiten ausgeliefert, doch diese beiden Inhaltstypen reichen nicht weit, wenn ein Kunde ein Immobilienverzeichnis, eine Mitarbeiterliste oder ein Rezeptarchiv benötigt. Hier kommt ein WordPress Custom Post Type ins Spiel — eine vollwertige Inhaltsstruktur, die sich nahtlos in das bestehende Datenmodell von WordPress einfügt, ohne die Standardeinstellungen zu umgehen.

Was ist ein Custom Post Type?

Ein Custom Post Type (CPT) ist ein benannter Inhaltstyp, den Sie bei WordPress registrieren. Trotz des Namens handelt es sich nicht um eine separate Datenbanktabelle. Alle Post Types — eingebaute und benutzerdefinierte — teilen sich die wp_posts-Tabelle und werden durch die Spalte post_type unterschieden. Das ist ein wichtiges mentales Modell: Sie erweitern eine bestehende Struktur, anstatt eine parallele zu erstellen.

Zu den Standard-Post-Types gehören post, page, attachment, revision und nav_menu_item. Wenn Sie einen CPT wie property oder recipe registrieren, behandelt WordPress ihn mit derselben Konsistenz: Admin-Oberflächen, REST-API-Endpunkte, URL-Routing und Template-Hierarchie funktionieren alle auf die gleiche Weise.

Custom Post Types ≠ Custom Fields. Ein CPT definiert den Typ des Inhalts. Custom Fields (hinzugefügt über ACF oder die Metadata-API) speichern zusätzliche Daten, die an diesen Inhalt angehängt sind. Dies sind separate Anliegen.

Registrierung eines Custom Post Type mit register_post_type()

Der kanonische Weg, einen WordPress Custom Post Type zu erstellen, ist die Funktion register_post_type(), die am init-Hook aufgerufen wird.

Hier ist ein sauberes, funktionierendes Beispiel:

add_action( 'init', 'register_property_post_type' );

function register_property_post_type() {
    $labels = [
        'name'               => 'Properties',
        'singular_name'      => 'Property',
        'add_new_item'       => 'Add New Property',
        'edit_item'          => 'Edit Property',
        'not_found'          => 'No properties found.',
    ];

    $args = [
        'labels'       => $labels,
        'public'       => true,
        'has_archive'  => true,
        'supports'     => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
        'rewrite'      => [ 'slug' => 'properties' ],
        'show_in_rest' => true,
    ];

    register_post_type( 'property', $args );
}

Wichtige Argumente erklärt

• public — Macht den CPT im Admin-Bereich und im Frontend sichtbar. Setzen Sie dies auf false für rein interne Typen.
• labels — Steuert alle UI-Texte im Admin-Bereich. Es lohnt sich, diese ordentlich auszufüllen, damit Redakteure nicht verwirrt werden.
• supports — Deklariert, welche Editor-Funktionen auf dem Bearbeitungsbildschirm erscheinen. Häufige Werte: title, editor, thumbnail, excerpt, custom-fields.
• has_archive — Aktiviert eine Archivseite unter /properties/. WordPress sucht nach einem passenden archive-property.php-Template (oder fällt auf archive.php zurück).
• rewrite — Legt den URL-Slug fest. Einzelne Beiträge erscheinen unter /properties/post-name/.
• show_in_rest — Setzen Sie dies auf true. Dies stellt den CPT über die WordPress REST API bereit und ist erforderlich, damit der Block-Editor korrekt mit Ihrem Post Type funktioniert. Ohne diese Einstellung fällt der Editor auf die klassische Oberfläche zurück.

Plugin vs. Theme: Wo sollte der Code leben?

Dies ist ein häufiger Punkt der Verwirrung. Registrieren Sie Ihren Custom Post Type in einem Plugin, nicht in einem Theme.

Wenn Ihre CPT-Registrierung in der functions.php liegt und der Kunde das Theme wechselt, werden alle Inhalte dieses Typs unzugänglich — nicht gelöscht, aber unsichtbar. Ein dediziertes Plugin (selbst ein einfaches Ein-Datei-Plugin) hält den CPT unabhängig von Theme-Wechseln aktiv.

Leeren Sie Rewrite-Regeln nicht bei jeder Anfrage. Rufen Sie flush_rewrite_rules() nur einmal auf — bei Plugin-Aktivierung über register_activation_hook(). Das Leeren bei jedem init ist ein Performance-Problem.

Template-Hierarchie für Custom Post Types

WordPress sucht nach Templates in dieser Reihenfolge für einen einzelnen CPT-Eintrag:

1. single-{post-type}.php (z.B. single-property.php)
2. single.php
3. singular.php
4. index.php

Für Archive folgt es: archive-{post-type}.php → archive.php → index.php.

Fazit

Mit register_post_type(), korrekt am init-Hook eingehängt, aktiviertem show_in_rest und der Registrierung in einem Plugin haben Sie eine solide, portable Grundlage. Von hier aus können Sie Custom Taxonomies, Meta-Felder über ACF oder die Metadata-API und benutzerdefinierte Admin-Spalten hinzufügen — ohne etwas anzufassen, das bei WordPress- oder Theme-Updates kaputt gehen würde.

FAQs

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.