Proszę sobie wyobrazić: uruchamiają Państwo portal korporacyjny na WordPress, zakładają niestandardowy typ wpisów „Sprzęt" i wypełniają go wewnętrzną dokumentacją. Po tygodniu okazuje się, że wszystkie te strony są spokojnie indeksowane przez wyszukiwarki i widoczne dla każdego. Dostęp powinni mieć tylko zalogowani pracownicy, a u Państwa jest otwarty.

Domyślne narzędzia WordPress nie pozwalają punktowo zamknąć pojedynczego niestandardowego typu wpisów przed niezarejestrowanymi użytkownikami. Role i uprawnienia, tak, ale powiązanie „gość nie widzi CPT X" nie jest dostępne od razu po instalacji. Rozwiązanie składa się z trzech komponentów: rejestracja CPT, konfiguracja ról i wtyczka ograniczająca odczyt. Czwarty, opcjonalny, to logowanie społecznościowe, aby pracownicy nie musieli za każdym razem wpisywać hasła.

Poniżej znajduje się szczegółowa analiza każdego komponentu krok po kroku, z konkretnymi wtyczkami i ustawieniami. Wszystkie narzędzia są bezpłatne, dostępne w oficjalnym katalogu WordPress.org i nie wymagają pisania kodu, choć na końcu omówiono również wariant stricte kodowy dla tych, którzy chcą obejść się bez wtyczek.

💡 Szybki przegląd:

• Rejestrujemy niestandardowy typ wpisów za pomocą Custom Post Type UI, bez ani jednej linii kodu
• Tworzymy niestandardową rolę w PublishPress Capabilities i przypisujemy ją pracownikom
• Zamykamy CPT przed gośćmi wtyczką WP Access Areas: nieautoryzowany odwiedzający otrzymuje przekierowanie na stronę logowania
• Opcjonalnie podłączamy autoryzację społecznościową przez Super Socializer, logowanie kontem Google bez hasła

Krok 1: Rejestracja niestandardowego typu wpisów

Pierwszy i najprostszy etap, czyli utworzenie samego CPT. Nie trzeba w tym celu zaglądać do functions.php: wtyczka Custom Post Type UI na WordPress.org udostępnia graficzny interfejs do rejestracji dowolnych typów wpisów i taksonomii.

Instalacja jest standardowa: „Wtyczki → Dodaj nową", wyszukiwanie po nazwie, aktywacja. Po aktywacji w bocznym menu pojawia się pozycja „CPT UI → Add/Edit Post Types". Wypełniają Państwo pola: slug (na przykład equipment), nazwa w liczbie mnogiej i pojedynczej, etykiety, i klikają „Add Post Type".

Wtyczka sama wywołuje register_post_type() z prawidłowymi parametrami. Żadnego ręcznego kodu: na wyjściu otrzymują Państwo gotowy typ wpisów z obsługą edytora, archiwów i REST API. Jeśli w przyszłości zajdzie potrzeba przeniesienia rejestracji do functions.php, CPT UI pokazuje wygenerowany kod PHP na zakładce „Tools".

Na etapie rejestracji warto zwrócić uwagę na dwie opcje krytyczne dla bezpieczeństwa. W bloku „Settings" CPT UI znajduje się pole wyboru „Publicly Queryable", które określa, czy wpis można otworzyć przez bezpośredni link. Domyślnie jest to true i nawet po ograniczeniu odczytu przez wtyczkę zaleca się pozostawienie tego parametru włączonego, w przeciwnym razie WordPress zwróci 404 zamiast przekierowania na stronę logowania i użytkownik nie zrozumie, co się stało. Drugi parametr, „Has Archive", włącza stronę archiwum z listą wszystkich wpisów CPT. Jeśli archiwum nie jest potrzebne, proszę je wyłączyć, aby wyszukiwarki nie zaindeksowały strony technicznej z podglądem zamkniętych dokumentów.

Krok 2: Tworzenie niestandardowej roli

Samo zamknięcie CPT przed gośćmi nie wystarczy, potrzebna jest rola, która będzie miała do niego dostęp. Domyślnie WordPress udostępnia stały zestaw: Administrator, Editor, Author, Contributor, Subscriber. Nową rolę utworzymy za pomocą wtyczki PublishPress Capabilities (wcześniej nosiła nazwę Capability Manager Enhanced, ten sam slug, ta sama funkcjonalność, rebranding).

Po aktywacji przechodzimy do „Capabilities → Roles". W prawej części ekranu znajduje się blok „Create New Role":

