Narzędzie Stan witryny w WordPressie. Jak czytać zalecenia i które wdrożyć?

WordPress ma wbudowane narzędzie, które samo sprawdza konfigurację strony i podpowiada, co wymaga poprawy. W polskiej wersji panelu nosi ono nazwę „Stan witryny”, choć wielu właścicieli stron mówi o nim „kondycja witryny”, bo tak brzmi dosłowne tłumaczenie angielskiej nazwy Site Health. Kłopot polega na tym, że lista zaleceń bywa długa, pisana technicznym językiem i nie mówi wprost, co jest pilne, a co można spokojnie odłożyć.

Ten tekst jest instrukcją dla osób, które prowadzą firmę i same opiekują się swoją stroną albo chcą rozumieć, co robi ich wykonawca. Wyjaśniam w nim, gdzie znajduje się narzędzie, jak czytać jego ekran, co oznacza każde z najczęstszych zaleceń i jak je wdrożyć bez ryzyka dla działającej strony.

Po lekturze czytelnik będzie umiał odróżnić błąd krytyczny od drobnej sugestii, ułożyć kolejność prac, wykonać samodzielnie te poprawki, które robi się w panelu, i przygotować dla hostingu konkretne zgłoszenie w sprawach, których z poziomu WordPressa załatwić się nie da.

Gdzie znajduje się narzędzie „Stan witryny” i jak je otworzyć?

Narzędzie jest częścią samego WordPressa i nie wymaga instalowania żadnej wtyczki. Dostęp do niego ma użytkownik z rolą administratora. Jeśli po zalogowaniu pozycji nie widać w menu, najczęściej oznacza to konto o niższych uprawnieniach, na przykład redaktora.

1. Po zalogowaniu do kokpitu należy w menu po lewej stronie wskazać pozycję „Narzędzia”.
2. Z rozwiniętej listy wybiera się „Stan witryny”.
3. Ekran otwiera się na karcie „Status”. Przez kilka sekund widać komunikat „Wyniki wciąż się ładują…”, ponieważ część testów wykonuje się dopiero po wejściu na stronę. Trzeba poczekać, aż zniknie.
4. Obok karty „Status” znajduje się druga karta, „Informacja”. Zawiera ona pełny opis konfiguracji i przyda się przy rozmowie z hostingiem.

Skrócony wynik widać także na stronie głównej kokpitu, w okienku „Stan witryny”. WordPress uruchamia testy samodzielnie co pewien czas, więc okienko pokazuje ostatni znany wynik, a odnośnik w nim prowadzi do pełnego ekranu narzędzia.

W różnych wydaniach WordPressa polskie tłumaczenia pojedynczych komunikatów bywały poprawiane. Jeśli nazwa na ekranie różni się o słowo od podanej w tym tekście, chodzi o ten sam test. Sens i sposób naprawy pozostają bez zmian.

Jak czytać ekran „Status”: kółko, liczniki i etykiety?

Na górze ekranu znajduje się okrągły wskaźnik z opisem. Przyjmuje on jedną z dwóch wartości: „Dobre” albo „Powinien zostać poprawiony”. To ogólna ocena wyliczona z wyników wszystkich testów, a nie pomiar jakości strony w oczach klientów czy wyszukiwarki.

Poniżej WordPress dzieli wyniki na trzy grupy. Pierwsza to błędy krytyczne, czyli sprawy, które według opisu w panelu mogą mieć duży wpływ na wydajność lub bezpieczeństwo witryny i powinny być załatwione w pierwszej kolejności. Druga to zalecane usprawnienia: korzystne, ale mniej pilne. Trzecia, ukryta pod przyciskiem „Testy zaliczone”, pokazuje wszystko, co działa poprawnie.

Każda pozycja na liście ma po prawej stronie etykietę „Bezpieczeństwo” albo „Wydajność”. Kliknięcie pozycji rozwija opis: co WordPress sprawdził, dlaczego ma to znaczenie i często także odnośnik prowadzący prosto do miejsca, w którym wprowadza się poprawkę.

