Nutzer füllten in ihrem persönlichen Konto ein Formular aus, klickten auf „Absenden", und der Antrag landete im öffentlichen Feed der Website. Mitsamt Telefonnummer, Adresse und Passdaten.

Das passiert, wenn ein benutzerdefinierter Beitragstyp als öffentlich konfiguriert ist. WordPress zeigt standardmäßig alles an, was mit 'public' => true erstellt wurde, egal ob von einem Administrator oder einem Besucher über ein Frontend-Formular in WP-Recall veröffentlicht.

Nachfolgend eine Schritt-für-Schritt-Anleitung: Wir erstellen einen benutzerdefinierten Beitragstyp, weisen ihm bei der Veröffentlichung einen privaten Status zu und konfigurieren eine Weiterleitung zurück zum Benutzerkonto. Ohne teure All-in-One-Plugins: WP-Recall, MB Custom Post Type und drei Funktionen in functions.php.

💡 Kurzüberblick:

• Installieren Sie WP-Recall und MB Custom Post Type, zwei kostenlose Plugins aus dem WordPress.org-Verzeichnis.
• Erstellen Sie einen benutzerdefinierten Beitragstyp über die Oberfläche von MB Custom Post Type, ohne eine einzige Codezeile.
• Fügen Sie drei Funktionen in functions.php hinzu: CPT-Registrierung per Code (optional), Weiterleitung nach der Veröffentlichung und automatischer Übergang in den Status private.
• Prüfen: Der Nutzer veröffentlicht einen Antrag aus seinem persönlichen Konto, dieser ist nur für Administratoren und Redakteure sichtbar.

Schritt 1: WP-Recall und MB Custom Post Type installieren

Sie benötigen zwei Plugins. Beide sind kostenlos und im offiziellen WordPress.org-Verzeichnis verfügbar.

WP-Recall erstellt ein persönliches Benutzerkonto: Registrierung, Profil, private Nachrichten und, was für unsere Aufgabe wichtig ist, das Veröffentlichen von Beiträgen über das Frontend. Der Nutzer meldet sich in seinem Konto an, füllt das Formular aus und sendet den Antrag ab. Kein Admin-Panel, alles geschieht auf den Seiten der Website.

MB Custom Post Types & Custom Taxonomies, eine Erweiterung des Meta Box-Plugins. Bietet eine visuelle Oberfläche zum Erstellen benutzerdefinierter Beitragstypen und Taxonomien. Zum Zeitpunkt des Schreibens hat das Plugin über 10.000 aktive Installationen und eine Bewertung von 4,7 auf WordPress.org. Es wird regelmäßig aktualisiert, die letzte Version wurde im Juni 2026 veröffentlicht.

Beide Plugins werden auf dem Standardweg installiert: Plugins → Installieren, nach Namen suchen, „Installieren" → „Aktivieren".

Schritt 2: Benutzerdefinierten Beitragstyp über die MB Custom Post Type-Oberfläche erstellen

Nach der Aktivierung des Plugins erscheint im Admin-Panel das Menü Meta Box → Beitragstypen. Klicken Sie auf „Neu hinzufügen" und füllen Sie die Felder aus:

Wichtige Einstellungen, die Sie gleich konfigurieren sollten:

• Beitragstyp-ID, Systemname in lateinischer Schrift, zum Beispiel claim oder user_request. Dieser Slug erscheint in URLs und im Code.
• Bezeichnungen, das Plugin füllt die deutschen Bezeichnungen automatisch aus, wenn Sie den Namen im Feld Singular Name auf Deutsch eingeben. Bearbeiten Sie manuell, was für Sie nicht passt.
• Unterstützt, aktivieren Sie title, editor und custom-fields. Beitragsbild und Kommentare werden für Anträge in der Regel nicht benötigt.
• Von Suche ausschließen, aktivieren. Benutzerbeiträge sollen nicht indexiert werden.
• Öffentlich, true (das WP-Recall-Formular muss den Beitragstyp sehen). Den Datenschutz regeln wir mit Code in Schritt 4.

Klicken Sie auf „Speichern", der benutzerdefinierte Beitragstyp ist registriert. Dasselbe Ergebnis lässt sich mit Code erreichen (eine Alternative für diejenigen, die functions.php bevorzugen):

1
function sdstudio_register_private_cpt() {
2
    $args = array(
3
        'label'               => 'Applications',
4
        'public'              => true,
5
        'exclude_from_search' => true,
6
        'publicly_queryable'  => true,
7
        'show_ui'             => true,
8
        'show_in_rest'        => false,
9
        'menu_icon'           => 'dashicons-lock',
10
        'capability_type'     => 'post',
11
        'hierarchical'        => false,
12
        'has_archive'         => false,
13
        'supports'            => array( 'title', 'editor', 'author', 'custom-fields' ),
14
        'rewrite'             => array( 'slug' => 'claims' ),
15
    );
16
 
17
    register_post_type( 'user_claim', $args );
18
}
19
add_action( 'init', 'sdstudio_register_private_cpt' );

