Stellen Sie sich folgendes Szenario vor: Sie haben ein Unternehmensportal auf WordPress gestartet, einen Custom Post Type namens „Equipment" erstellt und mit internen Dokumentationen befüllt. Eine Woche später stellen Sie fest, dass all diese Seiten von Suchmaschinen indexiert und für jeden frei zugänglich sind. Der Zugriff sollte auf autorisierte Mitarbeiter beschränkt sein, doch Ihr Portal steht offen.

Die Bordmittel von WordPress erlauben es nicht, einen bestimmten Custom Post Type selektiv vor nicht registrierten Benutzern zu schützen. Rollen und Berechtigungen existieren, aber die Verknüpfung „Gäste können CPT X nicht sehen" ist nicht standardmäßig verfügbar. Die Lösung besteht aus drei Komponenten: CPT-Registrierung, Rollenkonfiguration und einem Plugin zur Leseberechtigung. Die vierte (optionale) Komponente ist Social Login, damit Mitarbeiter nicht jedes Mal ein Passwort eingeben müssen.

Nachfolgend finden Sie eine schrittweise Aufschlüsselung jeder Komponente mit konkreten Plugins und Einstellungen. Alle Werkzeuge sind kostenlos, im offiziellen WordPress.org-Verzeichnis verfügbar und erfordern keine Programmierung, wobei am Ende auch ein rein codebasierter Ansatz für diejenigen behandelt wird, die Plugins vermeiden möchten.

💡 Kurzüberblick:

• Registrieren Sie einen Custom Post Type über Custom Post Type UI, ohne eine einzige Codezeile zu schreiben
• Erstellen Sie eine benutzerdefinierte Rolle in PublishPress Capabilities und weisen Sie diese den Mitarbeitern zu
• Beschränken Sie den CPT-Zugriff für Gäste mit dem Plugin WP Access Areas: Nicht autorisierte Besucher werden auf die Anmeldeseite weitergeleitet
• Aktivieren Sie optional Social Login über Super Socializer für eine passwortfreie Anmeldung mit dem Google-Konto

Schritt 1: Registrierung eines Custom Post Type

Die erste und einfachste Phase ist das Anlegen des CPT selbst. Sie müssen dafür nicht die functions.php anfassen: Das Plugin Custom Post Type UI auf WordPress.org bietet eine grafische Oberfläche zur Registrierung beliebiger Post Types und Taxonomien.

Die Installation erfolgt standardmäßig: „Plugins → Installieren", nach Namen suchen, aktivieren. Nach der Aktivierung erscheint ein neuer Menüpunkt in der Seitenleiste: „CPT UI → Add/Edit Post Types". Füllen Sie die Felder aus: Slug (zum Beispiel equipment), Plural- und Singularbezeichnung, Labels und klicken Sie auf „Add Post Type".

Das Plugin ruft register_post_type() automatisch mit den korrekten Parametern auf. Kein manueller Code erforderlich: Sie erhalten einen voll funktionsfähigen Post Type mit Editor-Unterstützung, Archiven und REST API. Falls Sie die Registrierung später in die functions.php verlagern müssen, zeigt CPT UI den generierten PHP-Code im Reiter „Tools" an.

Achten Sie bei der Registrierung auf zwei sicherheitsrelevante Optionen. Im Block „Settings" von CPT UI gibt es die Einstellung „Publicly Queryable", die festlegt, ob Beiträge über direkte Links aufrufbar sind. Der Standardwert ist true, und selbst wenn Sie das Lesen später per Plugin einschränken, sollten Sie diese Option aktiviert lassen; andernfalls liefert WordPress einen 404-Fehler statt einer Weiterleitung auf die Anmeldeseite, und die Benutzer verstehen nicht, was passiert ist. Der zweite Parameter, „Has Archive", aktiviert eine Archivseite, die alle CPT-Beiträge auflistet. Wenn Sie kein Archiv benötigen, deaktivieren Sie diese Option, damit Suchmaschinen keine Service-Seite mit Vorschauen geschützter Dokumente indexieren.