Uważam, że najważniejsza umiejętność przy tym narzędziu to czytanie rozwiniętego opisu zamiast samego nagłówka. Nagłówek bywa ogólny, a dopiero w opisie pojawia się konkret: nazwa brakującego modułu, kod błędu albo liczba wtyczek czekających na aktualizację.

Czy wynik „Dobre” oznacza, że strona jest bezpieczna i szybka?

Nie. Narzędzie bada konfigurację: wersje oprogramowania, ustawienia serwera, działanie mechanizmów WordPressa. Nie szuka złośliwego kodu, nie ocenia haseł, nie mierzy czasu wczytywania strony u odwiedzających i nie sprawdza treści. Wynik „Dobre” mówi tyle, że podstawy techniczne są w porządku.

Czy trzeba dążyć do pustej listy zaleceń?

Nie zawsze. Część zaleceń zależy od oferty hostingu albo od świadomych decyzji właściciela, na przykład rezygnacji z automatycznych aktualizacji wtyczek w sklepie internetowym. Celem jest brak błędów krytycznych i rozumienie, dlaczego pozostałe pozycje zostają na liście.

Od czego zacząć, żeby niczego nie zepsuć?

Większość zaleceń prowadzi do aktualizacji, usuwania elementów albo zmian w plikach. Każda z tych czynności może w rzadkich przypadkach unieruchomić stronę, dlatego przed pierwszą poprawką potrzebna jest aktualna kopia zapasowa WordPressa obejmująca pliki i bazę danych. Kopia sprzed miesiąca nie wystarczy, jeśli w tym czasie przybyły zamówienia albo wpisy.

1. Wykonanie kopii zapasowej plików i bazy danych oraz upewnienie się, że da się ją pobrać lub przywrócić.
2. Zapisanie obecnego stanu: na karcie „Informacja” należy kliknąć „Skopiuj informacje o witrynie do schowka” i wkleić zawartość do pliku tekstowego. Będzie to punkt odniesienia.
3. Rozwinięcie wszystkich błędów krytycznych i spisanie ich na kartce lub w notatce razem z etykietą.
4. Załatwienie w pierwszej kolejności błędów krytycznych z etykietą „Bezpieczeństwo”, następnie pozostałych krytycznych.
5. Przejście do zalecanych usprawnień, zaczynając od tych, które da się wykonać w panelu.
6. Wprowadzanie zmian pojedynczo i sprawdzanie strony po każdej z nich, zarówno od strony odwiedzającego, jak i w kokpicie.

Zasada jednej zmiany naraz oszczędza najwięcej czasu. Gdy po dziesięciu aktualizacjach wykonanych jednym kliknięciem strona przestaje działać, nie wiadomo, która z nich zawiniła.

Aktualizacje WordPressa, wtyczek i motywów: jak wdrożyć te zalecenia?

Najczęstsze pozycje na liście dotyczą nieaktualnego oprogramowania. WordPress zgłasza dostępną aktualizację samego systemu, wtyczki oczekujące na aktualizację oraz motywy w starszych wersjach. Opis w panelu przypomina, że wtyczki mają głęboki dostęp do witryny, dlatego ich aktualność ma bezpośredni związek z bezpieczeństwem.

1. W menu należy otworzyć „Kokpit”, a następnie „Aktualizacje”.
2. Jeśli dostępna jest nowa wersja WordPressa, instaluje się ją jako pierwszą i po zakończeniu sprawdza, czy strona i kokpit działają.
3. W części z wtyczkami zaznacza się jedną wtyczkę i klika „Zaktualizuj wtyczki”. Po każdej aktualizacji należy odświeżyć stronę główną i jedną podstronę z formularzem lub koszykiem.
4. Tak samo postępuje się z motywami. Jeśli strona używa motywu potomnego, aktualizuje się motyw nadrzędny, a potomny pozostaje bez zmian.
5. Na końcu wraca się do „Narzędzia” i „Stan witryny”, żeby potwierdzić, że pozycje zniknęły z listy.

