Представьте: вы запустили корпоративный портал на WordPress, завели кастомный тип записей «Оборудование» и наполнили его внутренней документацией. Через неделю выясняется, что все эти страницы спокойно индексируются поисковиками и видны любому прохожему. Доступ должен быть только у авторизованных сотрудников, а у вас, открыто.

Штатные средства WordPress не дают точечно закрыть отдельный кастомный тип записей от незарегистрированных пользователей. Роли и возможности, да, но привязка «гость не видит CPT X» из коробки отсутствует. Решение собирается из трёх компонентов: регистрация CPT, настройка ролей и плагин ограничения чтения. Четвёртый, опциональный, социальный вход, чтобы сотрудники не вводили пароль каждый раз.

Ниже, пошаговый разбор каждого компонента с конкретными плагинами и настройками. Все инструменты бесплатны, доступны в официальном каталоге WordPress.org и не требуют написания кода, хотя в конце разобран и чисто кодовый вариант для тех, кто хочет обойтись без плагинов.

💡 Быстрый обзор:

• Регистрируем кастомный тип записей через Custom Post Type UI, без единой строки кода
• Создаём пользовательскую роль в PublishPress Capabilities и назначаем её сотрудникам
• Закрываем CPT от гостей плагином WP Access Areas: неавторизованный посетитель получает редирект на страницу входа
• Опционально подключаем социальную авторизацию через Super Socializer, вход по Google-аккаунту без пароля

Шаг 1: Регистрация кастомного типа записей

Первый и самый простой этап, создание самого CPT. Для этого не нужно лезть в functions.php: плагин Custom Post Type UI на WordPress.org даёт графический интерфейс для регистрации любых типов записей и таксономий.

Установка стандартная: «Плагины → Добавить новый», поиск по названию, активировать. После активации в боковом меню появляется пункт «CPT UI → Add/Edit Post Types». Заполняете поля: slug (например, equipment), множественное и единственное название, метки, и жмёте «Add Post Type».

Плагин сам вызывает register_post_type() с правильными параметрами. Никакого ручного кода: на выходе, готовый тип записей с поддержкой редактора, архивов и REST API. Если в будущем понадобится перенести регистрацию в functions.php, CPT UI показывает сгенерированный PHP-код на вкладке «Tools».

На этапе регистрации стоит обратить внимание на две критичные для безопасности опции. В блоке «Settings» CPT UI есть флаг «Publicly Queryable», он определяет, можно ли открыть запись по прямой ссылке. По умолчанию true, и даже после ограничения чтения через плагин этот параметр желательно оставить включённым, иначе WordPress вернёт 404 вместо редиректа на страницу входа, и пользователь не поймёт, что произошло. Второй параметр, «Has Archive», включает страницу архива со списком всех записей CPT. Если архив не нужен, отключите его, чтобы поисковики не проиндексировали служебную страницу с превью закрытых документов.

Шаг 2: Создание пользовательской роли

Просто закрыть CPT от гостей недостаточно, нужна роль, которой доступ будет открыт. По умолчанию WordPress даёт фиксированный набор: Administrator, Editor, Author, Contributor, Subscriber. Создавать новую роль будем через плагин PublishPress Capabilities (ранее назывался Capability Manager Enhanced, тот же слаг, та же функциональность, ребрендинг).

После активации переходим в «Capabilities → Roles». В правой части экрана, блок «Create New Role»:

Вводим название (например, «Equipment Reader»), выбираем базовую роль для клонирования (лучше Subscriber, минимум прав) и жмём «Create». Новая роль появилась, теперь её можно наполнить возможностями, для чтения CPT достаточно стандартной связки read + read_equipment (capability, которую зарегистрировал CPT UI).

Назначьте созданную роль сотрудникам, которым нужен доступ к закрытому контенту. После этого плагин можно деактивировать, роли и возможности остаются в базе данных WordPress и не зависят от активного состояния PublishPress Capabilities.

Шаг 3: Ограничение доступа к чтению CPT

Ключевой шаг. Плагин WP Access Areas позволяет точечно задать, кто читает, редактирует и комментирует записи каждого типа, вплоть до отдельных страниц. У него скромные 400 активных установок и давно не было крупных обновлений, но для задачи «закрыть CPT от гостей» он работает предсказуемо и без конфликтов.

После установки переходим в «Settings → Access Areas». В разделе «Default Behaviour» выбираем:

«If not logged in, redirect to login. Otherwise redirect to the fallback page.»

Эта настройка отправляет неавторизованного пользователя на wp-login.php при попытке открыть любую защищённую страницу CPT.

Далее, таблица всех зарегистрированных типов записей. Напротив вашего CPT в столбце «Reading» из выпадающего списка выбираем «Logged in Users». Всё: с этого момента любой гость, перешедший по прямой ссылке на страницу CPT, получает редирект на форму авторизации.

Важный нюанс: настройка через таблицу действует только на новые записи. Для уже созданных страниц нужно вручную выставить права в боковой панели редактора, там появляется блок «Access Areas». После настройки обязательно проверьте результат в режиме инкогнито браузера, открыв прямую ссылку на защищённую страницу CPT, вы должны увидеть wp-login.php, а не содержимое.

Альтернативы WP Access Areas, если вам нужно более активно поддерживаемое решение: PublishPress Permissions (бесплатная версия охватывает CPT и роли) или ContentGate (лёгкий плагин с правилами на основе статуса входа и ролей).

Шаг 4: Социальная авторизация (опционально)

Постоянно вводить логин и пароль на корпоративном портале, лишнее трение. Логичное решение: вход через Google-аккаунт одним кликом. Плагин Super Socializer решает эту задачу, 20 000+ активных установок, поддержка Google, Facebook, X (Twitter) и ещё дюжины провайдеров.

