WordPress 7.2 Beta: обработка изображений переходит в браузер

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

Расширение существующей возможности, а не начало с нуля

Анонс WordPress 7.2 Beta 1 опубликован 20 октября 2026 года. Он описывает расширение client-side media processing на Media Library: изменение размера, сжатие и преобразование формата перед загрузкой. Возможный выигрыш ресурсов сервера заявлен как возможность, не как результат замеров любого сайта.

Руководство по клиентской обработке медиа описывает условия браузера, устройства и сети. Если проверки не проходят, WordPress использует серверный путь. Поэтому наблюдение «у редактора всё обработалось на компьютере» нельзя распространить на каждое устройство и каждую загрузку.

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

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

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

Разные пути одной иллюстрации

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

Серверный плагин должен учитывать этапы загрузки

Handbook поясняет, что wp_generate_attachment_metadata вызывается при создании, а затем при обновлении после завершения клиентских sub-size загрузок и finalize. Там же советуют делать обработку идемпотентной: повторный проход не должен создавать лишнее действие. Наличие фильтра не означает одинаковый момент готовности всех вариантов изображения.

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

Fallback сохраняет требования к серверу

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

Не ослабляйте защитные настройки целиком ради включения функции. Если путь недоступен из-за политики проекта, разберите конкретную причину и предусмотренный fallback. Условия браузеров и самой Beta могут меняться до стабильного выпуска.

Что проверить на отдельной копии сайта

1. Запишите текущую тестируемую сборку и статус выпуска.
2. Выберите характерные иллюстрации и ожидаемый результат их использования.
3. Разделите клиентский путь и серверный fallback.
4. Проверьте нужные варианты в медиатеке и в шаблоне страницы.
5. Пройдите работу сторонних плагинов, включая повторный проход.
6. Сохраните несовместимости и повторите проверку перед рабочим обновлением.

Для сопровождения WordPress передайте набор примеров и результаты обоих путей. Доработку плагина связывайте с его входными данными, а поддержку серверной части — с фактической нагрузкой. Beta-анонс помогает подготовиться к изменению, но не заменяет проверку готовности рабочего сайта.