Медиахранилище WP: как настроить авто-оффлоад на S3 и Яндекс Объектное Хранилище
У всех бывает этот момент: заходишь в Медиафайлы WordPress, а там вместо аккуратной полочки – склад старых фоток весом по 8 мегабайт, видео с телефона, бэки шапки сайта от дизайнера и сотни дубликатов превью. Сервер тяжело вздыхает, резиновый диск на VPS предательски краснеет, а админ ночью синхронизирует папку uploads через SFTP, надеясь, что завтра не прилетит трафик из рекламной кампании. Авто-оффлоад в S3 и Яндекс Объектное Хранилище выключает этот цирк. Файлы улетают в дешёвое объектное хранилище, ссылки в постах сразу становятся облачными, сервер освобождается и начинает наконец жить, а не таскать гигабайты картинок по кругу.
Я люблю, когда вещи делают свою работу тихо. Оффлоад – ровно про это. Загрузил картинку в WP – она уже в бакете, URL переписан, CDN раздаёт её в два касания, а локальный диск почти пуст. На больших сайтах это не просто приятно, это экономит на дисках, ускоряет бэкапы и перестаёт пугать внезапные всплески посещаемости. Да, придётся немного покопаться в настройках, но оно того стоит.
Что такое оффлоад и почему это дешевле нервов
Оффлоад медиа – это когда WordPress перестаёт хранить файлы на сервере и складывает их в объектное хранилище наподобие Amazon S3 или Яндекс Объектного Хранилища. Объектное – значит без привычной файловой структуры, зато надёжно и масштабируемо. Вы платите за хранение и трафик, обычно копейки за гигабайт и за отдачу данных, и получаете доступ из любого места через URL. Плюсы простые: быстрые бэкапы сайта без медиа (они больше не жрут место), лёгкая миграция между хостингами, стабильная отдача медиа через CDN и меньше нагрузки на PHP и Nginx. Минус тоже честный – однажды придётся выделить вечер на первичную настройку и убедиться, что ссылки реально переписываются корректно, а права доступа не дырявые.
Два пути: плагин без боли или автоматизация на make.com
Кому нужно быстро и без философии – ставят плагин оффлоада. Их несколько, и у каждого свой характер. Нормально работают решения уровня Offload Media – Cloud Storage, WP Offload Media Lite и Media Cloud Sync. Они подключаются к S3 или совместимым сервисам, автоматически отправляют новые медиа в бакет и переписывают ссылки в записях и в самих attachment. Никаких скриптов, минимум шаманства, и даже обратная синхронизация бывает. Тем, у кого настроек и ветвлений больше, чем чашек на кухне, заходит другой формат – автоматизация на make.com. Там можно ловить событие загрузки медиа, крутить его как угодно, параллельно пулять в S3 и Телеграм, докручивать нейросети и вот это всё. Чуть сложнее старт, зато гибкость космическая.
Быстрый результат через плагин: Amazon S3
Начинать удобно с классики. В AWS создаём бакет с понятным именем и включаем блокировку публичных списков, чтобы нельзя было листать всё подряд. Для сайта с открытыми картинками обычно делают публичный доступ на чтение для объектов, но не для каталога целиком – раздаём только по прямым ссылкам. Дальше заводим пользователя IAM с политикой, ограниченной на один бакет, берём Access Key ID и Secret Access Key, и идём в настройки плагина в WordPress. Вводим ключи, выбираем бакет, включаем автоматическую выгрузку новых файлов и переписывание URL. Хороший плагин сразу предложит убрать локальные оригиналы после загрузки – не торопитесь, сперва убедитесь, что всё обновилось и ссылки в постах открываются. Если нужна скорость по всей стране, сверху цепляем CDN – в AWS это CloudFront, указываем свой домен с SSL, на стороне плагина заменяем базовый URL на cdn.домен.ру. Проверяем кэш, проверяем крошки в браузере, спим спокойно.
Тот же маршрут, но по русски: Яндекс Объектное Хранилище
В Яндекс Облаке логика почти такая же, только названия свои. Создаём бакет в регионе ru-central1, включаем версионирование если паранойя велит, и делаем сервисный аккаунт. Генерируем статические ключи доступа – это аналог AWS ключей, их же и используем в плагине. Самый важный параметр – endpoint. Для Яндекс это storage.yandexcloud.net, его нужно явно указать, если плагин спрашивает адрес совместимого S3. Некоторые плагины просят включить path-style адресацию, это разгружает танцы с поддоменами. Чтобы админка не ругалась на превью и кропы, не забываем CORS – разрешаем методы GET и HEAD с источника вашего домена, иногда ещё PUT для генерации миниатюр плагином. После подключения смотрим, чтобы новые загрузки летели в бакет, а ссылки в контенте менялись на https://ваш-бакет.storage.yandexcloud.net/год/месяц/файл.jpg. Если хотите красивый домен и кэширование поближе к пользователю, подключайте Yandex Cloud CDN, выпускайте бесплатный сертификат, и в настройках плагина меняйте базовый URL на медиа.домен.ру. Тут же удобно настраивать кэш правилом на картинки и видео с длинным TTL, но не переборщите – если часто перезаливаете лого, поставьте короткий срок для svg и png.
Когда плагина мало: автоматизация оффлоада через make.com
Иногда хочется больше контроля: часть медиа улетает в S3, часть в Яндекс, кое-что дополнительно оптимизируем, а ещё уведомление в Телеграм редактору. Это территория make.com. Сценарий обычно начинается с триггера на новый медиафайл из WordPress – берём модуль Watch Media, получаем метаданные и ссылку на оригинал. Дальше тянем файл в модуле HTTP или Download a file и отправляем его в Amazon S3 модулем Upload a file в нужный бакет с правильным путём, например год/месяц/имя. Ссылка на объект получается сразу, её записываем обратно в WordPress через Update a media или правим сам контент поста, если плагинов переписывания нет. С Яндексом есть нюанс: прямого коннектора может не оказаться, зато API полностью совместим с S3. Можно подписывать запросы по AWS Signature v4 и грузить через модуль HTTP, либо сделать маленькую промежуточную функцию на своём сервере, которая выдаёт пресайн-URL под каждую загрузку – сценарий в make работает тогда с обычным PUT без криптографии и головной боли. Если хочется готовых сценариев без изобретений, я собрал набор проверенных блюпринтов и разложил всё по полочкам в обучении – ссылку оставлю ниже.
Как аккуратно переписать ссылки и ничего не сломать
Тут много кто спотыкается. В WordPress поле source_url у медиапоста считается вычисляемым, и простая запись в него не канает. Когда оффлоад делает плагин, он обычно хранит в мета данные про новый базовый URL и перехватывает вывод через фильтры. Если вы идёте через make.com без плагина, у вас два пути. Первый – обновлять контент постов и блоки Гутенберга, заменяя старые домены на новые облачные. Работает, но нужен аккуратный поиск по постам и проверка сериализованных данных. Второй – написать мини-плагин на пару фильтров, который для вложений возвращает URL из кастомного мета-поля, а наполнение этого поля делать из make сценария. Я обычно начинаю с безопасного варианта с плагином оффлоада и уже вокруг него пляшу автоматизацией – меньше шансов на сюрпризы.
Безопасность, права и CORS без седых волос
Если медиа публичные – достаточно разрешить чтение объектов, но закрыть листинг бакета и все лишние методы. Для админки нужны превью и кропы, значит в CORS указываем домен сайта как разрешённый источник, добавляем методы GET и HEAD, иногда OPTIONS для предзапросов. На приватных проектах удобнее включить частный бакет и раздавать медиа по временным ссылкам – в AWS это пресайн, в Яндексе тоже есть аналог через SDK, а на фронте такая ссылка живёт например 10 минут. Ещё момент – не храните ключи доступа в коде темы, только в конфиге плагина или переменных окружения, и ограничивайте права пользователя на один бакет, без всеобщего S3FullAccess. Это банально, но спасает от лишних историй.
Сколько это стоит и когда точно надо
Обычно счёт получается приятным. Объектное хранение стоит заметно дешевле дисков на VPS при сопоставимых объёмах, а CDN экономит на повторной раздаче. Если у вас магазин на WooCommerce, медиа каталог рос как на дрожжах и на хостинге уже не помещается – самое время. Если блог на пару статей в месяц и картинок по 200 килобайт – можно не суетиться, выигрыш будет минимальный. Я ещё смотрю на бэкапы: когда база и код занимают мегабайты, а не десятки гигабайт вместе с медиа, переезд на новый сервер делается за полчаса и без адреналина.
Типичные косяки и быстрые фиксы
Самое частое – ссылки становятся смешанными и браузер ругается на небезопасный контент. Решается включением https на CDN и подменой базового URL в плагине. Второе место – забыли CORS, в админке пропали превью и кропы. Добавляем GET, HEAD, источники домена, всё оживает. Третья классика – отключили локальные копии, а оффлоад не успел загрузить файл из-за таймаута. Я всегда оставляю локальные оригиналы на пару дней, пока не увижу статистику выдачи из CDN, и только потом чищу. И ещё один старый добрый сюрприз – оптимизаторы картинок на сервере продолжают резать файлы, которых уже нет. Лечится отключением этих оптимизаторов или переводом их в режим работы до оффлоада, а лучше вообще делать оптимизацию при загрузке в make сценарием, там и контроль, и очереди, и метрики.
Где разогнаться по-настоящему
Если хочется не просто выгружать файлы, а выстроить целую конвейерную ленту – с генерацией обложек, созданием карточек в соцсетях, публикацией в Дзене и телеграме – всё это родной мир make.com. Я веду проект, где редактор загружает одну фотографию в WP, а дальше робот сам делает три формата превью, выгружает их в Яндекс, подписывает, создаёт запись, анонс в Телеграм и короткое видео для Reels. Если вам интересно собрать подобный конвейер под свои задачи, приходите на моё Обучение по make.com и загляните в готовые Блюпринты по make.com. Там есть схемы, которые экономят недели экспериментов. Ну и, конечно, короткие разборы и живые кейсы в телеге – подписывайтесь, будет полезно даже если вы только присматриваетесь: Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал.
Мини кейс: редакция на WordPress, оффлоад в Яндекс и поиск без тормозов
В одной редакции новостника картинок было столько, что бэкап шел часами, а поиск в админке медиа еле ползал. Мы подключили оффлоад на Яндекс, включили версионирование, и сделали в make.com небольшой сценарий: при загрузке фотографию пропускаем через оптимизацию, генерируем webp, обе версии складываем в бакет, в WP сохраняем мета с облачными URL. Сверху прикрутили Yandex Cloud CDN с доменом media.домен.ру. Через неделю бэкап базы уменьшился в десятки раз, а медиа библиотека перестала тормозить, потому что превью теперь отдаются из CDN. Вроде мелочь, но люди начали меньше ждать и больше работать – прямо как в рекламе, только без глянца.
FAQ
Можно ли смешивать локальное хранение и оффлоад, чтобы старые медиа остались на сервере?
Да, и это даже разумно на первом этапе. Большинство плагинов умеют оффлоадить только новые файлы, а старые трогать позже через задачу миграции. На рабочих проектах я всегда начинаю с новых загрузок, одну неделю смотрю на логи, и только потом запускаю массовый перенос старых папок uploads.
Что делать, если хранилище недоступно, а сайт должен работать?
CDN обычно вытягивает ситуацию – он кэширует часто запрашиваемые файлы и продолжает их раздавать, даже если бекенд временно молчит. На критичных проектах включайте достаточный TTL и стейл при ошибках. В худшем случае можно временно вернуть локальные копии, если вы их не удаляли, или переключить базовый URL обратно на локальный домен через конфиг плагина.
Подходит ли оффлоад для WooCommerce и больших каталогов товаров?
Да, это типичный сценарий. Картинки товаров, превью, вариации – всё уносится в бакет. Важно проверить совместимость вашего оптимизатора миниатюр с оффлоад плагином и не допустить ситуации, когда генерация превью проходит после выгрузки и плагин не узнаёт о новых файлах. Проще всего делать генерацию до или сразу в момент выгрузки.
Как организовать приватные медиа – видеоуроки, файлы для платных подписчиков?
Делайте закрытый бакет и раздавайте файлы по временным ссылкам. В AWS это пресайн ссылки, в Яндекс – аналог через SDK. Можно генерировать URL прямо из make.com, если у вас есть промежуточный сервис, который подписывает запросы. На фронте срок жизни ссылки 5-15 минут обычно достаточно, а пользователи ничего не замечают.
Нужно ли настраивать CORS, если медиа просто вставлены в записи?
Да, иначе превью в админке и некоторые JS инструменты будут ругаться. Минимальный набор – разрешить GET и HEAD с вашего домена и из админки, плюс OPTIONS для предflight. Безопасность это не ломает, а жизнь админам облегчает.
Можно ли обойтись без плагина и сделать всё на make.com?
Можно, но тогда вам придётся самостоятельно переписывать ссылки в контенте и аккуратно пробегаться по блокам Гутенберга. Для маленьких сайтов это несложно, для больших – лучше всё же положиться на зрелый плагин оффлоада, а make использовать для оптимизации, параллельных выгрузок и интеграций с другими инструментами.
Как быстро откатиться, если что-то пошло не так?
Держите бэкап базы и не удаляйте локальные оригиналы пару дней. Если поняли, что ссылка переписалась некорректно, возвращаете базовый URL в настройках плагина на локальный, чистите кэш CDN и проверяете. Дальше неспеша правите конфиг, а ночью снова включаете оффлоад.