Як саме працюють автоматичні оновлення?

Сьогодні вранці я отримав електронний лист із повідомленням про те, що мій сайт Wordpress було автоматично оновлено до останньої версії. Я знав про цю функцію, але завжди цікавився, як вона працює.

PHP не є постійно працюючим процесом: він працює лише за запитом. Наскільки я можу сказати, Wordpress може оновлювати себе лише тоді, коли хтось завантажує веб-сторінку. Але процес оновлення не миттєвий, тому, безумовно, користувач, який відвідує сайт, мав би дуже повільне завантаження сторінки.

Чи є інший трюк, який вони використовують для автоматичних оновлень? Я шукав всюди, але не знайшов жодного пояснення.

PHP не є постійно працюючим процесом: він працює лише за запитом. Наскільки я можу сказати, Wordpress може оновлювати себе лише тоді, коли хтось завантажує веб-сторінку. Але процес оновлення не миттєвий, тому, безумовно, користувач, який відвідує сайт, мав би дуже повільне завантаження сторінки.

Чи є інший трюк, який вони використовують для автоматичних оновлень? Я шукав всюди, але не знайшов жодного пояснення.

Система, яку ви шукаєте тут, називається "WP Cron". Це фонова система процесів у WordPress, яка дозволяє події відбуватися поза звичайною обробкою. Їм все ще потрібен спусковий механізм, щоб відбити їх, але вони не перешкоджають завантаженню сторінок через фоновий процес.

Так що так, хтось повинен завантажити вашу сторінку. Вимкнено у файлі за замовчуванням filters.php, ви знайдете цей рядок коду:

add_action( 'init', 'wp_cron' );

Отже, при кожному завантаженні сторінки функція wp_cron працює. Ця функція закінчена в wp-include / cron.php, і це робиться для перевірки запланованих подій у базі даних. Якщо у фоновому режимі є якісь процеси, які потрібно запустити, він викликає функцію spawn_cron.

Spawn cron має два можливі способи роботи, але перший і найпоширеніший - викликати функцію wp_remote_post для встановлення з'єднання назад до себе, за URL-адресою wp-cron.php. Створюючи цей додатковий запит HTTP, він запускає інший процес PHP, щоб виконати всю фактичну роботу. Тут запит не блокується, із затримкою 0,01 секунди. Отже, тут насправді не виходить ніяких результатів. Мета запиту - просто запустити новий процес у фоновому режимі. Після цього він просто повертається, тому користувач, який переглядає, ніколи не має затримок.

Процес wp-cron.php - це те, що реально працює, і оновлення, і все інше. Багато процесів у WordPress обробляється системою cron. Заплановані публікації після публікації, обробка пінгерів, перевірки оновлень, все, що повинно відбутися поза нормальним потоком, можна запланувати, а потім виконати за потребою.

Але так, звичайне потрапляння на сайт має справді статися, щоб почати процес. І ні, WordPress.org не контактує безпосередньо з вашим сайтом, щоб розпочати роботу, ваш сайт повинен отримати певну форму трафіку, щоб запустити його. Будь-яка форма руху буде робити.

Власне, автоматичне оновлення відштовхується від wp.org. Процес оновлення все ще працює на вашому сайті, але у фоновому режимі через wp-cron.

Коли виходить нове незначне оновлення, хлопці WordPress починають розгортати оновлення. Фактичний процес оновлення починається після того, як ваш сайт перевіряється wp.orgна оновлення, оновлення теоретично доступне, і ваш сайт вибирається випадковим чином для оновлення.

(Дякую @otto за вказівку на мою неправильну формулювання :))

Оскільки кожен сайт перевіряє wp.orgнаявність нових версій (як правило, двічі на день, що використовуються wp-cron), сервер rolloutserver знає, скільки сайтів потребує оновлення.

Далі випуск починається повільно - 1 з 128 сайтів оновлюється автоматично. Це контролюється, і якщо послідовний показник не має проблем з розгортанням, більшість сайтів отримують автоматичне оновлення (зазвичай наступним кроком буде 1 з 64, і надалі таким чином збільшується), поки не будуть доставлені всі автоматичні оновлення.

Це дає змогу розробникам зупинити випуск, якщо виникають якісь проблеми, але останнє оновлення 3.8до до 3.8.1було 100% успішним.

Сайти, вибрані компанією 1 out of 128, насправді випадкові. Ну, не дуже, але якщо ви хочете знати, це працює так:

URL-адреса сайту, що потребує оновлення, отримує хеш-використання MD5. Використання лише перших трьох символів цього хеша та перетворення його в base10це дає 4096 можливостей. Оновлення розпочалося для сайтів, що мають розрахункове число від 0 до 31 (4096/32 = 128).

Гаразд, гадаю, все-таки досить випадково;)

У моєму випадку, оскільки я запускаю багато сайтів WordPress, оновлення зайняли 1 день - було досить смішно бачити, коли всі сторінки оновлюються.

Про всяк випадок, коли вам було цікаво: D

btw, ось стаття на make.wordpress.org описує процес, як він відбувся.

У дуже широкому розумінні, коли користувач відвідує сайт Wordpress перевіряє, чи закінчився термін дії таймера, і якщо виявлено термін дії, на сервер надсилається інший запит, щоб "запустити" дії, пов'язані з подією, що минула. Ось чому користувач не відчуває помітної затримки завантаження сторінки, оскільки сервер виконує фактичну дію (оновлення в цьому випадку) в окремому процесі.

Це працює, але терміни не дуже точні. Чим більше трафіку має ваш сайт, тим точніше він буде.

Люди, які хочуть досягти кращої продуктивності та більш точних термінів, можуть заблокувати внутрішній крон "процес" у wordpress, а також використовувати процес cron для запуску перевірки таймерів.