После активации переходим в «Super Socializer → Social Login»:

Базовые настройки: включаем чекбокс «Отключить регистрацию пользователей через социальные сети», это важно, чтобы через соцсети входили только существующие учётные записи, а не создавались новые. Далее выбираем провайдера (Google), указываем Client ID и Client Secret. Где их взять:

• Открываем Google Cloud Console, создаём проект (или выбираем существующий)
• В разделе «APIs & Services → Credentials» жмём «Create Credentials → OAuth client ID»
• Тип приложения, Web application, в Authorized redirect URIs вставляем URL колбэка из настроек Super Socializer
• Сохраняем, получаем Client ID и Client Secret

Копируем ключи в поля плагина:

Критичный момент: в поле Authorized redirect URIs не должно быть слеша на конце, иначе получите ошибку redirect_uri_mismatch. После сохранения на странице входа появляется кнопка «Войти через Google».

Важно: в оригинальной версии поста (2020 год) описывалась интеграция с Google+, этот сервис закрыт с апреля 2019 года. Современный Super Socializer использует стандартный протокол Google OAuth 2.0 через Google Identity Services. Интерфейс Google Cloud Console с тех пор обновился, но логика шагов (проект → Credentials → OAuth client ID → redirect URI) осталась прежней.

Альтернативный подход: всё на коде

Если лишние плагины нежелательны, задачу можно решить в functions.php темы или дочерней темы. Код регистрирует CPT, создаёт роль и вешает проверку авторизации на шаблон:

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');

Что делает этот код: первый блок регистрирует CPT equipment с собственным типом возможностей (capability_type). Второй, при активации темы создаёт роль Equipment Reader с правами чтения этого CPT. Третий, на хуке template_redirect проверяет авторизацию и отправляет гостя на wp-login.php.

Плюс кодового подхода: ноль дополнительных плагинов, полный контроль. Минус: социальный вход всё равно потребует плагина (OAuth-интеграцию вручную писать долго и небезопасно), а каждое изменение ролей, правка кода.

⁉️🤔 Частые вопросы

Можно ли закрыть CPT без плагинов, только через functions.php?

Да. Связка register_post_type() + add_role() + хук template_redirect с проверкой is_user_logged_in(), полностью рабочее решение. Код приведён в разделе выше. Социальный вход без плагина реализовать значительно сложнее: ручная OAuth-интеграция требует обработки токенов, состояния и безопасности.

Почему WP Access Areas, а не более новый плагин вроде ContentGate?

WP Access Areas, минималистичный инструмент под конкретную задачу: «закрыть тип записей от гостей». Он не тянет за собой конструктор правил, визуальные редакторы и подписки. Если нужна более сложная логика, например, разные уровни доступа для разных ролей на одном CPT, берите ContentGate или PublishPress Permissions, они активно обновляются. Для базового сценария из этого руководства WP Access Areas достаточно.

Что делать, если после настройки гости всё ещё видят страницы CPT?

Три типичные причины. Первая: настройка «Logged in Users» в таблице WP Access Areas применяется только к новым записям, для старых страниц нужно выставить права вручную через боковую панель редактора. Вторая: кеш-плагин отдаёт закешированную версию страницы гостю, сбросьте кеш и настройте исключения для защищённого CPT. Третья: CPT зарегистрирован с 'publicly_queryable' => true и слаг совпадает с общедоступной страницей, проверьте коллизию.

Можно ли использовать Super Socializer только для входа, без шаринга и комментариев?

Да, модули плагина независимы. На вкладке «Social Sharing» снимите все галочки, кнопки «Поделиться» исчезнут. На вкладке «Social Commenting» отключите интеграцию. Оставьте только «Social Login» с нужными провайдерами. Плагин лёгкий, отключение лишних модулей не влияет на производительность.

Безопасно ли отключать PublishPress Capabilities после создания роли?

Да. Роли и возможности WordPress хранятся в таблице wp_options (опция wp_user_roles) и не зависят от плагина-создателя. После деактивации PublishPress Capabilities все созданные роли и выданные права сохраняются. Сам плагин можно активировать снова, если понадобится изменить права.

Стоит ли писать код или хватит плагинов

Выбор между плагинами и functions.php сводится к двум факторам: количество защищаемых CPT и частота изменений прав.

Если CPT один (как в примере с оборудованием), роли стабильны и вы готовы один раз написать 30 строк кода, вариант с functions.php чище: не плодит плагины, не зависит от сторонних обновлений, полностью прозрачен. Социальный вход можно оставить на Super Socializer, он решает узкую задачу и не конфликтует с кастомным кодом.

Если CPT несколько, права часто пересматриваются или сайтом управляет не-разработчик, берите связку плагинов. CPT UI + PublishPress Capabilities + WP Access Areas (или ContentGate) настраиваются из админки за 15 минут и не требуют касания кода. Плюс PublishPress Capabilities автоматически бэкапит роли при каждом изменении, откатиться можно в два клика.

В любом сценарии придерживайтесь принципа: один инструмент на одну задачу. Не ставьте мощный комбайн ради одной галки и не пишите велосипед, если готовый плагин делает ровно то же самое, но быстрее и безопаснее.

Отдельно стоит продумать версионирование. Код из functions.php живёт в репозитории темы, изменения отслеживаются через Git, и при переносе сайта роли пересоздадутся автоматически на хуке after_switch_theme. Плагинный подход такой прозрачности не даёт: роли хранятся в базе данных, и при развёртывании staging-копии или переносе на новый домен их нужно воссоздавать вручную либо писать скрипт миграции. Этот фактор часто становится решающим в пользу кода для команд, практикующих CI/CD и деплой через Git.