Сценарий типичный: в медиабиблиотеке лежат файлы для редакции, менеджеров, клиентов или подписчиков, а по умолчанию WordPress показывает их всем, у кого есть доступ к админке. Если просто скрыть элементы интерфейса, это не решает задачу: файл всё равно можно открыть по прямой ссылке, а иногда и скачать из письма, кеша или старой записи.
Ниже разберём рабочую схему: как ограничить видимость файлов в админке, как не сломать загрузку и как проверить, что доступ действительно закрыт. Для части проектов достаточно кода, для части удобнее подключить плагин с контролем доступа к медиа. Но сначала стоит понять, где именно возникает проблема.
Что именно нужно ограничить: интерфейс, список файлов или прямой доступ
В WordPress у медиафайлов есть три уровня, и их часто путают:
- отображение в медиабиблиотеке — кто видит файл в списке в админке;
- доступ к вложению — кто может открыть страницу attachment;
- прямой URL к файлу — кто может скачать файл по ссылке из
/wp-content/uploads/.
Если закрыть только первый уровень, пользователь с прямой ссылкой всё равно получит файл. Если закрыть только attachment-страницу, это тоже не спасает, когда файл лежит в открытой папке uploads. Поэтому решение нужно выбирать по сценарию.
Когда достаточно скрыть файлы в админке
Это подходит, если задача организационная: редакторы не должны видеть чужие файлы в медиабиблиотеке, но сами файлы не являются секретными. Например, у каждого менеджера свои изображения для карточек товаров, и лишние файлы только мешают.
Когда нужен реальный контроль доступа
Если речь о договорах, прайсах, закрытых PDF, материалах для клиентов или цифровых товарах, одного фильтра в админке мало. Тогда нужно либо хранить файлы вне публичной директории, либо отдавать их через защищённый обработчик, либо использовать плагин, который умеет ограничивать доступ к медиа по ролям и правилам.
Диагностика проблемы перед внедрением
Прежде чем что-то менять, проверьте, как сейчас устроена загрузка файлов. Это экономит время: иногда проблема не в WordPress, а в том, что файл уже проиндексирован, закеширован или разослан в старых письмах.
- Откройте файл по прямой ссылке в режиме инкогнито.
- Проверьте, доступна ли attachment-страница вида
/?attachment_id=123или её ЧПУ-вариант. - Посмотрите, кто видит файл в медиабиблиотеке: администратор, редактор, автор, клиентская роль.
- Проверьте, не отдаёт ли CDN или кеш-слой старую публичную копию.
- Убедитесь, что файл не вставлен в записи, письма, PDF или внешние документы.
Если файл уже был публичным, его нельзя считать закрытым только после настройки прав. Старые ссылки могут продолжать работать, пока не обновится кеш или пока файл физически не будет перенесён.
Пошаговое решение через код: скрываем файлы в медиабиблиотеке по автору
Самый практичный вариант для редакционных сайтов — показывать в медиабиблиотеке только файлы текущего пользователя, если у него нет права видеть чужие вложения. Это не полноценная система DRM, но для внутренних процессов работает стабильно.
Ниже пример, который ограничивает список медиафайлов в админке для всех, кроме пользователей с правом manage_options. Его можно доработать под конкретные роли.
<?php
add_action( 'pre_get_posts', function( $query ) {
if ( ! is_admin() || ! $query->is_main_query() ) {
return;
}
global $pagenow;
if ( 'upload.php' !== $pagenow ) {
return;
}
if ( current_user_can( 'manage_options' ) ) {
return;
}
$user_id = get_current_user_id();
if ( ! $user_id ) {
return;
}
$query->set( 'author', $user_id );
} );Что делает этот код: на странице upload.php он оставляет пользователю только его собственные файлы. Для редакторов и администраторов фильтр не применяется.
Если нужно ограничить не по автору, а по роли, логика меняется: можно разрешить доступ только определённой группе пользователей, а для остальных оставить пустой список или показать только свои вложения.
Ограничение по роли вместо автора
Иногда автор файла не совпадает с тем, кто должен его видеть. Например, файлы загружает один технический аккаунт, а просматривать их должны только менеджеры. В этом случае удобнее проверять роль пользователя и подставлять нужный фильтр.
<?php
add_action( 'pre_get_posts', function( $query ) {
if ( ! is_admin() || ! $query->is_main_query() ) {
return;
}
global $pagenow;
if ( 'upload.php' !== $pagenow ) {
return;
}
$user = wp_get_current_user();
if ( in_array( 'shop_manager', (array) $user->roles, true ) ) {
return;
}
if ( current_user_can( 'manage_options' ) ) {
return;
}
$query->set( 'author', get_current_user_id() );
} );Здесь менеджеры магазина видят все файлы, а остальные — только свои. Это удобный компромисс для WooCommerce-проектов, где часть медиа нужна всей команде, а часть — только конкретным сотрудникам.
Если нужен реальный запрет на скачивание: сравнение подходов
Когда файл должен быть закрыт от прямого доступа, одного фильтра в админке недостаточно. На практике есть три варианта.
| Подход | Что даёт | Минус |
|---|---|---|
| Только код в админке | Скрывает чужие файлы в медиабиблиотеке | Не закрывает прямой URL |
| Плагин контроля доступа к медиа | Управляет видимостью и доступом по правилам | Нужно проверять совместимость с кешем и CDN |
| Хранение вне public uploads | Максимально жёсткий контроль | Сложнее внедрение и обслуживание |
Если проект небольшой, обычно хватает кода и дисциплины: не хранить конфиденциальные документы в открытой папке. Если документов много и доступ зависит от ролей, лучше брать специализированный плагин или отдельную схему выдачи файлов.
Из плагинов стоит смотреть в сторону решений, которые умеют ограничивать доступ к файлам по ролям, группам пользователей или условиям публикации. Перед установкой проверьте, как плагин работает с wp_get_attachment_url(), кешем и CDN: иногда интерфейс скрывается корректно, а сам файл остаётся доступным по прямой ссылке.
Как не сломать загрузку файлов и ссылки в контенте
Самая частая ошибка — закрыть файл, который уже используется в записях, товарах или письмах. После этого часть контента начинает вести на 403 или на пустую страницу. Чтобы избежать этого, сначала составьте список зависимостей.
- Проверьте, где используется attachment ID.
- Посмотрите, не вставлен ли файл в блоки Gutenberg, ACF-поля, WooCommerce-описания.
- Проверьте письма, которые могли уйти клиентам раньше.
- Если есть CDN, очистите его кеш после изменения правил доступа.
Для файлов, которые уже опубликованы, безопаснее сначала заменить их на новые ссылки, а потом ограничивать старые. Иначе вы получите жалобы от пользователей, а не защиту данных.
Проверка результата после внедрения
После настройки не ограничивайтесь просмотром списка в админке. Проверьте именно доступ.
- Зайдите под пользователем с ограниченной ролью и откройте медиабиблиотеку.
- Убедитесь, что чужие файлы не отображаются.
- Скопируйте прямую ссылку на закрытый файл и откройте её в инкогнито.
- Проверьте ответ сервера: должен быть отказ в доступе, а не обычная загрузка файла.
- Если используется CDN, проверьте и его URL, а не только origin-сервер.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/wp-content/uploads/2026/01/private-file.pdfЕсли всё настроено правильно, вы увидите не успешную отдачу файла, а отказ или редирект на страницу авторизации — в зависимости от вашей схемы.
Частые ошибки и как их исправить
Скрыли файл в медиабиблиотеке, но он всё равно открывается
Это ожидаемо, если вы меняли только запрос в админке. Для закрытия прямого доступа нужен отдельный слой: защищённая выдача, перенос файла из public uploads или плагин с контролем доступа.
После ограничения пропали изображения в старых записях
Значит, вы закрыли файл, который уже используется на фронтенде. Исправление простое: либо оставьте публичный доступ для файлов, встроенных в контент, либо перенесите закрытые документы в отдельный каталог и не используйте их в публичных блоках.
Редактор видит слишком мало файлов
Проверьте, не слишком ли жёстко задано условие в pre_get_posts. Часто забывают исключить роли, которым нужен общий доступ, или не учитывают, что часть сотрудников работает под кастомной ролью.
Кеш показывает старую версию доступа
Очистите кеш страницы, объектный кеш и CDN. Если файл уже был публичным, старый ответ может продолжать отдаваться до сброса кеша.
Практические советы по безопасности и производительности
Если вы закрываете документы, не полагайтесь только на скрытие в интерфейсе. Для действительно чувствительных файлов лучше:
- не хранить их в публичной папке без необходимости;
- не использовать предсказуемые имена файлов;
- ограничивать доступ на уровне сервера или приложения;
- проверять, не попадает ли файл в sitemap, кеш или превью;
- регулярно пересматривать права ролей в админке.
Если задача больше про чистоту админки, чем про защиту данных, можно совместить ограничение медиабиблиотеки с инструментами вроде Clearfy Pro, но только если это реально упрощает обслуживание сайта. Важно не перегружать проект лишними плагинами, когда достаточно одного короткого сниппета.
Итоговая логика простая: сначала определите, что именно нужно закрыть, потом выберите уровень защиты, а после внедрения проверьте прямую ссылку, кеш и реальные роли пользователей. Тогда ограничение доступа к файлам в WordPress не превратится в очередную поломку медиабиблиотеки.
