Содержание статьи
Используйте стороннюю библиотеку файлов, если у вас мультисайт или несколько независимых инсталляций и требуется централизованный доступ к изображениям, видео и документам. Подключение через REST API или XML-RPC – избыточно. Есть способ проще.
Активируйте расширение только на одном ресурсе. Остальные – клиенты. Подключение происходит через обычный URL. Никаких токенов, регистраций, авторизаций. Просто укажите адрес основного источника, и готово. Визуально – как будто файлы у вас локально. Технически – работают через удалённые HTTP-запросы.
Внимание! Не пытайтесь подключать источник, если у него отключена загрузка миниатюр или изменены пути к wp-content – система не сможет получить доступ к файлам.
Обратите внимание на проблему с фильтрацией по автору. По умолчанию фильтр не работает – ID пользователей не совпадают. Решение: используйте фильтр media_library_author_query и пишите соответствие вручную через map.
Пример:
add_filter(\'media_library_author_query\', function($query) {
$query[\'author\'] = map_remote_user_id($query[\'author\']);
return $query;
});
Миниатюры. Слабое место. Загружаются не всегда. Если источник настроен неправильно или использует нестандартный механизм обработки изображений, превью могут отсутствовать. Проверяйте наличие размеров thumbnail и medium на основном сайте.
Важно помнить: если на клиентском сайте включён режим HTTPS, а источник работает по HTTP – медиафайлы не будут отображаться из-за политики браузеров.
Убедитесь, что в настройках клиента прописан полный URL без слэша на конце. Пример: https://media.example.com. Ошибка в одном символе – и ничего не работает. Паника. Потерянные часы. Проверьте трижды.
Только изображения. Только из папки uploads. Ни скрипты, ни PDF, ни SVG – всё, что не является изображением, не будет подключено корректно. Если нужно больше – придётся расширять функциональность вручную.
Файлы не кэшируются. Каждый просмотр изображения – отдельный запрос к удалённому серверу. Хотите оптимизировать? Используйте внешние CDN-решения или настройте локальный кеш средствами WordPress, например, через transient API.
Не работает с кастомными полями из ACF напрямую. Только через wp_get_attachment_url. Если поле ACF возвращает ID – всё хорошо. Если URL – настраивайте фильтр acf/format_value.
Нестабильно с WPML. Переводы вложений не синхронизируются. Решение: отключить автоматическое дублирование медиа и прописывать связи вручную через hook wpml_register_single_string.
Преимущество – скорость внедрения. Недостаток – отсутствие глубоких настроек. Рекомендуется только для тех, кто понимает, что делает, и может дебажить через консоль.
Как настроить подключение к удалённой медиа-библиотеке через Network Media Library
Сначала: зайдите в консоль WordPress на основном сайте, который будет источником файлов. Перейдите в настройки общего доступа и включите REST API доступ к контенту. Без этого ничего работать не будет.
Теперь откройте консоль на сайте, где нужно использовать внешний контент. Установите и активируйте модуль связи. Перейдите в раздел подключения. Укажите URL-адрес источника в формате: https://source-site.com/wp-json/nml/v1/media. Убедитесь, что этот адрес доступен публично. Нет HTTPS? Зря. Настройте.
Важно: если используется Basic Auth или JWT, обязательно передавайте токен авторизации. Без него вы получите 403 и вечный reload.
Проверьте конфигурацию постоянных ссылок. Без ЧПУ API не заработает. Примеры некорректной ссылки: ?rest_route=/nml/v1/media. Так быть не должно. Настройте структуру на /post-name/.
Внимание! Если сайт находится на поддомене или мультисайте, прописывайте точные пути до API, включая схему и порт, если нестандартный.
Далее – выберите, что синхронизировать. Изображения? Видео? Все сразу? Укажите типы MIME, чтобы избежать захламления.
Зайдите в Media Settings на принимающем сайте. Включите автоматическую подгрузку мета-данных. Это критично: иначе alt-теги, заголовки и размеры не подтянутся. Результат – пустые блоки и сломанная верстка.
Проверьте CORS-заголовки. Пример настройки на сервере Apache:
Header set Access-Control-Allow-Origin \"*\"
Header set Access-Control-Allow-Methods \"GET, OPTIONS\"
Проблемы с CORS? Значит, браузер блокирует внешний контент. Смотрите консоль разработчика, ищите ошибку blocked by CORS policy. Правьте .htaccess или конфигурацию Nginx.
Важно помнить: если источник использует кэширование, например, через плагин кеша или Cloudflare, не забудьте добавить исключения для REST-запросов. Иначе данные будут подгружаться с задержкой или неактуально.
Проведите финальную проверку: загрузите изображение на исходный сайт, затем проверьте, появилось ли оно в галерее подключенного сайта. Нет? Чистите трансиенты, сбрасывайте кэш REST, проверяйте nonce.
Резюме: правильное подключение требует дисциплины. Одна ошибка – и вы получаете пустые блоки, битые ссылки, обрывы. Следуйте шагам точно. Тестируйте каждый этап. Сомневаетесь – логи Apache и консоль браузера дадут больше, чем десяток туториалов.
Решение проблем с отображением медиафайлов на клиентских сайтах сети
Первое, что нужно проверить – настройки доступа в wp-config.php. Убедитесь, что глобальное хранилище не заблокировано через DISALLOW_FILE_MODS или DISALLOW_UNFILTERED_HTML. Эти директивы могут мешать загрузке изображений на дочерних сайтах.
Далее – права. У основного сайта должны быть правильно выставлены права на каталог wp-content/uploads. Разрешение должно быть не ниже 755 для директорий и 644 для файлов. Неверные права – гарантированные ошибки загрузки.
Теперь о REST API. Если изображения не подгружаются, а путь к ним корректный – проверьте доступность конечной точки /wp-json/ на основном сайте. Часто причиной является конфликт с модулем безопасности (например, Wordfence или iThemes). Отключите – проверьте.
Настройки постоянных ссылок на клиентских сайтах тоже могут стать источником проблем. Если включён режим простых ссылок, вложенные изображения могут возвращать ошибку 404. Переключитесь на «произвольные» и сбросьте правила через flush_rewrite_rules().
Важно помнить: если используется многоуровневая структура поддоменов или подпапок, пути к файлам могут сбиваться из-за неправильных фильтров. Пример: фильтр wp_get_attachment_url может переопределять домен на текущий сайт. Используйте switch_to_blog() для получения точного URL.
Внимание! Если вы видите миниатюры, но не оригиналы – проблема почти всегда в кэшировании. Проверьте объектный кэш и удалите временные файлы.
В многосайтовых конфигурациях обязательно проверяйте опцию upload_url_path в базе данных. Некорректный URL в этой настройке приводит к тому, что изображения отображаются с неправильным адресом. Команда для исправления через WP-CLI:
wp option update upload_url_path \'https://main-site.com/wp-content/uploads\'
Следующий уровень: фильтрация через CDN. Некоторые прокси-сервисы (Cloudflare, BunnyCDN) могут кешировать 403 ошибки, если файл физически недоступен. Нужно отключить автооптимизацию или добавить исключения по пути к директории загрузок.
Наконец, если используется кастомная логика загрузки, проверьте, не перезаписывает ли она мета-данные вложений. При отсутствии поля _wp_attached_file WordPress не сможет отобразить изображение в админке и на фронте.
Важно! Регулярно выполняйте синхронизацию данных между сайтами – несоответствие мета-информации вызывает ошибки даже при наличии физического файла.
Суть проста: если файлы не видны, значит либо сломался путь, либо кто-то подменил URL. Поиск начинается с базы. Заканчивается фильтрами. Всё остальное – шум.
Ограничения прав доступа к медиафайлам между сайтами в мультисайте
Запрещайте доступ к чужим загрузкам. Это первое, что нужно сделать. По умолчанию WordPress мультисайт не изолирует загрузки между сайтами – любой сайт может теоретически получить прямую ссылку на файл другого. Нужна фильтрация.
Добавьте проверку владельца вложения перед отображением файла. Используйте attachment_url_to_postid() и get_blog_details(), чтобы убедиться, что файл принадлежит текущему сайту:
add_filter( \'wp_get_attachment_url\', function( $url, $post_id ) {
$attachment_blog_id = get_current_blog_id();
switch_to_blog( get_current_blog_id() );
if ( get_post( $post_id )->post_author !== get_current_user_id() ) {
$url = \'\'; // блокировка чужих файлов
}
restore_current_blog();
return $url;
}, 10, 2 );
Это работает, только если файлы загружены в БД. Если вы используете общую файловую директорию, ситуация осложняется. Здесь нужен уровень фильтрации на уровне .htaccess или NGINX. Пример:
# .htaccess
RewriteCond %{REQUEST_URI} ^/wp-content/uploads/sites/([0-9]+)/
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in_
RewriteRule .* - [F,L]
Такой подход запрещает загрузку файлов, если пользователь не авторизован. Но это грубо. Тонкая настройка требует авторизации по session/cookie, проверок nonce и даже собственных middleware для выдачи доступа.
Важно: файлы, загруженные с одного сайта, не должны быть доступны с другого без проверки прав – это нарушение логики мультисайта и потенциальная утечка данных.
Теперь про нюанс: WP не учитывает принадлежность вложения к сайту при запросе по REST API. Запрос к /wp-json/wp/v2/media может выдать файлы другого сайта, если ID совпадает. Это баг. Защита – кастомный REST контроллер с проверкой get_current_blog_id() против get_post()->blog_id.
И ещё. Если сайт A подключает файл сайта B через <img src> – это технически работает. Но нарушает концепцию. Такие связи нужно рвать. Файл должен быть клонирован в текущий сайт при вставке, либо блокироваться через CSP-заголовки:
Content-Security-Policy: default-src \'self\'; img-src \'self\';
Помните: мультисайт – это не общая корзина. Это группа изолированных сущностей с жёсткими границами. Файлы – не исключение.
Проверьте: используете ли вы switch_to_blog() в обходе? Тогда нужно обязательно вызывать restore_current_blog(), иначе контекст сохранится и доступ будет дырявый. Микро-утечки приводят к глобальным последствиям.