WordPress 7.1 и загрузка изображений: что проверить после обновления

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

Для владельца сайта это не повод разбираться в WebAssembly. Практический вывод проще: после обновления нужно проверить оба пути. Сообщение «файл загружен» ещё не подтверждает, что появились все размеры, сработал оптимизатор, CDN получил файлы, а на странице показывается правильная версия изображения.

Что изменилось в WordPress 7.1

WordPress 7.1 вышел 19 августа 2026 года. В релизе обработка изображений в редакторе перенесена в браузер: там могут выполняться сжатие, изменение размера, поворот по EXIF и создание зарегистрированных миниатюр. Получившиеся варианты загружаются отдельными запросами.

Полный клиентский конвейер работает в совместимых Chromium-браузерах при подходящих ресурсах устройства, сети и настройках безопасности. Для неподдерживаемого браузера, слабого устройства, медленного соединения или несовместимой политики CSP предусмотрен автоматический серверный fallback. Поэтому два редактора одного сайта могут фактически использовать разные способы обработки одного файла.

Подготовьте контрольный набор до обновления

Проверку удобнее проводить на тестовой копии. До обновления сохраните резервную копию и выберите несколько файлов, которые отражают обычную работу редакции:

стандартную фотографию JPEG;
PNG или WebP с прозрачностью, если такие файлы используются;
крупную фотографию с телефона;
HEIC, AVIF или анимированный GIF, только если этот формат действительно встречается на сайте;
изображение для товара, баннера или другого блока с собственными размерами темы.

Для каждого файла запишите исходный формат, размер в пикселях и объём. Не берите случайные картинки из интернета: контрольный набор должен быть легальным, понятным и воспроизводимым.

Проверьте загрузку до конца, а не до галочки

После обновления загрузите контрольные файлы через редактор записи или страницы. Дождитесь завершения очереди и откройте каждый элемент в медиатеке. Проверьте название, формат, размеры, ориентацию, подпись и альтернативный текст.

Затем добавьте изображение на тестовую страницу и посмотрите её на компьютере и телефоне. Важно убедиться, что:

картинка открывается без ошибки и не повёрнута неожиданным образом;
обрезка соответствует выбранному блоку;
в HTML присутствуют подходящие варианты srcset, если тема их использует;
на мобильном устройстве не загружается неоправданно большой оригинал;
после очистки кеша страница не показывает старую или битую копию;
удаление тестового вложения не оставляет ненужные производные файлы в публичной странице.

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

Сравните Chromium и серверный fallback

Повторите одинаковую загрузку в актуальном Chrome или Edge и в браузере, который использует серверный путь. На дату выпуска WordPress указывал, что Firefox и Safari автоматически переходят к серверной обработке для основного WASM-конвейера.

Если в одном браузере всё работает, а в другом нет, это уже полезное доказательство. Оно сужает поиск до клиентской обработки, ресурсов устройства, расширений браузера, заголовков изоляции или CSP. Если ошибка повторяется везде, нужно проверять общие серверные причины: лимиты запроса, доступное место, права на каталог загрузок, REST API и плагины обработки медиа.

Не отключайте CSP на рабочем сайте ради эксперимента. Техническое описание WordPress указывает, что для рабочего Web Worker нужна директива worker-src с разрешением blob:; при несовместимости должен включаться fallback. Сначала сохраните заголовки и ошибки консоли, затем проверяйте исправление на тестовой копии. Ослаблять всю политику безопасности из-за одной загрузки нельзя.

Проверьте плагины, CDN и финализацию

Особое внимание нужно сайтам с оптимизатором изображений, водяными знаками, выгрузкой файлов в CDN или облачное хранилище. Убедитесь, что сервис получил не только оригинал, но и нужные производные размеры, а URL на тестовой странице ведут на существующие файлы.

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

Не забудьте про серверные ограничения

Клиентская обработка снижает нагрузку на создание миниатюр, но сервер всё равно принимает и проверяет файлы. Кроме того, fallback полностью зависит от серверной среды. В справке WordPress среди важных настроек перечислены upload_max_filesize, post_max_size, лимиты времени и памяти PHP.

Если небольшой JPEG проходит, а крупный файл стабильно отклоняется во всех браузерах, зафиксируйте точный порог и ответ сервера. Не увеличивайте лимиты вслепую: сначала проверьте, какой компонент обрывает запрос — браузер, веб-сервер, PHP, защитный модуль или сам WordPress.

Что собрать перед обращением в поддержку

Хорошее описание сокращает диагностику. Приложите дату обновления, версию WordPress, браузер и его версию, формат и размер контрольного файла, точный текст ошибки, время попытки и URL тестовой страницы. Укажите, повторяется ли проблема в другом браузере и с маленьким JPEG.

Если доступны инструменты разработчика, сохраните ошибку консоли и неуспешный сетевой запрос без cookie, токенов и персональных данных. Для разовой диагностики можно обратиться в техническую поддержку сайтов VOWE: на действующей странице услуги отдельно указаны задачи по WordPress, шаблонам, формам, WooCommerce и интеграциям.

Чек-лист проверки изображений после WordPress 7.1

Обновление сначала выполнено на тестовой копии, а резервная копия проверена.
Контрольные файлы отражают реальные форматы и размеры сайта.
Загрузка завершена в редакторе и проверена в медиатеке.
Ориентация, обрезка, качество и альтернативный текст корректны.
На тестовой странице работают изображения и производные размеры.
Мобильная версия не получает неоправданно большой оригинал.
Одинаковый набор проверен в Chromium и через серверный fallback.
Оптимизатор, водяной знак и CDN обработали все нужные варианты.
Нет отсутствующих миниатюр после завершения загрузки.
CSP не отключалась; заголовки и ошибки сохранены для диагностики.
Проверены серверные лимиты, свободное место и REST-запросы.
После очистки кеша страница открывается без битых изображений.

Вопросы о медиа в WordPress 7.1

Почему изображение загружается в Firefox, но не в Chrome?

Одна из возможных причин — разные пути обработки: совместимый Chromium может использовать клиентский WASM-конвейер, а Firefox — серверный fallback. Это не готовый диагноз, но полезный тест. Сравните один файл, сохраните ошибки консоли и сетевых запросов, затем проверьте CSP, расширения браузера и плагины медиа.

Нужно ли отключать CSP, если не работает обработка в браузере?

Нет. Полное отключение политики безопасности создаёт новый риск. Сначала зафиксируйте действующие заголовки и убедитесь, что проблема действительно связана с Web Worker. Исправление проверяйте на тестовой копии и меняйте только необходимую директиву.

С какими задачами WordPress можно обратиться в VOWE?

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