Jeśli po aktualizacji pojawi się komunikat o błędzie krytycznym w witrynie, WordPress wysyła na adres administratora wiadomość z odnośnikiem do trybu odzyskiwania. Pozwala on zalogować się i wyłączyć wtyczkę, która wywołała awarię. Gdy to nie pomaga, przywraca się kopię zapasową.

Automatyczne aktualizacje wtyczek i motywów

Osobny test sprawdza, czy automatyczne aktualizacje wtyczek i motywów nie zostały zablokowane. Ostrzeżenie pojawia się, gdy jakaś wtyczka lub wpis w konfiguracji wyłącza ten mechanizm, a panel nadal pokazuje jego ustawienia. Automatyczną aktualizację włącza się osobno dla każdej wtyczki na ekranie „Wtyczki”, w kolumnie „Automatyczne aktualizacje”.

Czy włączać ją wszędzie? W prostej stronie firmowej zwykle tak, bo szybkie łatanie luk jest ważniejsze niż ryzyko drobnej usterki. W sklepie albo w serwisie z rozbudowanymi integracjami rozsądniej jest aktualizować ręcznie, regularnie i po wykonaniu kopii.

Komunikat „Aktualizacje w tle mogą nie działać zgodnie z oczekiwaniami”

Aktualizacje w tle odpowiadają za samoczynne instalowanie poprawek bezpieczeństwa WordPressa. Jeśli test je kwestionuje, w rozwiniętym opisie widać powód: blokadę wpisaną w pliku konfiguracyjnym, brak uprawnień do zapisu plików albo obecność katalogu systemu kontroli wersji. Blokady celowo ustawionej przez wykonawcę nie należy usuwać bez rozmowy z nim. Brak uprawnień do zapisu zgłasza się hostingowi.

Nieużywane wtyczki i motywy: usuwać czy zostawić?

Komunikaty „Usuń wyłączone wtyczki” oraz „Zalecamy usunięcie nieużywanych motywów” należą do zaleceń z etykietą „Bezpieczeństwo”. Wyłączona wtyczka nadal leży na serwerze jako zbiór plików. Jeśli ma lukę, może zostać wykorzystana mimo tego, że nie jest uruchomiona.

Przed usunięciem trzeba ustalić, czy wtyczka na pewno nie jest potrzebna. Bywa, że ktoś wyłączył ją tylko na chwilę podczas szukania usterki. Razem z niektórymi wtyczkami znikają też ich ustawienia i dane, na przykład zapisane zgłoszenia z formularzy. W razie wątpliwości najpierw eksportuje się te dane, a dopiero potem usuwa wtyczkę.

1. Otwarcie ekranu „Wtyczki” i przejście do widoku „Wyłączone”.
2. Przy wtyczce, która nie jest potrzebna, należy kliknąć „Usuń” i potwierdzić.
3. Otwarcie ekranu „Wygląd”, a następnie „Motywy”.
4. Kliknięcie miniatury nieużywanego motywu, a w oknie szczegółów odnośnika „Usuń” w prawym dolnym rogu.

Przy motywach obowiązują dwa wyjątki. Nie usuwa się motywu nadrzędnego, jeśli strona działa na jego motywie potomnym. Warto też zostawić jeden aktualny motyw domyślny WordPressa z serii Twenty. System sięga po niego samoczynnie, gdy z wybranym motywem dzieje się coś złego, a jego brak narzędzie zgłasza komunikatem „Zainstaluj domyślny motyw”.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: przejrzę wszystkie zalecenia z ekranu „Stan witryny”, wdrożę te, które mają sens dla danej strony, i załatwię z hostingiem resztę.

Wersja PHP, baza danych i moduły: co da się zmienić w panelu hostingu?

Ta grupa zaleceń dotyczy serwera, a nie samego WordPressa. W kokpicie nie da się ich naprawić. Robi się to w panelu klienta firmy hostingowej albo przez zgłoszenie do jej pomocy technicznej.

Starsza lub przestarzała wersja PHP

