Мэтт Мулленвег и официальный аккаунт WordPress в X вызвали волну недовольства в сообществе после того, как на прошлой неделе использовали инцидент с фатальной ошибкой WP Rocket для публичной критики плагина кэширования.
В четверг Мулленвег опубликовал в X пост: «Ваша ракета взорвалась? Воспользуйтесь @Jetpack. 🚀» — отсылка к ошибке совместимости WordPress 7.1, из-за которой сайты, работающие с WP Rocket, перестали работать.
На следующий день официальный аккаунт WordPress в X, который контролирует Мулленвег, пошел еще дальше. Цитируя предупреждение WP Rocket, призывающее пользователей не обновляться до WordPress 7.1, аккаунт опубликовал: «Ох, призывать людей не обновляться… в версии 7.1 такого бага нет. Возможно, стоит пересмотреть использование @wp_rocket. С этим связан риск установки сторонних плагинов; в официальном каталоге есть множество альтернатив, которые, кажется, прекрасно функционировали в день релиза 7.1».
Аккаунт WordPress добавил, что компания WP Rocket была «проинформирована об этой проблеме за 44 дня до выпуска версии 7.1». Затем последовала критика аккаунта GitHub, использующего фирменную символику WordPress: подписчикам напомнили, что только Automattic и Bluehost обладают лицензиями на товарные знаки, а также предупредили людей «быть бдительными и подозрительными» в отношении других пользователей, использующих изображения WordPress.
Упоминание WP Rocket и предупреждение о нарушении товарного знака в одном из обсуждений, в дополнение к рекламе Jetpack от Мулленвега накануне, вызвали негативную реакцию.
SEO-консультант Сёрен Линдхофф ответил: «Очень плохой шаг со стороны WP Rocket, но Мэтт и его придворные клоуны активно уничтожают ту хилую репутацию, которая еще осталась у WordPress». Разработчик Пол Майкл написал: «Я не думаю, что это подходящий способ взаимодействия с сообществом. Я полагал, вы извлекли урок из предыдущей волны хейта. Очевидно, нет».
Менеджер по продуктам Cloudflare Скотт Бушеми спросил, как следует распространять платные плагины, если официальный каталог их не принимает. Аккаунт WordPress ответил: «Хотели бы вы получать платные коммерческие плагины через каталог? Как это должно работать?» Разработчик Дэйв Лоодтс отметил, что проект WordPress так и не создал надлежащий механизм дистрибуции коммерческих плагинов, несмотря на многолетние запросы со стороны разработчиков.
В чате Post Status Slack также царило недовольство. Соучредитель Dollie Боу Франкема спросил, какая еще платформа «активно ведет крестовый поход против крупнейших коммерческих организаций в своей собственной экосистеме».
Не все возражали против подхода Мулленвега. Основатель North Commerce Келли Муро написала в X: «Мэтт использует эту ситуацию в качестве показательного примера, с чем я вполне согласна».
Однако для многих этот эпизод стал отголоском старых событий, когда во время спора с WP Engine в конце 2024 года официальный аккаунт WordPress блокировал подписчиков и публиковал пренебрежительные ответы, включая уже печально известное «Извините, а вы кто?».
Выбранная формулировка снова вызвала фактическое сопротивление. Когда аккаунт WordPress сообщил пользователям, что проблема с WP Rocket «не является багом в 7.1», директор по развитию бизнеса rtCamp Дэвид Левин указал на тикет Trac #65919 — нарушение обратной совместимости ядра, из-за которого в WordPress 7.1 ID обратных вызовов хуков были изменены со строк на целые числа, и это запланировано к исправлению в версии 7.1.1.
Уэстон Рутер, разработчик, спонсируемый WP Engine, открыл тикет в Slack, написав, что, похоже, мы имеем дело с нарушением обратной совместимости, которое следует устранить. Аки Хамано, один из технических руководителей версии 7.1, подчеркнул, что, хотя проблема связана с реализацией WP Rocket, а не с ядром, «это, безусловно, момент, заслуживающий внимания».
Остин Гиндер, основатель Anchor Hosting, первым сообщивший о критических ошибках WP Rocket, также высказался на эту тему. «Это не сбой тестирования WP Rocket. Баг был тщательно спрятан», — написал Гиндер в X. «WP Rocket + WordPress 7.1 работали без проблем. Добавьте третью переменную, например, Elementor Pro, и возникнет критическая ошибка PHP».
Тем временем Девин Уокер, художественный директор Jetpack, опубликовал пост в блоге, в котором сослался на медлительные ответы WP Rocket и предложил Jetpack Boost в качестве альтернативы, предоставив инструкции по миграции.
Уокер написал в X, что он уважает «то, насколько серьезно мы относимся к инцидентам безопасности и совместимости» в Automattic, добавив, что политики Jetpack — «это не просто документация… команды следуют им, обсуждают детали и учатся на произошедшем».
Стоит отметить, что предложение по тестированию совместимости плагинов, открытое разработчиками ядра в ответ на инцидент с WP Rocket на прошлой неделе, продвинулось вперед. Независимый разработчик ядра Адам Сильверстайн провел полное тестирование 200 плагинов в своей версии, обнаружив реальную фатальную ошибку в eps-301-redirects, которая оказалась уже существующим багом плагина, а не регрессией ядра. Другой независимый разработчик ядра Аарон Джорбин предложил проводить тестирование ежемесячно по расписанию. Эта задача включена в план разработки WordPress 7.2.
После инцидента на прошлой неделе компания WP Rocket заявила, что на этой неделе опубликует анализ произошедшего, в котором расскажет о причинах сбоя и о том, как компания планирует исправиться в будущем.