Schritt 2: Erstellung einer benutzerdefinierten Rolle

Es reicht nicht, den Zugriff auf den CPT für Gäste einfach zu sperren: Sie benötigen eine Rolle, die Zugriff erhält. Standardmäßig stellt WordPress einen festen Satz bereit: Administrator, Editor, Autor, Mitarbeiter, Abonnent. Wir legen eine neue Rolle mit dem Plugin PublishPress Capabilities an (früher Capability Manager Enhanced, gleicher Slug, gleiche Funktionalität, nur umbenannt).

Nach der Aktivierung navigieren Sie zu „Capabilities → Roles". Auf der rechten Bildschirmseite finden Sie den Block „Create New Role":

Vergeben Sie einen Namen (zum Beispiel „Equipment Reader"), wählen Sie eine Basisrolle zum Klonen (am besten Subscriber, mit minimalen Berechtigungen) und klicken Sie auf „Create". Die neue Rolle existiert nun und Sie können sie mit Berechtigungen bestücken. Für das Lesen eines CPT genügt die Standardkombination aus read + read_equipment (die von CPT UI registrierte Berechtigung).

Weisen Sie die erstellte Rolle den Mitarbeitern zu, die Zugriff auf die geschützten Inhalte benötigen. Danach können Sie das Plugin deaktivieren: Rollen und Berechtigungen bleiben in der WordPress-Datenbank erhalten und sind nicht davon abhängig, dass PublishPress Capabilities aktiv ist.

Schritt 3: Lesezugriff auf den CPT einschränken

Dies ist der entscheidende Schritt. Das Plugin WP Access Areas erlaubt es Ihnen, präzise festzulegen, wer Beiträge jedes Typs lesen, bearbeiten und kommentieren darf, bis hinunter auf die Ebene einzelner Seiten. Es hat bescheidene 400 aktive Installationen und erhielt seit längerem keine größeren Updates, aber für die Aufgabe „CPT vor Gästen schützen" arbeitet es zuverlässig und konfliktfrei.

Gehen Sie nach der Installation zu „Einstellungen → Access Areas". Wählen Sie im Abschnitt „Default Behaviour":

„If not logged in, redirect to login. Otherwise redirect to the fallback page."

Diese Einstellung leitet nicht autorisierte Benutzer auf wp-login.php um, wenn sie versuchen, eine geschützte CPT-Seite zu öffnen.

Darunter befindet sich eine Tabelle aller registrierten Beitragstypen. Wählen Sie für Ihren CPT in der Spalte „Reading" aus dem Dropdown-Menü „Logged in Users" aus. Das war es bereits: Ab diesem Zeitpunkt wird jeder Gast, der einem direkten Link zu einer CPT-Seite folgt, auf das Anmeldeformular umgeleitet.

Wichtiger Hinweis: Die über die Tabelle vorgenommenen Einstellungen gelten nur für neue Beiträge. Für bereits erstellte Seiten müssen Sie die Berechtigungen manuell in der Editor-Seitenleiste setzen, wo ein Block „Access Areas" erscheint. Überprüfen Sie das Ergebnis nach der Konfiguration unbedingt im Inkognito-Modus Ihres Browsers: Der Aufruf eines direkten Links zu einer geschützten CPT-Seite sollte Ihnen wp-login.php anzeigen, nicht den Inhalt.

Alternativen zu WP Access Areas, falls Sie eine aktiver gepflegte Lösung benötigen: PublishPress Permissions (die kostenlose Version deckt CPT und Rollen ab) oder ContentGate (ein schlankes Plugin mit Regelwerk auf Basis von Anmeldestatus und Rollen).

Schritt 4: Social Login (optional)

Die ständige Eingabe von Benutzername und Passwort auf einem Unternehmensportal erzeugt unnötige Reibung. Die logische Lösung: One-Click-Login per Google-Konto. Das Plugin Super Socializer übernimmt diese Aufgabe mit über 20.000 aktiven Installationen und Unterstützung für Google, Facebook, X (Twitter) sowie ein Dutzend weiterer Anbieter.

Gehen Sie nach der Aktivierung zu „Super Socializer → Social Login":

Grundeinstellungen: Aktivieren Sie die Checkbox „Disable user registration via social networks". Dies ist wichtig, damit sich nur bestehende Konten über soziale Netzwerke anmelden können, statt neue anzulegen. Wählen Sie anschließend den Anbieter (Google) und tragen Sie die Client-ID und das Client-Secret ein. Wo Sie diese erhalten:

• Öffnen Sie die Google Cloud Console, erstellen Sie ein Projekt (oder wählen Sie ein bestehendes aus)
• Klicken Sie im Bereich „APIs & Services → Credentials" auf „Create Credentials → OAuth client ID"
• Anwendungstyp ist Webanwendung; fügen Sie unter Authorized redirect URIs die Callback-URL aus den Super-Socializer-Einstellungen ein
• Speichern Sie, um Ihre Client-ID und Ihr Client-Secret zu erhalten

Kopieren Sie die Schlüssel in die Plugin-Felder:

Kritischer Punkt: Das Feld Authorized redirect URIs darf keinen abschließenden Schrägstrich enthalten, sonst erhalten Sie einen redirect_uri_mismatch-Fehler. Nach dem Speichern erscheint auf der Anmeldeseite eine Schaltfläche „Sign in with Google".

Wichtig: Die ursprüngliche Version dieses Beitrags (2020) beschrieb die Integration mit Google+, das im April 2019 eingestellt wurde. Der moderne Super Socializer nutzt das standardmäßige Google OAuth 2.0-Protokoll über Google Identity Services. Die Oberfläche der Google Cloud Console wurde seitdem aktualisiert, die Logik der Schritte (Projekt → Credentials → OAuth client ID → redirect URI) bleibt jedoch gleich.

Alternativer Ansatz: alles im Code

Wenn zusätzliche Plugins unerwünscht sind, lässt sich die Aufgabe in der functions.php des Themes oder eines Child-Themes lösen. Der Code registriert den CPT, erstellt eine Rolle und hängt eine Berechtigungsprüfung an das Template:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

Was dieser Code bewirkt: Der erste Block registriert den CPT equipment mit einem eigenen Fähigkeitstyp (capability_type). Der zweite Block erstellt bei der Theme-Aktivierung die Rolle Equipment Reader mit Leseberechtigungen für diesen CPT. Der dritte Block prüft die Berechtigung im template_redirect-Hook und leitet Gäste zu wp-login.php weiter.

Der Vorteil des Code-Ansatzes: null zusätzliche Plugins, volle Kontrolle. Der Nachteil: Social Login erfordert weiterhin ein Plugin (eine manuelle OAuth-Integration zu schreiben ist zeitaufwendig und unsicher), und jede Änderung an Rollen bedeutet Code-Änderungen.

⁉️🤔 Häufig gestellte Fragen

Kann ich einen CPT ohne Plugins nur über functions.php einschränken?

Ja. Die Kombination aus register_post_type() + add_role() + dem template_redirect-Hook mit einer is_user_logged_in()-Prüfung ist eine voll funktionsfähige Lösung. Der Code findet sich im Abschnitt oben. Social Login ohne Plugin ist deutlich schwieriger umzusetzen: Eine manuelle OAuth-Integration erfordert den Umgang mit Tokens, State und Sicherheit.

Warum WP Access Areas statt eines neueren Plugins wie ContentGate?

WP Access Areas ist ein minimalistisches Werkzeug für eine spezifische Aufgabe: „Einen Beitragstyp für Gäste sperren". Es bringt keinen Regel-Builder, keine visuellen Editoren und keine Abonnements mit. Wenn Sie komplexere Logik benötigen (zum Beispiel unterschiedliche Zugriffsebenen für verschiedene Rollen auf demselben CPT), nutzen Sie ContentGate oder PublishPress Permissions, die aktiv aktualisiert werden. Für das Basisszenario in diesem Leitfaden ist WP Access Areas ausreichend.

Was tun, wenn Gäste nach der Konfiguration weiterhin CPT-Seiten sehen?

Drei typische Ursachen. Erstens: Die Einstellung „Logged in Users" in der WP Access Areas-Tabelle gilt nur für neue Beiträge; bei bestehenden Seiten müssen Sie die Berechtigungen manuell über die Editor-Seitenleiste setzen. Zweitens: Ein Caching-Plugin liefert eine zwischengespeicherte Version der Seite an Gäste aus; leeren Sie den Cache und konfigurieren Sie Ausnahmen für den geschützten CPT. Drittens: Der CPT ist mit 'publicly_queryable' => true registriert und der Slug kollidiert mit einer öffentlichen Seite; prüfen Sie auf Überschneidungen.

Kann ich Super Socializer nur für das Login nutzen, ohne Sharing und Kommentare?

Ja, die Module des Plugins sind unabhängig. Entfernen Sie auf dem Tab „Social Sharing" alle Häkchen, dann verschwinden die „Teilen"-Buttons. Deaktivieren Sie auf dem Tab „Social Commenting" die Integration. Lassen Sie nur „Social Login" mit den von Ihnen benötigten Anbietern aktiv. Das Plugin ist schlank, und das Deaktivieren nicht benötigter Module beeinträchtigt die Performance nicht.

Ist es sicher, PublishPress Capabilities nach dem Erstellen einer Rolle zu deaktivieren?

Ja. WordPress-Rollen und -Fähigkeiten werden in der wp_options-Tabelle gespeichert (Option wp_user_roles) und sind nicht vom Plugin abhängig, das sie erstellt hat. Nach der Deaktivierung von PublishPress Capabilities bleiben alle erstellten Rollen und vergebenen Berechtigungen erhalten. Sie können das Plugin später wieder aktivieren, wenn Sie Berechtigungen ändern müssen.

Code schreiben oder bei Plugins bleiben

Die Wahl zwischen Plugins und functions.php läuft auf zwei Faktoren hinaus: die Anzahl der geschützten CPTs und wie oft sich Berechtigungen ändern.

Wenn Sie nur einen CPT haben (wie das Equipment-Beispiel), die Rollen stabil sind und Sie bereit sind, einmalig 30 Zeilen Code zu schreiben, ist der functions.php-Ansatz sauberer: Er erzeugt keine Plugins, hängt nicht von Drittanbieter-Updates ab und ist vollkommen transparent. Sie können Super Socializer für den Social Login beibehalten, da es eine eng umrissene Aufgabe löst und nicht mit eigenem Code kollidiert.

Wenn Sie mehrere CPTs haben, Berechtigungen häufig überarbeitet werden oder die Seite von einem Nicht-Entwickler betreut wird, setzen Sie auf die Plugin-Kombination. CPT UI + PublishPress Capabilities + WP Access Areas (oder ContentGate) lassen sich in 15 Minuten aus dem Admin-Panel heraus konfigurieren, ohne Code anzufassen. Zudem sichert PublishPress Capabilities Rollen bei jeder Änderung automatisch und ermöglicht ein Rollback mit zwei Klicks.

Folgen Sie in jedem Szenario dem Prinzip: ein Werkzeug für eine Aufgabe. Installieren Sie keine mächtige All-in-One-Lösung für eine einzelne Checkbox und erfinden Sie das Rad nicht neu, wenn ein existierendes Plugin exakt dasselbe schneller und sicherer erledigt.

Eine gesonderte Betrachtung verdient die Versionskontrolle. Code aus der functions.php lebt im Theme-Repository, Änderungen werden über Git nachverfolgt, und bei einem Seitenumzug werden Rollen über den after_switch_theme-Hook automatisch neu erstellt. Der Plugin-Ansatz bietet diese Transparenz nicht: Rollen liegen in der Datenbank, und beim Deployment einer Staging-Kopie oder beim Umzug auf eine neue Domain müssen sie manuell oder per Migrationsskript neu erstellt werden. Dieser Faktor gibt bei Teams, die CI/CD und Git-basiertes Deployment praktizieren, oft den Ausschlag zugunsten von Code.