Fügen Sie diesen Code in die functions.php Ihres Child-Themes oder über das Code Snippets-Plugin ein. Nach dem Speichern erscheint im Admin-Panel ein Bereich „Anträge" in der Seitenleiste.

Schritt 3: Weiterleitung nach der Veröffentlichung konfigurieren

Standardmäßig zeigt WP-Recall dem Nutzer nach dem Absenden den Beitrag selbst an. Für Anträge ist das sinnlos, die Person benötigt ihr persönliches Konto, nicht eine Seite mit dem gerade abgesendeten Formular.

Die folgende Funktion fängt den update_post_rcl-Hook ab (WP-Recall-Ereignis nach der Veröffentlichung) und leitet den Nutzer zurück in seinen Antragsbereich:

1
/**
2
 * Redirect to personal account after publishing a post via WP-Recall.
3
 * Add to functions.php of the child theme.
4
 */
5
function sdstudio_redirect_after_rcl_publish() {
6
    $user_id = get_current_user_id();
7
    wp_redirect( '/account/?user=' . $user_id . '&tab=publics' );
8
    exit;
9
}
10
add_action( 'update_post_rcl', 'sdstudio_redirect_after_rcl_publish' );

Hier wird get_current_user_id() innerhalb der Funktion aufgerufen, anders als beim verbreiteten Muster mit einer Variable außerhalb, das ist unabhängig von der Reihenfolge des Dateiaufrufs zuverlässig. Ersetzen Sie den Pfad /account/ durch die URL Ihres persönlichen Kontos in Ihrer WP-Recall-Installation.

Prüfen: Melden Sie sich als Testnutzer an, veröffentlichen Sie einen Beitrag aus dem Konto, der Browser sollte zur Seite mit der Antragsliste zurückkehren.

Schritt 4: Beitrag automatisch auf privat setzen

Das ist der entscheidende Schritt. Selbst wenn der benutzerdefinierte Beitragstyp vor der Suche verborgen ist, ist der Beitrag selbst mit post_status = 'publish' über den direkten Link zugänglich. Und es gibt genug Wege, diesen Link zu finden: von RSS-Feeds bis zur wp-json REST API.

Der transition_post_status-Hook wird bei jeder Statusänderung eines Beitrags ausgelöst. Wir fangen den Moment ab, in dem der Status auf publish wechselt, und setzen ihn zwangsweise auf private:

1
/**
2
 * Automatically makes a post private upon publication.
3
 * Checks that it is our custom post type — user_claim.
4
 * Source: https://stackoverflow.com/questions/54508808/
5
 */
6
function sdstudio_force_private_status( $new_status, $old_status, $post ) {
7
    if ( 'user_claim' === $post->post_type
8
         && 'publish' === $new_status
9
         && $old_status !== $new_status ) {
10
        $post->post_status = 'private';
11
        wp_update_post( $post );
12
    }
13
}
14
add_action( 'transition_post_status', 'sdstudio_force_private_status', 10, 3 );

Was hier Zeile für Zeile passiert:

• transition_post_status, ein WordPress-Hook, der bei jedem Übergang eines Beitrags von einem Status in einen anderen aufgerufen wird.
• Die erste Bedingung prüft post_type, um zu vermeiden, dass normale Beiträge und Seiten betroffen sind.
• Die zweite Bedingung fängt den Moment der Veröffentlichung (publish) ab, nicht die Zurücknahme der Veröffentlichung.
• Die dritte Bedingung ($old_status !== $new_status) verhindert wiederholtes Auslösen, wenn wp_update_post selbst denselben Hook aufruft.

Ersetzen Sie 'user_claim' unbedingt durch Ihre benutzerdefinierte Beitragstyp-ID. Wenn Sie die ID nicht sicher kennen, prüfen Sie sie in der Adressleiste, wenn Sie den Beitragstyp unter Meta Box → Beitragstypen bearbeiten.

Das Video oben ist eine detaillierte Anleitung zum Erstellen benutzerdefinierter Beitragstypen in WordPress: von der Theorie bis zum funktionierenden Code auf dem Bildschirm. Wenn Sie ein visuelles Format bevorzugen, zeigt der Autor jeden Schritt mit Erläuterung der register_post_type()-Argumente.

⁉️🤔 Häufig gestellte Fragen

Warum überhaupt privater Status, wenn der Beitrag von der Suche ausgeschlossen ist?

