Od kilkunastu dni na stronie WordPress.org trwa dyskusja na temat pewnego pomysłu, który wywołuje spore – i zarazem chyba zrozumiałem – kontrowersje. Chodzi mianowicie o pomysł automatycznego aktualizowania starszych wersji WordPrssa. Niby nic nowego, bo od wersji 3.7 działa moduł automatycznych aktualizacji, ale… ogranicza się on obecnie tylko do aktualizacji bezpieczeństwa, w obrębie tej samej wersji (np. 3.7.*, 4.2.*, 4.9.*). Propozycja zakłada, że można by pójść dalej, i w ten sposób aktualizować strony działające na starszych wersjach WordPressa do (naj)nowszych wersji…

Automatyczne aktualizacje w WordPressie

Zaczęło się od wpisu Jake’a Spurlock, z zapytaniem, czy ekipa odpowiedzialna za rozwój WordPressa cały czas powinna zapewniać wsparcie dla starszych wersji WordPressa, czyli do wersji 3.7, gdy pojawił się moduł automatycznego instalowania aktualizacji bezpieczeństwa.

Jest to pytanie dość sensowne, bo z każdą kolejną wersja WordPressa rośnie automatycznie liczba starszych wersji, które również trzeba brać pod uwagę przy przygotowywaniu kolejnych poprawek. Nawet jeśli są to tylko części procenta, to przy popularności WordPressa jest to naprawdę sporo stron.

Temat wywołał na tyle gorącą dyskusję, że Ian Dunn w pierwszej połowie sierpnia postanowił opublikować post z propozycją, by wykorzystać moduł pozwalający instalować poprawki bezpieczeństwa do aktualizacji najstarszych wersji WordPressa (3.7+) do nowszych wersji.

W propozycji pojawia się pomysł, by stopniowo aktualizować strony działające pod kontrolą starszego WordPressa do coraz nowszych wersji, tak by ostatecznie większość stron działała pod kontrolą WordPressa nie starszego niż 6 wersji od aktualnej (obecnie mamy 5.2, a więc najstarsza „dopuszczalna” wersja, to 4.7).

Jak możecie się zapewne domyślić, pomysł ten, choć niepozbawiany sensu wywołał jeszcze większe kontrowersje. I to pomimo tego, że w jego założeniach znalazły się mechanizmy pozwalające (spróbować) poinformować właścicieli (administratorów) stron o planowanej aktualizacji z dużym wyprzedzeniem, jak i sam WordPress w ostatnim czasie został rozbudowany o wiele mechanizmów kontrolujących jego działanie, oraz sam proces aktualizacji.

Jednak jak słusznie zauważa wielu uczestników dyskusji, skoro ktoś nie aktualizuje swojej strony, to albo nie wiem, że w ogóle takie coś jak panel zarządzania (WP-Admin) istnieje, a więc szansa, że dotrze do niego informacja o planowanej automatycznej aktualizacji jest niewielka. A nawet jak dotrze (np. jako e-mail) to mała szansa, że będzie wiedział, o co chodzi. A w tym przypadku miałaby obowiązywać zasada domniemania zgody na aktualizację, jeśli nie zostaną w odpowiednim terminie podjęte kroki blokujące ją (opt-out).

Innym równie istotnym argumentem jest to, że jest też część właścicieli stron, którzy świadomie nie dokonują akyualizacji – czy to z obawy, że strona po tej operacji się rozjedzie, i to nie tylko wizualnie. A zarazem mają obecnie pewność, że w razie problemów aktualizacje bezpieczeństwa i tak dostaną.

Natomiast rozumiem problem, przed którym coraz bardziej staje ekipa odpowiedzialna za rozwój WordPressa – mijają lata, pojawiają się nowe wersje, a zarazem cały czas trzeba wspierać starsze wersje.

Ale moim zdaniem to właśnie tu jest klucz – uważam, że wystarczy – brutalnie mówiąc – olać najstarsze wersje, przeprowadzając przy tej okazji kampanię informacyjną (również w formie komunikatu w panelu zarządzania WordPressem) o tym, że bezpośrednie wsparcie jest zapewnione tylko np. dla 6 ostatnich wersji. Jeśli nie jesteś zainteresowany aktualizacją, to trudno, nikt na siłę nie będzie cię uszczęśliwiał.

Zarządzanie automatycznymi aktualizacjami w WordPressie

Przy tej okazji chyba warto wspomnieć, że WordPress od wersji 3.7 posiada nie tylko moduł pozwalający automatycznie instalować poprawki bezpieczeństwa, ale również opcję, pozwalającą zarządzać tą funkcją:

To completely disable all types of automatic updates, core or otherwise, add the following to your wp-config.php file:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

To enable automatic updates for major releases or development purposes, the place to start is with the WP_AUTO_UPDATE_CORE constant. Defining this constant one of three ways allows you to blanket-enable, or blanket-disable several types of core updates at once.

define( 'WP_AUTO_UPDATE_CORE', true );

WP_AUTO_UPDATE_CORE can be defined with one of three values, each producing a different behavior:

• Value of true – Development, minor, and major updates are all enabled
• Value of false – Development, minor, and major updates are all disabled
• Value of 'minor’ – Minor updates are enabled, development, and major updates are disabled

Note that only sites already running a development version will receive development updates.

For development sites, the default value of WP_AUTO_UPDATE_CORE is true. For other sites sites, the default value of WP_AUTO_UPDATE_CORE is minor.

Jak widać, można nawet całkowicie wyłączyć „drobne” aktualizacje. Choć oczywiście tego nie zalecam, chyba, że w środowisku testowym…