Nadszedł czas na co najmniej dziwny artykuł. Długo się zastanawiałem, czy go opublikować, ale przez apogeum irytacji, jakie osiągnąłem w związku z problemem, jakiego dotyczy, decyzja mogła być tylko jedna. Zatem rzecz ma się o WordPress’ie, dzięki któremu widzisz ten blog. Ciekawe, nieprawdaż?

Wordpress

Otóż pewne zimowego wieczoru postanowiłem (mając wyłącznie przyjemne doznania po wcześniejszych aktualizacjach) zaktualizować ten blogowy CMS do wersji 3.8. Wszystko przebiegło z powodzeniem, ale tylko pozornym. Nieświadomy sytuacji zostawiłem w ówczesnym stanie blog i zbagatelizowałem ją. Tutaj zaczyna się niemiła przygoda. Otóż wszyscy czytelnicy, bez względu na prędkość internetu odczuwali drastyczny spadek prędkości ładowania strony. W moim przypadku dopiero po 90 sekundach strona rozpoczęła ładowanie. Pomyślałem – to nie dzieje się naprawdę. A jednak! Zniesmaczony ochoczo udałem się do wujka, wujka Google. Okazało się, że wujek jest w temacie. Przewijało się mnóstwo wpisów, artykułów, zapytań dotyczących spowolnienia WP3.8. Pomijając przedstawione propozycje, wykonałem aktualizację do najnowszej wersji – z nadzieją, że Twórcy rozwiązali „jakiś” problem, będący przyczyną – WP3.8.1. Chcesz wiedzieć co się stało później? 

Z nadzieją w nieznane…

Aktualizacja do wersji 3.8.1 nic nie dała. Pozostało skorzystać z rad wujka. Przewijało się mnóstwo rozwiązań, począwszy od przeglądowych, kompleksowych do ukierunkowanych na jeden problem. Między innymi padła sugestia zmiany właściwości max_allowed_packet  (MySQL) na wyższą – link. Wiąże się to koniecznością dostępu do pliku konfiguracyjnego my.cnf, do którego zdecydowana większość blogerów nie ma dostępu, bowiem korzystają z serwisów blogowych – np. blox.pl.

Przyjrzyjmy się problemowi głębiej. Skoro nastąpiło spowolnienie to być może podczas instalacji aktualizacji „coś” zostało „magicznie nieukończone”? Biorąc pod uwagę tę sugestię mogłoby się wydawać – aha, niedługo problem sam się rozwiąże! Guzik prawda – nic się nie zmieniło i pozostawałem nadal smutny. Jednak bojowy byłem nadal 🙂

Dalej przyglądałem się rozwiązaniom zaproponowanym tutaj. Te bardziej „wyszukane”, jak można się domyślić na wstępie nie zadziałały. Ale cóż tam się ukryło ciekawego?! Mianowicie pewien dobry człowiek ukierunkował moje myśli. Zadziałała logika – przecież aktualizując wtyczki WP mamy informację na ile zgodne są obecną wersją WP. O ile wtedy wiemy, o tyle przy aktualizacji WP nie mamy pewność czy wtyczki (wszystkie) zadziałają analogicznie, jak na wcześniejszej wersji.

Poparcie tezy uzyskałem również w kompleksowej propozycji – link. Zanim zabrałem się wyłączanie wtyczek znalazłem prawdziwą perełkę wśród rozwiązań. Dezaktywowałem wszystkie wtyczki po kolei zostawiając na koniec wspomnianą WordPress SEO by Yoast. Żadna nie wpłynęła na poprawę. A uwierzcie mi, że było to czasochłonne, bowiem każde usunięcie wtyczki to 3 żądania po 2 minuty mniej więcej. Ciężko. O dziwo dezaktywacja WordPress SEO też nie zadziałała. Zatem posunąłem się krok dalej – usunąłem tę wtyczkę. Efektu brak. Pogodzony z niepowodzeniem zacząłem wdrażać stronę comming soon, by nie irytować czytelników.

Ale jak to możliwe?!

Strona przerwy technicznej została wdrożona. Podmieniłem plik dostępu i voila – zrobione. Ale… pomyślałem o zmianie motywu jeszcze. Powróciłem z bólami do wolnego WP – zmieniłem motyw (swoją drogą nawet był śliczny :)) i pojawiło się zdziwienie na mojej twarzy – zaczęło działać szybko. Pomyślałem – motyw był winny, ale powróciłem do poprzedniego i nadal było szybko. Sytuację tłumaczę sobie jakimś cache’m WP. Tylko czy i jak bardzo przyczyniła się do niego wtyczka SEO wolę nie sprawdzać – przynajmniej na razie. Tak profilaktycznie, jako zmęczony debuggowaniem bloger. Miłego dnia!

 


Edycja (26-03-2014 11:11): Jednak WP ponownie zaczął zamulać – testowo dezaktywowałem WordPress Database Backup 2.2.4 (gdzie włączone były okresowe dumpy) – zobaczymy co to da :/