Ошибка совместимости между WP Rocket и WordPress 7.1 привела к сбоям на сайтах, использующих модуль Cloudflare популярного плагина кэширования. О баге было сообщено в репозитории WP Rocket на GitHub 6 июля, во время бета-тестирования WordPress 7.1, с предложенным в репорте однострочным решением. Однако баг не был исправлен вплоть до релиза в среду.
В четверг WP Rocket выпустили исправление — релиз 3.23.2.2.
Остин Гиндер, основатель Anchor Hosting, ставший в этом году одним из самых активных исследователей безопасности в экосистеме WordPress, первым сообщил об этой проблеме. В среду он опубликовал в X пост о том, что сайты, использующие WP Rocket на его хостинге, отключились после обновления до версии 7.1, и что он вручную скорректировал плагин, чтобы восстановить их работу.
В посте, опубликованном в четверг, Гиндер подробно описал случившееся. Из 332 сайтов в его сети, работающих на WP Rocket, на 124 (37%) произошли фатальные ошибки PHP. Все сбои были вызваны одной и той же комбинацией: WordPress 7.1, PHP 8.x и модуль Cloudflare.php от WP Rocket.
Баг представляет собой ошибку несоответствия типов, вызванную изменением в механизме генерации ID обратных вызовов хуков в WordPress 7.1. При строгом контроле типов в PHP 8 несоответствие приводит к фатальной ошибке, но только если активны определенные плагины. Гиндер обнаружил, что чистая установка WordPress только с WP Rocket не приводит к сбою. Добавляем Elementor Pro или Contact Form 7 Redirection — и сайт «падает» при следующем запросе.
Компания Wordify, предоставляющая услуги управляемого хостинга и опубликовавшая подробное техническое описание бага после его воспроизведения на собственном тестовом сайте, отметила, что модуль Cloudflare в WP Rocket запускается при каждом запросе независимо от того, использует ли сайт Cloudflare или нет. Это позволяет объяснить, почему сбой застал врасплох стольких владельцев сайтов.
Такое условное поведение может частично объяснить, почему внутреннее тестирование WP Rocket его не выявило. Но существование бага не являлось какой-то тайной. В тикете на GitHub от 6 июля была указана точная причина бага и ссылка на соответствующий тикет в ядре WordPress. Компания WP Rocket изначально публично не отреагировала на проблему.
Мэтт Кромвелл, основатель Roots & Fruit, отметил в X, что изменение в ядре, вызвавшее баг, само по себе было улучшением производительности. «По иронии судьбы, похоже, что целью основного изменения было улучшение производительности, — написал Кромвелл, — то, чем как раз и занимается WP Rocket».
В четверг компания WP Rocket опубликовала в X первоначальное предупреждение, призывая пользователей не обновлять WordPress до версии 7.1 до тех пор, пока не будет готово исправление, добавив к посту ссылку на документацию с обходными путями. Исправление было выпущено позже в тот же день.
Реакция последовала незамедлительно. Эрл Дэвис, старший разработчик WordPress в Aristotle, назвал пропущенный репорт в GitHub свидетельством некомпетентности, написав в X, что он «потерял дар речи», поскольку команда разработчиков игнорировала зарегистрированную проблему в течение нескольких недель. Веб-разработчик Гийом Бурдаж задался вопросом в X, как премиум-плагин может поставляться с таким фундаментальным багом, указав на недавнее повышение цены. Другие пользователи сообщили, что сбой привел к отключению их рабочих сайтов.
Компания WP Rocket признала свою ошибку. В ответе на сообщение разработчика WordPress Ремкуса де Вриса в X, который заявил, что у него осталось ощущение, будто бы этого можно было избежать, WP Rocket написала, что на следующей неделе сообщит, что пошло не так и что будет изменено. Компания также сообщила Дэвису, что проводит анализ того, как был обработан репорт от 6 июля.
Когда другой разработчик спросил, тестировался ли плагин на пререлизах WordPress 7.1, WP Rocket ответили, что тестировали плагин, но попросили время на выяснение причин, по которым тестирование не выявило проблему.
Этот инцидент вновь поднял вопросы об автоматических обновлениях WordPress. Разработчик Эндрю Хойер написал в X, что сбой заставил его команду пересмотреть свой подход к автоматическим обновлениям.
«Полагаю, нам необходима более надежная процедура тестирования. Мне следовало тестировать WordPress 7.1 (альфа-, бета- и RC-версии) на собственных серверах, а не доверять это крупным компаниям», — написал он, добавив: «Урок усвоен».
Другие отнеслись к владельцам пострадавших сайтов с меньшим сочувствием. Разработчик Стив Джонс задался вопросом в X, все ли обновляют WordPress на рабочем сайте сразу после выхода релиза; нормально ли вообще это делать без какого-либо тестирования и без возможности отката к прошлой версии.
Этот инцидент уже вызвал реакцию со стороны разработчиков ядра. Адам Сильверстайн в четверг открыл тикет в Trac, предложив новый рабочий процесс GitHub Actions, который будет автоматически тестировать 100 самых популярных плагинов из каталога WordPress.org на невыпущенных версиях WordPress, выявляя критические ошибки до того, как они попадут на рабочие сайты. Черновик пул-реквеста уже доступен, и тикет был добавлен в план разработки WordPress 7.2.
Сильверстайн признал в тикете, что предложенный алгоритм действий не позволил бы выявить именно этот инцидент, поскольку WP Rocket — это платный плагин, а API каталога охватывает только бесплатные плагины. Но он говорит, что подобная ошибка несоответствия типа с таким же успехом могла бы возникнуть в любом из бесплатных плагинов с миллионами установок.
Джеффри Пол поддержал это предложение. «Учитывая многочисленные случаи, когда владельцы сайтов на WordPress сталкиваются с фатальными ошибками после главных обновлений WP, разработчики ядра должны сделать все возможное, чтобы предотвратить подобные негативные ситуации в будущем», — написал Пол в тикете.
WP Rocket заявила, что опубликует полный анализ произошедшего на следующей неделе.
