Dostałem dziś link do wpisu na Facebooku, w którym jako grafika widniał kod PHP znaleziony zapewne w jakiejś „odziedziczonej i modernizowanej po kimś” stronie internetowej, z dopiskiem, że to – w uproszczeniu – wielkie zło. Oczywiście z linkiem pojawiło się pytanie, czy to faktycznie takie zło wcielone, i – jeśli tak – co jest tam nie tak.
Wyłączenie aktualizacji w WordPressie
Odpowiedzi udzieliłem dość szybko, bo wystarczył krótki rzut oka na kod by zorientować się, że faktycznie jest to zachowanie naganne osób tworzących stronę, zwłaszcza, jeśli nie jest ona pod ich stałym zarządzaniem (choć uważam, że nawet stałe zarządzanie stroną internetową bezpośrednio przez specjalistów nie uzasadnia tego typu „trików”).
I o ile kod do skomplikowanych nie należy, to jego konsekwencje mogą być opłakane dla właściciela strony internetowej:
add_filter('pre_site_transient_update_core', 'remove_updates');
//add_filter('pre_site_transient_update_plugins', 'remove_updates');
//add_filter('pre_site_transient_update_themes', 'remove_updates');
function remove_updates(){
global $wp_version;
return(object) array('last_checked' => time(), 'version_checked' => $wp_version);
}
Z trzech pierwszych linijek używana jest tylko jedna, która odpowiedzialna za wywołanie funkcji „remove_updates”, w raz z którą sprawia, że WordPress nie będzie aktualizowany (nie będzie nawet informacji, że jest dostępna nowa wersja). Druga i trzecia linijka odpowiadają za zablokowanie informacji o dostępnych aktualizacjach dla wtyczek i motywów, ale w powyższym przypadku są nieaktywne (zakomentowane).
Jestem w stanie w pewnych okolicznościach zrozumieć fakt zablokowania aktualizacji wtyczek i motywów – gdy korzystamy tylko z własnych/autorskich wtyczek i motywu, i chcemy zablokować „obcą aktualizację” (wystarczy, że w repozytorium WordPressa pojawi się motyw o takiej samej nazwie, ale z wyższym numerem wersji i nieszczęście gotowe).
Wynika to z tego, że – jeśli nic ostatnio się nie zmieniło w tym temacie – w WordPressie nie ma mechanizmów zabezpieczających przed tego typu sytuacjami, jak choćby podpis cyfrowy, czy weryfikacja czegoś więcej niż tylko nazwy motywu.
To nie mogę zrozumieć blokady aktualizacji samego WordPressa, co właściwie w każdej sytuacji sprawia, że skuteczne zaatakowanie (zarażenie) nieaktualizowanej strony jest właściwie pewne. Kwestia tylko czasu.
Oczywiście może ktoś się obawiać, że któraś z kolejnych dużych aktualizacji WordPressa może przynieść na tyle istotne zmiany, że jakieś elementy na stronie przestaną prawidłowo działać. Ale nawet jeśli, to chyba lepiej, jak na stronie przestanie wyświetlać się prawidłowo np. baner promocyjny, niż ma zostać ona zaatakowana i – w konsekwencji najprawdopodobniej – zablokowana przez wyszukiwarki i przeglądarki internetowe.
Osobiście nigdy nie zdarzyło mi się zablokować na jakiejkolwiek stronie jakiemukolwiek klientowi aktualizacji WordPressa. Nawet jeśli jakąś stroną po jej przygotowaniu nie zarządzam bezpośrednio, a chce to robić sam klient, to każdorazowo przeprowadzam odpowiednie szkolenia, w których duży nacisk kładę właśnie na regularne aktualizacje (i kopie zapasowe).


- Notepad++ i wtyczka Linefilter3, czyli prosty sposób na filtrowanie treści, np. logów serwera, nie tylko na prośbę prokuratury ;-) - 1970-01-01
- Poważny danych wyciek z ALAB Laboratoria – do internetu trafiły nie tylko dane osobowe, ale też i dane medyczne, i choć już jest grubo, to ponoć tylko zapowiedź prawdziwego armagedonu - 1970-01-01
- Prosty sposób na bezpłatny dostęp do płatnych ikon Font Awesome, czyli krótkie testy przed ewentualnym zakupem - 1970-01-01
Wyłączyć aktualizacji to zły pomysł. Lepiej się nauczyć z nich posługiwać się. Chodzi mi o umiejętności aktualizacji systemu tak, aby on nie padł :)