Разработчики плагинов потребовали улучшить процесс выпуска релизов безопасности после выхода WordPress 4.2.3

WordPress 4.2.3, критический релиз безопасности, был автоматически поставлен пользователям вчера и исправлял XSS-уязвимость. Вскоре после этого форумы поддержки запестрели комментариями от пользователей, чьи сайты перестали работать после обновления.

Примерно восемь часов спустя Robert Chapin опубликовал пост в блоге Make.WordPress.org/Core, объяснив изменения, внесенные в Shortcode API в этом релизе. Согласно Роберту, эти изменения были необходимы для исправления уязвимости:

«Из-за природы самого исправления – как это часто бывает с релизами безопасности – мы не смогли заранее предупредить разработчиков плагинов о необходимых мерах, однако мы приложили все усилия, чтобы изучить то, какие плагины, возможно, будут затронуты этим релизом.

Мы старались сохранить все базовые функции Shortcode API. Однако есть некоторые новые ограничения, которые повлияли на некоторые редкие случаи использования шорткодов»

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

«Я полностью понимаю, что это – проблема, но разве такой подход не является странным? Практически все наши клиенты говорят/пишут нам в данный момент о том, что их сайты перестали работать», прокомментировал пост о Shortcode API один из разработчиков. «В идеале надо было объявить о том, что будут внесены такие огромные изменения. Теперь мне придется полностью менять свои планы, которые уже были расписаны на выходные».

В комментариях к записи WordPress.org отписалось довольно много разработчиков, ищущих способ исправления клиентских сайтов. Многие люди были разочарованы тем, что общая засекреченность действий команды безопасности, которая необходима в таких ситуациях, не была сопровождена публичным постом с необходимыми изменениями в Shortcode API. Тем временем почтовые ящики агентств и разработчиков плагинов заполняются срочными сообщениями от недовольных клиентов.

Разработчикам требуется лучшая координация с теми, кто управляет релизами безопасности. Amir Helzer, автор Types и Views, двух плагинов, которые были сильно затронуты этим релизом, суммировал высказывания многих других комментаторов на Make/WordPress.org/Core:

«Сегодня мы обновили плагин Views, переписав процесс обработки шорткодов.

Это – довольно простое изменение, которое потребовало от нас один день.

Однако на практике лучше было бы уведомить нас о предстоящем изменении, чтобы мы могли внести все коррективы заранее.

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

Нас волнует то, что клиенты (люди, которые создают сайты WordPress для поддержания своей жизни) теряют веру в систему. Они понимают, что система рассматривает их как муравьев, а не как людей. Людям не нравится, что их проблемы игнорируются.

Многие из них ведут сотни сайтов. Они не могут позволить себе все бросить и исправлять контент на таком количестве сайтов. Особенно если они сейчас находятся в отпуске с семьей.

То, что просили здесь другие люди, и что я сам хочу попросить – нам требуется механизм, который позволил бы разработчикам ядра WordPress приватно взаимодействовать с разработчиками плагинов о предстоящих изменениях.

Мы – ваши партнеры.

Без WordPress (стабильного, защищенного и надежного) нас бы не было.

Без прекрасных тем и плагинов, WordPress никогда бы не добился 24% доли в сети.

Участники ядра WordPress уже посвятили массу своего времени на развитие системы. Я не прошу никого добровольно тратить еще больше времени. Нужна помощь? Спросите нас. Есть огромное сообщество разработчиков, которые связаны с WordPress. Мы всегда рады оказать посильный вклад в разработку»

Уверенность пользователей в автоматических фоновых обновлениях несколько снизилась после выхода релиза 4.2.3. Столкновение с неработающими сайтами заставило пользователей задуматься о том, нужны ли им автоматические обновления. Релизы безопасности и технические релизы не должны включать в себя таких разрушительных изменений.

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

Последствия нового релиза безопасности – одна из причин, по которой разработчики и пользователи все еще опасаются автоматических обновлений. Amir Helzer представляет ту группу разработчиков плагинов, которые заинтересованы в поиске хороших способов сотрудничества с командой ядра для создания идеального процесса обновлений. Это особенно важно для таких релизов, как этот, в котором изменения Shortcode API напрямую затронули пользовательский контент. Комментарий Амира подтвердил тот факт, что агентства разработки, разработчики плагинов и разработчики ядра – партнеры, состоящие в одной и той же команде. Пришла пора поиска лучших путей взаимодействия между собой, чтобы предложить отлаженный процесс обновлений для пользователей WordPress.

Блог про WordPress
Комментарии: 2
  1. Обретатель

    Предпочитаю никогда не обновляться автоматом. Стараюсь предварительно изучить то, что там новенького в новых обновлениях. Бездумно не ставлю. Если обновление не включает в себя что-то реально важное (как правило гонюсь за снижением нагрузки на хостинг и производительностью), то предпочитаю и вовсе пропускать такое обновление.

    1. Дмитрий (автор)

      Можно подождать, пока все утрясется, проверить, нет ли сообщений о найденных проблемах (с помощью этого блога, к примеру — я публикую всегда такие новости), после чего уже обновиться, если все в порядке.

      И всегда стоит делать бэкапы перед этим, чтобы потом можно было все вернуть в начальное состояние.

Добавить комментарий

Получать новые комментарии по электронной почте.