PHP to język, w którym napisany jest WordPress. Narzędzie rozróżnia dwie sytuacje. Wersja starsza od zalecanej trafia do usprawnień. Wersja, która nie otrzymuje już poprawek bezpieczeństwa, jest opisywana jako przestarzała i wymaga pilnej zmiany.

1. Wykonanie kopii zapasowej oraz aktualizacja WordPressa, wtyczek i motywu. Stare wtyczki są najczęstszą przyczyną kłopotów po zmianie PHP.
2. Zalogowanie do panelu hostingu i odszukanie ustawień PHP dla danej domeny. Nazwa tej sekcji zależy od dostawcy.
3. Wybranie nowszej wersji, najlepiej tej, którą narzędzie wskazuje jako zalecaną, i zapisanie zmiany.
4. Sprawdzenie strony głównej, podstron, formularza i logowania do kokpitu.
5. Jeśli pojawia się błąd, powrót do poprzedniej wersji PHP w tym samym miejscu i ustalenie, która wtyczka lub motyw nie obsługuje nowszej.

Zmiana wersji PHP jest odwracalna, dlatego nie trzeba się jej obawiać. Trzeba ją tylko wykonać świadomie i od razu sprawdzić skutki.

Brakujące moduły PHP

Komunikat „Brakuje co najmniej jednego zalecanego modułu” oznacza, że na serwerze nie włączono dodatku, z którego WordPress chętnie korzysta, na przykład przy obróbce zdjęć. W rozwiniętym opisie podana jest dokładna nazwa. Jeśli brakuje modułu wymaganego, pozycja trafia do błędów krytycznych.

W wielu panelach hostingowych moduły włącza się w ustawieniach PHP przez zaznaczenie pola przy nazwie. Gdy takiej opcji nie ma, wysyła się zgłoszenie. Wystarczy krótka treść: Proszę o włączenie modułu PHP o nazwie [nazwa z ekranu Stan witryny] dla domeny [adres strony]. Brak modułu zgłasza narzędzie Stan witryny w WordPressie.

Przestarzała wersja serwera SQL

Komunikat „Przestarzała wersja serwera SQL” dotyczy oprogramowania bazy danych. Właściciel strony nie zmienia go samodzielnie. Należy zapytać hosting o możliwość przeniesienia na nowszą wersję bazy, a jeśli dostawca jej nie oferuje, potraktować to jako argument przy wyborze innego hostingu.

HTTPS i bezpieczna komunikacja: co oznaczają te komunikaty?

Komunikat „Twoja witryna nie używa połączenia HTTPS” pojawia się w dwóch sytuacjach. W pierwszej strona w ogóle nie ma certyfikatu. W drugiej certyfikat działa, ale adresy zapisane w ustawieniach WordPressa nadal zaczynają się od http.

Którą sytuację pokazuje ekran, widać w rozwiniętym opisie. Jeśli WordPress wykrył, że serwer obsługuje połączenie szyfrowane, w opisie pojawia się przycisk „Zaktualizuj swoją witrynę, aby korzystała z HTTPS”. Jego kliknięcie zmienia adresy w ustawieniach. Ręcznie robi się to w „Ustawienia”, „Ogólne”, w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”.

Uwaga: wpisanie adresu z https w tych polach w chwili, gdy certyfikat nie jest jeszcze zainstalowany, odcina dostęp do kokpitu. Najpierw trzeba sprawdzić w przeglądarce, czy strona otwiera się pod adresem zaczynającym się od https, i dopiero wtedy zmieniać ustawienia. Cały proces, razem z przekierowaniami i poprawą starych odnośników, opisałem w tekście o tym, jak przejść na https bez strat.

Test bezpiecznej komunikacji oraz test połączenia z WordPress.org sprawdzają coś innego: czy serwer potrafi bezpiecznie łączyć się z innymi usługami i pobierać aktualizacje. Błąd w tym miejscu leży prawie zawsze po stronie hostingu, który blokuje połączenia wychodzące albo ma nieaktualne biblioteki. Trzeba przesłać mu dosłowną treść komunikatu z ekranu.