Wpisujemy nazwę (na przykład „Equipment Reader"), wybieramy rolę bazową do sklonowania (najlepiej Subscriber, minimum uprawnień) i klikamy „Create". Nowa rola została utworzona, teraz można ją wypełnić uprawnieniami, do odczytu CPT wystarczy standardowa para read + read_equipment (capability zarejestrowana przez CPT UI).

Przypiszcie Państwo utworzoną rolę pracownikom, którzy potrzebują dostępu do zamkniętych treści. Po wykonaniu tej czynności wtyczkę można dezaktywować, role i uprawnienia pozostają w bazie danych WordPress i nie zależą od aktywnego stanu PublishPress Capabilities.

Krok 3: Ograniczenie dostępu do odczytu CPT

Kluczowy krok. Wtyczka WP Access Areas pozwala precyzyjnie określić, kto czyta, edytuje i komentuje wpisy każdego typu, aż do pojedynczych stron. Ma skromne 400 aktywnych instalacji i od dawna nie doczekała się dużych aktualizacji, ale do zadania „zamknięcia CPT przed gośćmi" działa przewidywalnie i bez konfliktów.

Po instalacji przechodzimy do „Settings → Access Areas". W sekcji „Default Behaviour" wybieramy:

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

To ustawienie przekierowuje nieautoryzowanego użytkownika na wp-login.php przy próbie otwarcia dowolnej chronionej strony CPT.

Następnie widoczna jest tabela wszystkich zarejestrowanych typów wpisów. Przy Państwa CPT w kolumnie „Reading" z listy rozwijanej wybieramy „Logged in Users". To wszystko: od tego momentu każdy gość, który przejdzie pod bezpośredni link do strony CPT, otrzymuje przekierowanie na formularz logowania.

Ważny niuans: ustawienie przez tabelę działa tylko na nowe wpisy. Dla już utworzonych stron trzeba ręcznie nadać uprawnienia w panelu bocznym edytora, pojawia się tam blok „Access Areas". Po skonfigurowaniu należy koniecznie sprawdzić wynik w trybie incognito przeglądarki, otwierając bezpośredni link do chronionej strony CPT, powinni Państwo zobaczyć wp-login.php, a nie zawartość.

Alternatywy dla WP Access Areas, jeśli potrzebują Państwo rozwiązania z aktywniejszym wsparciem: PublishPress Permissions (bezpłatna wersja obejmuje CPT i role) lub ContentGate (lekka wtyczka z regułami opartymi na statusie logowania i rolach).

Krok 4: Autoryzacja społecznościowa (opcjonalnie)

Ciągłe wpisywanie loginu i hasła na portalu korporacyjnym to zbędne tarcie. Logicznym rozwiązaniem jest logowanie przez konto Google jednym kliknięciem. Wtyczka Super Socializer rozwiązuje to zadanie, 20 000+ aktywnych instalacji, obsługa Google, Facebook, X (Twitter) i kilkunastu innych dostawców.

Po aktywacji przechodzimy do „Super Socializer → Social Login":

Podstawowe ustawienia: włączamy checkbox „Wyłącz rejestrację użytkowników przez sieci społecznościowe", to ważne, aby przez social media logowały się wyłącznie istniejące konta, a nie były tworzone nowe. Następnie wybieramy dostawcę (Google), podajemy Client ID i Client Secret. Skąd je wziąć:

• Otwieramy Google Cloud Console, tworzymy projekt (lub wybieramy istniejący)
• W sekcji „APIs & Services → Credentials" klikamy „Create Credentials → OAuth client ID"
• Typ aplikacji: Web application, w Authorized redirect URIs wklejamy URL callbacku z ustawień Super Socializer
• Zapisujemy, otrzymujemy Client ID i Client Secret

Kopiujemy klucze do pól wtyczki:

Krytyczny moment: w polu Authorized redirect URIs nie może być ukośnika na końcu, w przeciwnym razie otrzymają Państwo błąd redirect_uri_mismatch. Po zapisaniu na stronie logowania pojawia się przycisk „Zaloguj się przez Google".

Ważne: w oryginalnej wersji wpisu (2020 rok) opisywana była integracja z Google+, usługa ta została zamknięta w kwietniu 2019 roku. Współczesny Super Socializer wykorzystuje standardowy protokół Google OAuth 2.0 przez Google Identity Services. Interfejs Google Cloud Console od tego czasu został zaktualizowany, ale logika kroków (projekt → Credentials → OAuth client ID → redirect URI) pozostała niezmieniona.

Alternatywne podejście: wszystko w kodzie

Jeśli dodatkowe wtyczki są niepożądane, zadanie można rozwiązać w pliku functions.php motywu lub motywu potomnego. Kod rejestruje CPT, tworzy rolę i podpina sprawdzanie autoryzacji na szablon:

1
// Регистрация кастомного типа записей
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Оборудование', 'singular_name' => 'Оборудование'],
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
// Создание роли при активации темы
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
// Редирект гостей с CPT на страницу входа
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');

Co robi ten kod: pierwszy blok rejestruje CPT equipment z własnym typem uprawnień (capability_type). Drugi, podczas aktywacji motywu, tworzy rolę Equipment Reader z prawami do odczytu tego CPT. Trzeci, na haku template_redirect, sprawdza autoryzację i odsyła gościa na wp-login.php.

Plus podejścia kodowego: zero dodatkowych wtyczek, pełna kontrola. Minus: logowanie społecznościowe i tak będzie wymagało wtyczki (ręczna integracja OAuth jest czasochłonna i niebezpieczna), a każda zmiana ról to edycja kodu.

⁉️🤔 Często zadawane pytania

Czy można zamknąć CPT bez wtyczek, tylko przez functions.php?

Tak. Połączenie register_post_type() + add_role() + hak template_redirect ze sprawdzeniem is_user_logged_in() to w pełni działające rozwiązanie. Kod podano w sekcji powyżej. Logowanie społecznościowe bez wtyczki jest znacznie trudniejsze do zrealizowania: ręczna integracja OAuth wymaga obsługi tokenów, stanu i bezpieczeństwa.

Dlaczego WP Access Areas, a nie nowsza wtyczka, taka jak ContentGate?

WP Access Areas to minimalistyczne narzędzie do konkretnego zadania: „zamknięcia typu wpisów przed gośćmi". Nie ciągnie za sobą kreatora reguł, edytorów wizualnych ani subskrypcji. Jeśli potrzebna jest bardziej złożona logika, na przykład różne poziomy dostępu dla różnych ról w jednym CPT, proszę sięgnąć po ContentGate lub PublishPress Permissions, są one aktywnie aktualizowane. Dla podstawowego scenariusza z tego poradnika WP Access Areas jest wystarczające.

Co zrobić, jeśli po skonfigurowaniu goście nadal widzą strony CPT?

Trzy typowe przyczyny. Pierwsza: ustawienie „Logged in Users" w tabeli WP Access Areas dotyczy tylko nowych wpisów, dla starych stron należy ręcznie ustawić uprawnienia w panelu bocznym edytora. Druga: wtyczka cache'ująca serwuje gościowi zcache'owaną wersję strony, proszę wyczyścić cache i skonfigurować wyjątki dla chronionego CPT. Trzecia: CPT jest zarejestrowany z 'publicly_queryable' => true, a slug pokrywa się z ogólnodostępną stroną, proszę sprawdzić kolizję.

Czy można używać Super Socializer tylko do logowania, bez udostępniania i komentarzy?

Tak, moduły wtyczki są niezależne. Na karcie „Social Sharing" proszę odznaczyć wszystkie pola, przyciski „Udostępnij" znikną. Na karcie „Social Commenting" proszę wyłączyć integrację. Proszę pozostawić tylko „Social Login" z wybranymi dostawcami. Wtyczka jest lekka, wyłączenie zbędnych modułów nie wpływa na wydajność.

Czy bezpiecznie jest wyłączyć PublishPress Capabilities po utworzeniu roli?

Tak. Role i uprawnienia WordPress są przechowywane w tabeli wp_options (opcja wp_user_roles) i nie zależą od wtyczki, która je utworzyła. Po dezaktywacji PublishPress Capabilities wszystkie utworzone role i nadane uprawnienia zostają zachowane. Samą wtyczkę można aktywować ponownie, jeśli zajdzie potrzeba zmiany uprawnień.

Czy pisać kod, czy wystarczą wtyczki

Wybór między wtyczkami a functions.php sprowadza się do dwóch czynników: liczby chronionych CPT i częstotliwości zmian uprawnień.

Jeśli CPT jest jeden (jak w przykładzie ze sprzętem), role są stabilne i są Państwo gotowi raz napisać 30 linii kodu, wariant z functions.php jest czystszy: nie mnoży wtyczek, nie zależy od zewnętrznych aktualizacji, jest w pełni przejrzysty. Logowanie społecznościowe można pozostawić Super Socializerowi, rozwiązuje on wąskie zadanie i nie koliduje z niestandardowym kodem.

Jeśli CPT jest kilka, uprawnienia są często weryfikowane lub stroną zarządza osoba nietechniczna, proszę wybrać zestaw wtyczek. CPT UI + PublishPress Capabilities + WP Access Areas (lub ContentGate) konfiguruje się z panelu administracyjnego w 15 minut i nie wymaga dotykania kodu. Dodatkowo PublishPress Capabilities automatycznie tworzy kopię zapasową ról przy każdej zmianie, przywrócenie jest możliwe dwoma kliknięciami.

W każdym scenariuszu proszę trzymać się zasady: jedno narzędzie do jednego zadania. Nie należy instalować potężnego kombajnu dla jednego pola wyboru i nie należy pisać własnego rozwiązania, jeśli gotowa wtyczka robi dokładnie to samo, ale szybciej i bezpieczniej.

Osobno warto przemyśleć wersjonowanie. Kod z functions.php żyje w repozytorium motywu, zmiany są śledzone przez Git, a podczas przenoszenia strony role zostaną odtworzone automatycznie na haku after_switch_theme. Podejście wtyczkowe nie daje takiej przejrzystości: role są przechowywane w bazie danych, a podczas wdrażania kopii stagingowej lub przenoszenia na nową domenę należy je odtworzyć ręcznie lub napisać skrypt migracyjny. Ten czynnik często przesądza na korzyść kodu w przypadku zespołów praktykujących CI/CD i wdrażanie przez Git.