Wyobraźmy sobie, że tworzymy nieco bardziej rozbudowany serwis, w którym użytkownicy mogą się rejestrować. Niekoniecznie jednak chcemy, aby byli oni świadomi, że serwis bazuje na WordPressie, albo chcemy wzbogacić i uprzyjemnić ich doświadczenie i stworzyć specjalny panel administracyjny. Tak czy inaczej nie chcemy, aby „szwędali” się nam po panelu administracyjnym WordPressa.

Żeby nie rozmieniać się na drobne, załóżmy, że zalogowanych użytkowników, którzy mają określoną rolę (w naszym przypadku subscriber, chcemy przekierowywać na określoną stronę (naszserwis.pl/uzytkownik/). I taką właśnie funkcjonalność realizuje poniższy kod:

function prefiks_restrict_wpadmin_access() {
    if ( ! defined('DOING_AJAX') || ! DOING_AJAX ) {
        $user = wp_get_current_user();

        if ( in_array('subscriber', $user->roles) ) {
            wp_redirect( site_url( '/uzytkownik/' ) );  // <- dostosuj swoich potrzeb
            die;
        }
    }
}
add_action( 'admin_init', 'prefiks_restrict_wpadmin_access' );

Dodatkowe warianty i pytania

Tylko tyle? To wystarczy?

Tak i nie. Powyższy kod zadba jedynie o to, aby użytkownik o określonej roli nie dostał się do panelu administracyjnego WP. Natomiast warto byłoby jeszcze ukryć takim użytkownikom pasek narzędzi administracyjnych. Dobrze jest też uświadomić sobie, że skoro nie wpuszczamy tych użytkowników wp-admina, to należy dać im możliwość edycji ich profilu, zmiany hasła, itd.

Dlaczego nie podpinamy się pod filtr login_redirect?

Czasem można trafić na różnych forach na rozwiązanie oparte na tym filtrze. Tyle, że oczywiście jest ono błędne. Jedyne, co nam zapewni, to że po zalogowaniu, użytkownik zostanie gdzieś przekierowany. Tyle, że jeśli taki użytkownik wpisze /wp-admin w pasku adresu swojej przeglądarki, to wejdzie do panelu administracyjnego.

Dlaczego w powyższym kodzie znajduje się sprawdzenie DOING_AJAX?

Sprawdzenie to wynika z mechanizmu, jaki WordPress oferuje do obsługi zapytań AJAXowych. Requesty takie (o ile są przez wtyczki/motywy obsługiwane poprawnie) kierowane są do pliku wp-admin/admin-ajax.php. Jeśli usuniemy to sprawdzenie, to zapytania AJAXowe przestaną działać poprawnie (one także będą przekierowywane).