Повествование ведется от лица разработчика WordPress Эндрю Нейсина.

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

• Вы управляете своим сайтом, используя контроль версий
• Вы применяете свой собственный механизм развертывания (чаще всего это верно для многочисленных серверов)
• Вы являетесь управляемым WordPress хостером, и уверенно продвигаете своевременные обновления самостоятельно

Я считаю, что ответ «не хочу иметь такое» – это не веский довод для отключения автообновлений. Если вы не обновляете свой сайт, то он становится менее безопасным местом как для вас, так и для ваших посетителей.

Фоновые обновления полностью безопасны. Для сайтов, на которых уже стоит WordPress 3.7, было проведено более чем 110,000 обновлений без единой критической ошибки, что осуществилось благодаря многочисленным верификационным действиям, которые сделали обновления более надежными. Фоновое обновление для незначительных релизов или релизов безопасности означает загрузку и копирование всего лишь нескольких файлов. Мы действительно добились успехов в этом деле. Мы потратили годы, оттачивая свое мастерство поставки стабильных, целевых исправлений в минорных релизах – мы не устраняем все ошибки без разбора. Эти ошибки должны представлять собой серьезные баги, и их исправление проходит через несколько уровней изучения, включая проверку как минимум двух ведущих разработчиков. У нас есть возможность провести автоматическое обновление в течение нескольких часов или дней. Для 3.7.1, скорее всего, сначала несколько часов будут идти обновления, инициированные пользователями, после чего можно будет говорить, что 1% сайтов обновился, и затем этот процент будет медленно увеличиваться.

Автоматические обновления также поддерживают более старые ветви. Если текущая версия 3.8.1, и мы выпускаем новый релиз безопасности 3.8.2, то теперь у нас есть возможность выпустить сборку 3.7.2 с этими исправлениями, т.е. сборки 3.7 и 3.7.1 смогут автоматически обновиться до безопасной версии (вам, естественно, будут по-прежнему указывать на то, что нужно обновиться до 3.8.2). Да, автоматические обновления будут, естественно, меняться, когда мы коснемся технических выпусков и исправлений безопасности. Нам нравится возможность сохранить отстающие в плане обновлений сборки безопасными. Я также ожидаю более частых технических релизов для текущей ветви WordPress, поскольку головная боль от постоянных обновлений теперь ушла в прошлое.

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

Как быть, если вы хотите воспользоваться автоматическими обновлениями, но ваш сайт сообщает вам, что применить эти обновления в автоматическом режиме не получается? Существует плагин, Background Update Tester, который определит точную причину, по которой ваш сайт не поддерживает автоматические фоновые обновления. Он не входит в ядро, поскольку он представляет собой достаточно сложную схему функций, большая часть опций которой будет непонятна технически неподготовленным пользователям. Мы считаем, что 80 процентов всех сборок поддерживают автоматические обновления. Самые частые причины, по которой они не работают: ваши права доступа к файлам требуют использования FTP, и мы не знаем ваш пароль; вы отключили эту возможность (или вы используете контроль версий); WP Cron (который обрабатывает такие вещи, как запланированные записи) не работает на вашем сервере; ваша сборка не поддерживает безопасное взаимодействие с WordPress.org. Существуют также некоторые ситуации (как, к примеру, непоследовательные права доступа к файлам), когда WordPress думает, что он может обновиться, но когда он начинает это делать, то понимает, что выполнить обновление не получится (ваша сборка в таком случае отправит вам электронное письмо).

Стоит отметить, что функции «автоматического апдейтера» более широки, нежели просто управление ядром WordPress. Если апдейтер обнаружит, что не может или не должен обновлять, он отправит письмо администратору сайта (хотите отключить и это? В дальнейшем мы покажем, как это сделать). Автоматический апдейтер поддерживает также темы и плагины. По умолчанию, переводы (для тем, плагинов и всего ядра) обновляются автоматически. Когда-нибудь в будущем мы будем в состоянии предотвращать обновление вредоносных или опасных плагинов. Это огромная победа для безопасной сети.

Понятно, что отключение всего апдейтера целиком также отключает и многие полезные возможности. Выборочное отключение – более продуманный подход. В данной статье мы покажем вам, как отключить автоматические фоновые обновления разными способами.

1. Используем систему контроля версий.

Если WordPress обнаруживает систему контроля версий, то он понимает, что вы имеете представление о своих действиях. В данном случае автоматические обновления отключаются. WordPress ищет наличие Subversion, Git, Mercurial и Bazaar. Ищет он везде.

Происходит просмотр двух директорий (ABSPATH и все, что вы обновляете, как, к примеру, WP_PLUGINS_DIR или WP_LANG_DIR) на предмет наличия директорий VCS (.svn, .git, .hg, .bz). Потом идет переход на один уровень вверх, после чего поиск продолжается. Он идет до тех пор, пока не будет достигнута корневая папка сервера. Таким образом, если у вас установлена одна только система Subversion в / или /var/www/ или /var/www/mysite.com/, WordPress-сборка по адресу /var/www/mysite.com/public_html/wordpress/ будет заблокирована в плане получения обновлений. Понятно, что это отзывается на сайте разными предупреждениями.

Есть фильтр automatic_updates_is_vcs_checkout. Если вы хотите использовать автоматические обновления, вы можете просто вернуть true в этом фильтре. Фильтр также пропускает директорию, которую он ищет в дополнение к ABSPATH, так что если вы хотите обновить языковые файлы (даже при запущенной системе Subversion), вы можете воспользоваться следующим кодом:

function update_languages_vcs( $checkout, $context ) {
    if ( $context == WP_LANG_DIR )
        return true;
    return $checkout;
}
add_filter( 'automatic_updates_is_vcs_checkout', 'update_languages_vcs', 10, 2 );

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

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

2. Запрещаем любые изменения файлов.

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

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

Также будут заблокированы уведомления об обновлении, которые посылаются на почту администратору для минорных релизов.

3. Отключаем автоматический апдейтер целиком.

Константа AUTOMATIC_UPDATER_DISABLED позволяет полностью отключить автоматический апдейтер. Она напоминает DISALLOW_FILE_MODS – запрет любых изменений – однако применима она только к автоматическому апдейтеру.

Не используйте эту константу для блокировки одних только обновлений ядра! Вы также заблокируете попутно кучу полезной функциональности. Вы не будете получать обновления переводов (языковые паки) для ядра, тем и плагинов. Вы не будете получать уведомления на почту, которые сообщают о новых версиях. Также вы отключите все возможности поверхностного контроля.

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

Есть также фильтр с тем же самым названием automatic_updater_disabled (он переписывает константу).

4. Отключаем только обновления ядра.

Самый простой способ управления обновлениями ядра – использование константы WP_AUTO_UPDATE_CORE:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
 
# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );
 
# Enables core updates for minor releases (default):
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Есть также несколько фильтров, которые вы можете использовать для более тщательной настройки, которые переписывают константу: allow_dev_auto_core_updates (как, к примеру, обновление от 3.7-RC к 3.7-RC2), allow_minor_auto_core_updates (обновление от 3.7 к 3.7.1), allow_major_auto_core_updates (от 3.7 к 3.8). Чтобы позволить соответствующие обновления, достаточно вернуть true через эти фильтры (либо false для запрета).

5. Управляем обновлениями ядра, плагинов, тем и переводов по отдельности.

Предыдущие опции конфигурации работают по принципу «либо все, либо ничего». Возможно, вы пожелаете сделать что-то более тонкое. Фильтр auto_update_$type (auto_update_core, auto_update_plugin, auto_update_theme, auto_update_translation) используется для определенных обновлений, когда они готовы к запуску. Фильтр передает фактический объект обновления, который указывает на то, что именно требуется обновить. Это означает, что вы можете выборочно разрешить обновление некоторых плагинов или тем, или создать белый список предстоящих обновлений ядра.

6. Управляем уведомлениями, которые будут отправляться на почту администратору.

Электронные письма отправляются в трех случаях: итоговое письмо после авто обновления ядра, уведомление о том, что WP не может обновиться, а также письмо с данными для отладки при запуске разрабатываемой версии WordPress (alpha/beta/RC).

Результирующее письмо может иметь три формы:

• Успешное обновление. Прекрасно!
• Обновление не было выполнено. WordPress попытался обновиться, но тут же все закончилось провалом, как это бывает при ошибке несовпадения прав доступа.
• Критическая ошибка, когда обновление обрывается в ходе процесса копирования файлов.

(Заметьте, что мы пока еще не сталкивались с критическими ошибками. Обновления действительно надежны).

Вы можете отключить отправку данных электронных писем с помощью возврата false в фильтре auto_core_update_send_email:

/* @param bool   $send        Whether to send the email. Default true.
 * @param string $type        The type of email to send.
 *                            Can be one of 'success', 'fail', 'critical'.
 * @param object $core_update The update offer that was attempted.
 * @param mixed  $result      The result for the core update. Can be WP_Error.
 */
apply_filters( 'auto_core_update_send_email', true, $type, $core_update, $result );

Далее, за письмо об обновлении ядра отвечает фильтр send_core_update_notification_email. Письмо приходит при выходе каждой новой версии, если почтовый адрес администратора не менялся. Возврат true означает, что сборка будет всегда уведомлять вас при выходе нового обновления.

Наконец, отладочные письма представляют собой полноценный журнал всех выполненных автообновлений – ядра, переводов, плагинов и тем. Все равно что вы бы щелкнули по кнопке Обновить и наблюдали бы за появляющимися строками текста; также письма включают в себя дополнительную дату возникновения ошибки, если что-то пошло не так, как ожидалось. Такие письма управляются фильтром automatic_updates_send_debug_email. Передача false приводит к тому, что эти письма не будут отправляться при запуске разрабатываемой версии WordPress. Передача true приведет к тому, что эти письма будут отправляться вам для всех версий, в том числе и для стабильных.

Хочется сказать напоследок – выбирайте с умом! Если вы хотите заблокировать обновления ядра, используйте WP_AUTO_CORE_UPDATE.

Я получил один и тот же вопрос вот уже несколько раз за последнее время: должны ли хостинги, которые предлагают сервисы обновления WordPress, блокировать автообновления? Я не беспокоюсь за тех хостеров, которые планируют своевременно обеспечивать свои собственные обновления. Так как у них есть полноценный, неограниченный доступ к серверу, они могут это делать в разы эффективнее, нежели WordPress. Также они могут предлагать службу поддержки. Гораздо приятнее положиться на такую хостинг-компанию, чем развалиться и почивать на лаврах WordPress. Многие хостинг-компании сильно задирают планку качества, поставляя основные релизы после всего лишь нескольких недель тестирования, что является фантастическим результатом. Естественно, это говорит о том, что хостинг должен действовать немедленно и ответственно предлагать технические релизы и релизы безопасности. Именно так и работают многие компании. Некоторые из них сделали это уже в первые 12 часов. Я очень возбужден тем, как сообщество отзывается на все это!

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

Источник: make.wordpress.org/core