Zaplanowane zdarzenia, pętla zwrotna, REST API i debugowanie: jak naprawić mechanizmy WordPressa?

Te cztery zalecenia brzmią najbardziej obco, a dotyczą mechanizmów, od których zależy codzienna praca strony. Zwykle mają wspólną przyczynę: coś blokuje połączenia, które witryna wykonuje sama do siebie.

„Nie można było ukończyć zapytania pętli zwrotnej w obrębie twojej witryny”

Zapytanie pętli zwrotnej to połączenie, które strona nawiązuje z własnym adresem. Według opisu w panelu służy ono do uruchamiania zaplanowanych zdarzeń, a wbudowane edytory motywów i wtyczek sprawdzają nim, czy zmieniony kod nie psuje strony. Gdy test nie przechodzi, zaplanowane wpisy mogą nie publikować się o czasie.

Możliwe przyczyny są cztery: wtyczka bezpieczeństwa lub zapora, która odrzuca takie połączenia, hasło założone na całą stronę na poziomie serwera, błędna konfiguracja domeny na serwerze albo ograniczenie po stronie hostingu. Sprawdza się je w tej kolejności:

1. Odczytanie w rozwiniętym opisie kodu błędu i jego zapisanie.
2. Wyłączenie na chwilę wtyczki bezpieczeństwa lub zapory i odświeżenie ekranu „Stan witryny”. Jeśli komunikat znika, w ustawieniach tej wtyczki należy dopuścić połączenia z adresu własnego serwera, a wtyczkę włączyć ponownie.
3. Jeśli strona jest zabezpieczona dodatkowym hasłem serwera, na przykład w czasie budowy, test nie przejdzie do chwili jego zdjęcia. W takiej sytuacji komunikat można uznać za oczekiwany.
4. Gdy żaden z powyższych punktów nie pasuje, zgłoszenie trafia do hostingu z dosłowną treścią błędu i prośbą o sprawdzenie, czy serwer może łączyć się z własną domeną.

„REST API napotkało błąd” albo „REST API napotkało nieoczekiwany rezultat”

REST API to sposób, w jaki WordPress i inne aplikacje komunikują się z serwerem. Korzysta z niego między innymi edytor blokowy przy zapisywaniu wpisów i stron. Jeśli ten test nie przechodzi, zwykle towarzyszą mu kłopoty z zapisem treści w edytorze.

Pierwszą czynnością jest ponowne zapisanie struktury adresów: „Ustawienia”, „Bezpośrednie odnośniki”, przycisk „Zapisz zmiany”, bez zmieniania czegokolwiek. Odświeża to reguły adresów na serwerze. Drugą jest sprawdzenie wtyczek bezpieczeństwa, które potrafią wyłączać REST API dla niezalogowanych albo całkowicie. Trzecią pozostaje kontakt z hostingiem, jeśli zapora serwera odrzuca te żądania.

„Zaplanowane zdarzenie jest opóźnione” albo „Zaplanowane zdarzenie nie zostało zrealizowane”

Zaplanowane zdarzenia to mechanizm, który okresowo szuka aktualizacji, publikuje wpisy ustawione na przyszłą datę i wykonuje zadania wtyczek, takie jak wysyłka wiadomości czy tworzenie kopii. W WordPressie jest on uruchamiany przy okazji odwiedzin strony. Na stronie o małym ruchu pojedyncze opóźnienie nie musi oznaczać usterki.

Jeśli komunikat powtarza się stale, trzeba sprawdzić trzy rzeczy: czy przechodzi test pętli zwrotnej, czy w pliku konfiguracyjnym nie ma wiersza wyłączającego ten mechanizm, oraz które zdarzenie jest wskazane w opisie. Nazwa zdarzenia zwykle zdradza wtyczkę, do której należy. Gdy mechanizm wyłączono celowo, hosting powinien mieć ustawione własne zadanie cykliczne, które go zastępuje. Jego brak należy zgłosić.

Włączone debugowanie

