Может ли плагин WordPress добавлять страницы только для чтения?

Вопрос или проблема

.

Ответ или решение

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

Теория

Во-первых, важно понимать, что WordPress управляет страницами и постами через свою систему постов, записывая их в специальную таблицу в базе данных (обычно это wp_posts). Страницы и посты, созданные обычным способом через административную панель, будут иметь свои записи в этой таблице, и по умолчанию административные пользователи смогут редактировать или удалять их, если у них есть соответствующие права доступа.

Чтобы сделать страницы непросматриваемыми и недоступными для редактирования через стандартную административную панель, можно рассмотреть два подхода: использование "пользовательских пост-типов" или генерацию страниц динамически.

Пример реализации

Использование пользовательских пост-типов. Это стандартный подход для создания новых сущностей, которые ведут себя как страницы или записи, но могут быть изолированы в административной панели:

1. Регистрация пользовательского пост-типа. Вы можете использовать функцию register_post_type для создания кастомного типа сообщения. В параметрах этой функции можно задать метапараметры, указывая, чтобы они не отображались в административной панели ('show_in_menu' => false).
2. Редактирование прав. Можно использовать фильтрующие хуки WordPress, такие как map_meta_cap, чтобы перекрыть права на редактирование и удаление этих страниц. Например, вы можете установить права доступа таким образом, что ни у одной из пользовательских ролей не будет доступа к редактированию или удалению этих объектов.
3. Исключение из списка. Вы можете использовать соответствующие хуки и фильтры (например, manage_edit-{post_type}_columns), чтобы не показывать эти объекты в списках на административных страницах.

Динамическая генерация страниц. Если вам не нужны записи с постоянным хранением в базе данных, можно использовать хуки для интерцепции запросов:

1. Использование хуков. Хук init или template_redirect позволит вам интерцептировать запросы к определённым URL, которые будут генерироваться плагиом. Например, добавьте правило перезаписи (rewrite rule) и хук, переходящий на кастомный PHP-шаблон.
2. Исключение. Вы таким образом сможете исключить эти страницы из административной панели, так как они никогда не будут сохраняться в привычной таблице постов.

Применение

Рассматривая конкретные шаги, для реализации желания сделать страницы только для чтения и исключить их из админ-панели, вы можете:

1. Создать пользовательский пост-тип. Далее, в функции register_post_type убедитесь, что аргументы show_ui, show_in_menu, и publicly_queryable заданы таким образом, чтобы они минимально проявлялись в интерфейсе:

function create_read_only_pages() {
    register_post_type('custom_read_only_page', array(
        'label' => 'Read-only Pages',
        'public' => true,
        'show_ui' => false, // не показывать в админке
        'show_in_menu' => false,
        'publicly_queryable' => true,
        'capability_type' => 'page',
    ));
}
add_action('init', 'create_read_only_pages');

2. Используйте мета-возможности (meta capabilities) для ограничения прав доступа. Вы можете использовать map_meta_cap для запрета редактирования или удаления этих объектов.

3. Создавайте и поддерживайте контент динамически. Это может включать обратные вызовы и правила перезаписи (rewrite rules), чтобы ваши страницы были доступны исключительно через магию плагина.

Каждый из этих подходов имеет свои преимущества и нюансы. Исходя из ваших конкретных нужд и архитектуры вашего проекта, вы можете гибко сочетать эти методы и использовать дополнительные возможности для их защиты (например, дополнительные проверки прав доступа или использование куки/сессий для управления доступом).

Эти практики помогают не только в обеспечении безопасности, но и упрощают поддержку в долгосрочной перспективе.