Der Ausschluss von der Suche (exclude_from_search) entfernt den Beitrag nur aus den WP_Query-Ergebnissen im Frontend. Direkte URLs, REST API und RSS-Feeds liefern den Inhalt weiterhin aus. Der Status private schließt den Zugriff auf WordPress-Core-Ebene, der Beitrag ist nur für Nutzer mit der Berechtigung read_private_posts sichtbar (Administratoren und Redakteure).

Kann der Nutzer den Beitragsstatus nach der Veröffentlichung ändern?

Über die Standard-WP-Recall-Oberfläche nicht. Das Frontend-Formular bietet keinen Zugriff auf die Statusauswahl. Sollte der Nutzer jedoch auf irgendeine Weise Zugang zum Admin-Panel erhalten (Rolle Autor und höher), kann er seine Beiträge bearbeiten. Geben Sie Nutzern auf Websites, die Anträge annehmen, daher keine höhere Rolle als Abonnent.

Was tun, wenn WP-Recall meinen benutzerdefinierten Beitragstyp nicht sieht?

Prüfen Sie zwei Parameter in den Beitragstyp-Einstellungen: public sollte true sein und show_ui ebenfalls true. Gehen Sie dann zu WP-Recall-Einstellungen → „Veröffentlichung" und stellen Sie sicher, dass Ihr Beitragstyp in der Liste der erlaubten Typen angehakt ist. Leeren Sie nach dem Ändern der Einstellungen den Permalink-Cache: Einstellungen → Permalinks → Änderungen speichern.

Ist es zwingend, speziell MB Custom Post Type zu verwenden?

Nein. Jede Methode zur Registrierung eines benutzerdefinierten Beitragstyps funktioniert: Code in functions.php (wie in Schritt 2), das Plugin Custom Post Type UI oder ACF. MB Custom Post Type wurde wegen der Kombination aus visueller Oberfläche und Kostenfreiheit gewählt. Wenn Sie bereits ACF Pro nutzen, erstellen Sie die Beitragstypen darin, die Logik ändert sich nicht.

Der Code funktioniert, aber alte Beiträge sind öffentlich geblieben, wie verberge ich sie?

Die Funktion aus Schritt 4 wird nur beim Veröffentlichungsereignis ausgelöst. Vorhandene Beiträge müssen separat bearbeitet werden. Der sicherste Weg ist, ins Admin-Panel zu gehen, alle Beiträge des benötigten Typs auszuwählen und über „Schnellbearbeitung" den Status auf Privat zu ändern. Für Hunderte von Beiträgen nutzen Sie WP-CLI: wp post list --post_type=user_claim --format=ids | xargs -I {} wp post update {} --post_status=private. Erstellen Sie vor der Massenaktualisierung ein Datenbank-Backup.

Dieser Ansatz funktioniert auf Dutzenden von Websites: Nutzer reichen Anträge über ihr persönliches Konto ein, und Administratoren sehen sie im Admin-Panel. Für das typische „WP-Recall + private Beiträge"-Setup wird nichts weiter benötigt.

Wenn Sie vorhaben, Zahlungsdaten oder Passscans über den benutzerdefinierten Beitragstyp entgegenzunehmen, konfigurieren Sie zusätzlich SSL und Feldverschlüsselung. Aber das ist ein Thema für einen separaten Artikel.

Was wir erreicht haben: Checkliste für den Start

• WP-Recall und MB Custom Post Type sind installiert und aktiviert.
• Der benutzerdefinierte Beitragstyp ist erstellt, über die Plugin-Oberfläche oder mit Code.
• In den WP-Recall-Einstellungen → „Veröffentlichung" ist der benötigte Beitragstyp angehakt.
• Die Weiterleitungsfunktion aus Schritt 3 ist in functions.php eingefügt.
• Die Funktion für den privaten Status aus Schritt 4 ist eingefügt, post_type ist durch Ihren ersetzt.
• Permalinks sind geleert: Einstellungen → Permalinks → Änderungen speichern.
• Ein Testnutzer hat einen Antrag aus seinem persönlichen Konto abgesendet, die Weiterleitung funktioniert, der Beitrag ist privat.

Ein einziger Testantrag spart eine Stunde Fehlersuche nach dem Motto „warum funktioniert es nicht" im Produktivbetrieb. Überspringen Sie diesen Schritt nicht.

Beginnen Sie mit der Installation von MB Custom Post Type, der visuelle Builder erspart Ihnen Mühe mit den register_post_type()-Argumenten. Und falls Sie bereits einen anderen Beitragstyp-Builder (ACF, CPT UI) verwenden, übernehmen Sie einfach die Funktionen aus Schritt 3 und 4: Weiterleitung und privater Status funktionieren unabhängig von der CPT-Registrierungsmethode.

Und welche Methode nutzen Sie, um Anträge von Nutzern auf Ihren WordPress-Websites entgegenzunehmen? Teilen Sie es in den Kommentaren mit, es ist interessant, Ansätze zu vergleichen.