Tryb debugowania służy do szukania usterek. Na działającej stronie nie powinien pozostawać włączony, ponieważ może ujawniać szczegóły techniczne. Narzędzie ocenia to surowo: komunikaty „Twoja witryna ustawiona jest tak, by wyświetlać błędy odwiedzającym” oraz „W witrynie ustawiono zapisywanie błędów w pliku dostępnym publicznie.” mają rangę błędów krytycznych.

Poprawkę wprowadza się w pliku wp-config.php w głównym katalogu strony, przez menedżera plików w panelu hostingu albo program FTP. Przed zmianą należy pobrać kopię tego pliku na dysk. Następnie odszukuje się wiersze zaczynające się od define( 'WP_DEBUG' i nadaje im taką postać:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Jeśli w pliku jest tylko pierwszy z tych wierszy, wystarczy zmienić w nim true na false. Plik zapisuje się bez zmiany nazwy i kodowania. Błąd w tym pliku, choćby brak średnika, wyłącza całą stronę, dlatego kopia sprzed zmiany jest konieczna. Jeżeli debugowanie włączył wykonawca, który właśnie szuka usterki, najpierw trzeba to z nim uzgodnić. Świadome korzystanie z tego trybu opisuję w tekście o tym, jak włączyć zapis błędów do pliku i go odczytać.

Pamięć podręczna i inne zalecenia z etykietą „Wydajność”: które mają sens?

Zalecenia dotyczące wydajności najczęściej budzą pytanie, czy trzeba je wdrażać. Odpowiedź zależy od wielkości strony i od tego, co oferuje hosting. Żadne z nich nie jest tak pilne jak sprawy bezpieczeństwa.

Pamięć podręczna strony

Pamięć podręczna strony polega na zapisywaniu gotowych stron i podawaniu ich odwiedzającym bez budowania każdej od nowa. Test szuka włączonej wtyczki tego rodzaju, a dodatkowo trzykrotnie pobiera stronę główną i sprawdza nagłówki odpowiedzi oraz czas reakcji serwera. Najgorszy z możliwych wyników to „Pamięć podręczna strony nie jest wykrywana i czas odpowiedzi serwera jest powolny”.

Ten wynik wymaga działania. Rozwiązaniem jest włączenie pamięci podręcznej w panelu hostingu, jeśli dostawca ją oferuje, albo instalacja jednej sprawdzonej wtyczki. Nigdy dwóch naraz, bo wzajemnie sobie przeszkadzają. Po włączeniu trzeba sprawdzić formularz, koszyk i strony dostępne po zalogowaniu, bo to one najczęściej cierpią na źle ustawionej pamięci podręcznej.

Jeśli pamięć została wykryta, a serwer nadal odpowiada wolno, przyczyna leży głębiej: w ciężkich wtyczkach, w motywie albo w słabym serwerze. Sposób szukania opisałem w tekście o tym, co spowalnia WordPressa.

„Powinieneś używać trwałej pamięci podręcznej obiektów”

Trwała pamięć podręczna obiektów odciąża bazę danych, ponieważ WordPress szybciej pobiera zawartość i ustawienia. Narzędzie zaleca ją dopiero wtedy, gdy uzna, że strona jest na to wystarczająco duża. Na małej stronie firmowej ta pozycja zwykle w ogóle się nie pojawia.

Tego zalecenia nie wdraża się samą wtyczką. Potrzebna jest usługa po stronie serwera, najczęściej Redis lub Memcached, i to hosting odpowiada na pytanie, czy jest dostępna w danym pakiecie. Jeśli jest, włącza się ją w panelu hostingu i łączy ze stroną wtyczką wskazaną przez dostawcę. Jeśli jej nie ma, pozycja po prostu zostaje na liście.

„Automatycznie wczytywane opcje mogą mieć wpływ na wydajność”

Opcje wczytywane automatycznie to ustawienia wtyczek i motywów ładowane przy każdym otwarciu strony. Gdy jest ich zbyt dużo, często za sprawą dawno usuniętych wtyczek, strona zwalnia. Porządkowanie polega na usuwaniu wpisów z bazy danych, a pomyłka potrafi rozregulować działającą wtyczkę.

Uważam, że to zadanie dla osoby, która zna strukturę bazy WordPressa. Bezpieczna droga to kopia bazy, ustalenie, które wpisy należą do nieużywanych już wtyczek, i usunięcie wyłącznie tych.

Karta „Informacja”, zgłoszenie do hostingu i kontrola wyniku: jak domknąć pracę?

Karta „Informacja” niczego nie ocenia i niczego nie pozwala zmienić. Pokazuje konfigurację w rozwijanych sekcjach: „WordPress”, „Foldery i rozmiary”, „Aktualnie używany motyw”, „Wtyczki wyłączone”, „Obsługa mediów”, „Serwer”, „Baza danych”, „Stałe WordPressa” i „Uprawnienia systemu plików”. Kilka z nich przydaje się częściej niż pozostałe.

• „Serwer”: wersja PHP, limit pamięci, maksymalny rozmiar wysyłanego pliku i limit czasu wykonywania. To pierwsze miejsce, do którego zagląda się przy błędach wgrywania plików.
• „Foldery i rozmiary”: ile miejsca zajmują pliki, wtyczki, motywy i baza danych. Pomaga ocenić, czy zbliża się limit pakietu hostingowego.
• „Uprawnienia systemu plików”: czy WordPress może zapisywać w swoich katalogach. Brak zapisu tłumaczy nieudane aktualizacje.
• „Stałe WordPressa”: między innymi stan debugowania i rodzaj środowiska.

Jak przygotować zgłoszenie, które hosting załatwi od ręki?

Nad sekcjami znajduje się przycisk „Skopiuj informacje o witrynie do schowka”. Kopiuje on całą konfigurację w postaci tekstu, który można wkleić do wiadomości. Dobre zgłoszenie składa się z trzech części: dosłownej treści komunikatu z karty „Status”, opisu tego, co już sprawdzono, oraz wklejonych informacji o witrynie.

Przykładowa treść: Narzędzie Stan witryny w WordPressie zgłasza dla domeny [adres] komunikat: [dosłowna treść]. Wtyczka bezpieczeństwa została na czas próby wyłączona, komunikat pozostał. Proszę o sprawdzenie konfiguracji serwera. Poniżej wklejam informacje o witrynie.

Skopiowany tekst zawiera szczegóły techniczne: ścieżki katalogów, listę wtyczek z wersjami, parametry serwera. WordPress pomija w nim dane oznaczone jako poufne, mimo to nie należy wklejać go na publicznych forach ani w grupach dyskusyjnych bez przejrzenia. Do pomocy technicznej hostingu i do zaufanego wykonawcy można go wysłać w całości.

Po czym poznać, że naprawa zadziałała?

Po każdej poprawce należy wrócić do „Narzędzia”, „Stan witryny” i odświeżyć ekran. Testy wykonują się od nowa przy każdym wejściu. Naprawiona pozycja znika z listy błędów lub usprawnień i pojawia się po rozwinięciu przycisku „Testy zaliczone”. Zmieniają się też liczniki, a przy braku poważnych uwag wskaźnik pokazuje „Dobre”.

Drugim, ważniejszym sprawdzianem jest sama strona. Trzeba otworzyć ją w oknie prywatnym przeglądarki, przejść przez najważniejsze podstrony, wysłać próbne zapytanie z formularza i, w sklepie, złożyć próbne zamówienie.

Co zrobić, gdy komunikat nie znika?

Najczęstszy powód to pamięć podręczna. Po zmianie należy wyczyścić pamięć podręczną wtyczki i serwera, odczekać kilka minut i odświeżyć ekran narzędzia. Drugi powód to zmiana wprowadzona w złym miejscu, na przykład wersja PHP przestawiona dla innej domeny albo poprawka w kopii pliku zamiast w pliku używanym przez stronę.

Gdy i to nie pomaga, rozwinięty opis trzeba przeczytać ponownie, słowo po słowie. Często okazuje się, że komunikat ma dwa warunki, a spełniony został jeden. Na końcu pozostaje hosting: opis w panelu sam podpowiada przy części testów, że jeśli ostrzeżenie widać mimo wykonania zaleconych czynności, potrzebna jest pomoc dostawcy usług hostingowych.

Jakich błędów unikać przy wdrażaniu zaleceń?

• Aktualizowanie wszystkiego jednym kliknięciem, bez kopii i bez sprawdzania strony po drodze.
• Usuwanie wtyczek tylko dlatego, że są wyłączone, bez ustalenia, czy nie przechowują potrzebnych danych.
• Instalowanie kilku wtyczek pamięci podręcznej lub kilku wtyczek bezpieczeństwa jednocześnie.
• Ukrywanie zaleceń dodatkiem, który wyłącza wybrane testy. Lista staje się krótsza, a przyczyna zostaje.
• Edytowanie pliku wp-config.php bez kopii oraz zmienianie adresów strony na https przed instalacją certyfikatu.
• Traktowanie wyniku „Dobre” jak pełnego przeglądu bezpieczeństwa i rezygnacja z kopii zapasowych oraz mocnych haseł.

Najczęstsze pytania

Jak często należy zaglądać do narzędzia „Stan witryny”?

Rozsądny rytm to raz w miesiącu oraz po każdej większej zmianie: aktualizacji WordPressa, zmianie motywu, przenosinach na inny hosting. WordPress wykonuje testy także samodzielnie i pokazuje skrót wyniku w kokpicie, ale pełną listę z opisami widać dopiero na ekranie narzędzia.

Czy wynik narzędzia wpływa na pozycję strony w Google?

Bezpośrednio nie, ponieważ wyszukiwarka nie widzi tego ekranu. Pośredni związek istnieje: brak połączenia szyfrowanego, wolna odpowiedź serwera czy awarie po zaniedbanych aktualizacjach to sprawy, które odbijają się na odbiorze strony przez odwiedzających i roboty.

Dlaczego na liście są zalecenia, których nie da się wykonać w kokpicie?

Narzędzie sprawdza również serwer: wersję PHP, moduły, bazę danych, połączenia wychodzące. Te elementy należą do firmy hostingowej, dlatego zmienia się je w jej panelu albo przez zgłoszenie do pomocy technicznej, a WordPress może jedynie wskazać problem.

Czy można wyłączyć pojedynczy test, który nie pasuje do danej strony?

Technicznie jest to możliwe za pomocą kodu lub dodatków, ale odradzam takie rozwiązanie na co dzień. Ukryty test nie ostrzeże, gdy sytuacja się zmieni. Lepiej zostawić pozycję na liście i zapisać w notatkach, dlaczego została świadomie pominięta.

Co oznacza komunikat „Brak nagłówka autoryzacji”?

Nagłówek autoryzacji jest używany przez zewnętrzne aplikacje zatwierdzone w witrynie. Jeśli serwer go usuwa, takie aplikacje nie połączą się ze stroną. W opisie testu WordPress proponuje odświeżenie reguł adresów przez ponowne zapisanie bezpośrednich odnośników, a gdy to nie pomaga, sprawę przejmuje hosting.

Czy narzędzie zastępuje wtyczkę bezpieczeństwa i kopie zapasowe?

Nie. Narzędzie ocenia ustawienia, a nie chroni strony w czasie rzeczywistym i nie przechowuje jej kopii. Kopie zapasowe, mocne hasła i aktualizacje pozostają osobnymi obowiązkami, niezależnie od koloru wskaźnika.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Prowadzenie firmy zajmuje dość czasu, a lista technicznych komunikatów nie każdemu poprawia humor. Mogę zająć się tym od początku do końca: wykonam kopię zapasową, przejdę przez wszystkie zalecenia z ekranu „Stan witryny”, wprowadzę poprawki po kolei, sprawdzę po każdej z nich, czy strona działa, uzgodnię z hostingiem sprawy serwera i na koniec przekażę krótkie podsumowanie prostym językiem: co zostało zrobione, a co świadomie pozostawiono.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, od czego zacznę i ile to potrwa.