В октябре 2024 Automattic (сторона, связанная с WordPress.org) заменила в каталоге плагинов популярный Advanced Custom Fields (ACF) от WP Engine на форк под названием Secure Custom Fields. У ACF миллионы установок, поэтому шаг вызвал шум у разработчиков и владельцев сайтов.
Предыстория конфликта
Напряжение между Automattic и WP Engine нарастало с лета 2024. WP Engine — крупный managed-хостинг под WordPress. Публичные претензии Automattic касались использования товарных знаков WordPress и, по их оценке, недостаточного вклада WP Engine в ядро и экосистему при существенно меньших вложениях в разработку по сравнению с Automattic.
В сентябре обсуждались заявки Automattic на знаки вроде Managed WordPress и Hosted WordPress, которые пересекаются с маркетингом хостеров. Отдельным ударом стало ограничение доступа WP Engine к ресурсам WordPress.org: это затруднило публикацию обновлений ACF через официальный каталог.
Форк ACF: Secure Custom Fields
12 октября 2024 в каталоге WordPress.org вместо привычного ACF оказался Secure Custom Fields — форк, продвигаемый со стороны Automattic. Формальное обоснование: закрытие уязвимости, которую в тот момент нельзя было закрыть штатным обновлением оригинального плагина из-за блокировок доступа к репозиторию.
WP Engine заявляла, что патч уже выпущен, но выложить его в wordpress.org не дала блокировка. Сообщество восприняло подмену плагина с большой аудиторией (порядка 2+ млн активных установок у ACF) как жёсткий и спорный ход. WP Engine рекомендовала ставить и обновлять ACF с официального сайта плагина и через собственный канал обновлений.
Реакция и сопутствующие события
Конфликт совпал с волной уходов из Automattic (в том числе по программе добровольного выхода на фоне политики компании). Параллельно шли судебные и PR-ходы: иски, ответы, ужесточение трактовок правил товарных знаков WordPress, упоминание WP Engine в списках нежелательного использования бренда.
Для экосистемы важнее не «кто прав в пресс-релизах», а то, что контроль над slug плагина в wordpress.org и доступ к SVN/обновлениям оказались рычагом давления. Это напрямую бьёт по привычной модели «поставил из каталога и забыл».
Что делать пользователям ACF
Если нужен именно оригинальный ACF (бесплатный или Pro), а не Secure Custom Fields, ориентир такой:
- Ставьте ACF с официального сайта — advancedcustomfields.com, а не только из репозитория wordpress.org, пока ситуация с slug и обновлениями нестабильна.
- Настройте канал обновлений разработчика — по инструкциям WP Engine/ACF, чтобы патчи приходили напрямую, а не через подменённый пакет в каталоге.
- Проверьте, что реально стоит на сайте — если плагин превратился в Secure Custom Fields после автообновления, замените его на нужную сборку ACF, сделав бэкап и проверив поля/шаблоны на стейдже.
- Не смешивайте наугад — перед сменой плагина зафиксируйте версии, экспортируйте группы полей ACF, прогоните ключевые шаблоны и Gutenberg-блоки, где используются field keys.
Что из этого следует
История ACF показала, насколько сильно корпоративный конфликт может затронуть «обычный» плагин на миллионах сайтов. Имеет смысл:
- знать, откуда приходят обновления критичных плагинов;
- держать бэкапы и стейдж перед массовыми auto-update;
- для коммерчески важных сайтов дублировать дистрибутивы плагинов (zip с известного источника), а не полагаться только на один каталог.
Ситуация вокруг ACF, WP Engine и Automattic продолжала развиваться после октября 2024. Перед решениями на проде сверяйтесь с актуальными заявлениями ACF, WP Engine и статусом плагина в репозитории.
