Kurs "WordPress: Pierwsze kroki" (na dobry początek)

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).

Gdy korzystamy np. z jakiegoś komercyjnego motywu, który nie jest dostępny w repozytorium WordPress.org, wystarczy, że pojawi się tam jakiś jego “imiennik”. W tym momencie WordPress z chęcią zaktualizuje motyw bazowy całkiem innym motywem, co skutecznie zmieni wygląd całej strony.

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).

(!) Zgłoś błąd na stronie | Lub postaw nam kawę :-)
LUTy dla D-Cinelike (DJI Mini 3 Pro, DJI Avata, OSMO Pocket) od MiniFly
Wdrożenie Omnibusa w sklepie na WooCommerce
Jak (legalnie) latać dronem w Kategorii Otwartej
Kurs "WordPress: Pierwsze kroki" (na dobry początek)
Patryk
Kurs "WordPress: Pierwsze kroki" (na dobry początek)