WordPress pokazuje błąd krytyczny, panel przestał działać, strona ładuje się kilka sekund albo po aktualizacji nie działa formularz? Najgorszym sposobem naprawy jest losowe wyłączanie wtyczek i zmienianie ustawień bez ustalenia rzeczywistej przyczyny problemu.
Przy naprawie WordPressa najpierw zbieram informacje: co dokładnie przestało działać, kiedy pojawił się problem, jaki komunikat zwraca serwer i który element strony zachowuje się inaczej niż wcześniej.
Dopiero później dobieram odpowiednie narzędzie. Inaczej diagnozuję błąd PHP, inaczej konflikt JavaScript, przeciążoną bazę danych, awarię po aktualizacji czy problem występujący wyłącznie w WooCommerce.
Jeśli problem wymaga już technicznej ingerencji, zajmuję się również naprawą błędów WordPress i WooCommerce , ale poniższe narzędzia pokazują, jak sam proces diagnostyki powinien wyglądać.
Site Health – szybki przegląd środowiska WordPressa i serwera.
Recovery Mode – dostęp po części błędów krytycznych.
WP_DEBUG i debug.log – informacje o błędach PHP i WordPressa.
Query Monitor – zapytania SQL, PHP, hooki, HTTP API i wydajność.
Troubleshooting Mode – szukanie konfliktów wtyczek i motywu.
DevTools – błędy JavaScript, Network i problemy frontendu.
SFTP, WP-CLI i baza – pomoc, gdy panel WordPressa przestaje wystarczać.
Logi serwera i staging – diagnoza bardziej złożonych awarii bez zgadywania.
Najpierw diagnoza, później naprawa
Ten sam objaw może mieć kilka zupełnie różnych przyczyn.
Przykład:
możliwa przyczyna A: ciężkie zapytanie do bazy
możliwa przyczyna B: zewnętrzne API nie odpowiada
możliwa przyczyna C: PHP dobija do limitu CPU
możliwa przyczyna D: wtyczka wykonuje tysiące niepotrzebnych operacji
Dokładanie kolejnego pluginu cache bez diagnozy może więc niczego nie zmienić.
Narzędzia mają przede wszystkim odpowiedzieć: gdzie dokładnie powstaje problem?
Site Health – pierwsze miejsce, które sprawdzam w panelu
Wbudowana diagnostyka WordPressa bez instalowania dodatkowego pluginu.
WordPress posiada własny ekran diagnostyczny dostępny z poziomu panelu administratora.
↓
Stan witryny
W zależności od wersji językowej nazwy mogą się nieznacznie różnić, ale znajdę tam dwie szczególnie przydatne części: status witryny oraz informacje techniczne.
Mogę sprawdzić między innymi:
- wersję WordPressa,
- aktywny motyw,
- aktywne i nieaktywne wtyczki,
- wersję PHP,
- informacje o serwerze,
- konfigurację bazy danych,
- stałe WordPressa,
- uprawnienia systemu plików,
- problemy z HTTPS,
- loopback requests i wybrane testy techniczne.
Kiedy Site Health jest najbardziej przydatny?
Gdy chcę szybko ustalić, na jakim środowisku działa strona i czy WordPress sam wykrywa oczywisty problem.
Szczególnie przy przejęciu serwisu od innego wykonawcy pozwala mi w kilka minut zobaczyć podstawową konfigurację bez przeklikiwania całego hostingu.
Site Health sprawdza określony zestaw problemów. Nie znajdzie automatycznie każdego konfliktu JavaScript, błędu biznesowego w WooCommerce czy wolnego zapytania SQL.
Recovery Mode – gdy WordPress wykryje błąd krytyczny
Wbudowany tryb odzyskiwania może pomóc ponownie dostać się do panelu.
Jeśli wtyczka, motyw albo własny kod spowoduje fatalny błąd PHP, WordPress może uruchomić Recovery Mode.
Administrator może wtedy otrzymać wiadomość e-mail z informacją o problemie oraz specjalnym linkiem logowania.
Po wejściu w tryb odzyskiwania WordPress może wskazać komponent odpowiedzialny za awarię i pozwolić dostać się do panelu mimo problemu.
↓
fatal error
↓
komunikat o błędzie krytycznym
↓
e-mail Recovery Mode
↓
diagnoza problematycznej wtyczki
Nie dostałem wiadomości Recovery Mode – co wtedy?
Brak wiadomości nie oznacza, że nie da się naprawić strony.
Wtedy przechodzę do innych metod:
- logów PHP,
- WP_DEBUG,
- SFTP lub menedżera plików,
- WP-CLI,
- panelu hostingu.
WP_DEBUG i debug.log – podstawowe narzędzie przy błędach PHP
Zamiast zgadywać, sprawdzam komunikat generowany przez aplikację.
WordPress posiada wbudowany system debugowania, który można kontrolować w pliku:
wp-config.phpTypowa konfiguracja diagnostyczna wygląda tak:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Przy standardowej konfiguracji log mogę następnie znaleźć w:
/wp-content/debug.logDzięki temu zamiast komunikatu:
mogę zobaczyć informację wskazującą konkretny plik, funkcję oraz numer linii, w której wystąpił fatal error.
Nie wyświetlam błędów PHP publicznie
Na publicznej stronie wolę zapisywać błędy do logu, zamiast pokazywać je klientom w przeglądarce.
Dlatego wykorzystuję:
define( 'WP_DEBUG_DISPLAY', false );Po zakończeniu diagnostyki tryb debugowania wyłączam, a pozostawiony plik logu kontroluję lub usuwam, jeśli nie jest już potrzebny.
Nie traktuję pliku debug.log jak stałego raportu, który powinien rosnąć miesiącami na produkcyjnej stronie.
Przy problemach JavaScript przydaje się SCRIPT_DEBUG
Podczas diagnostyki skryptów WordPressa mogę tymczasowo użyć:
define( 'SCRIPT_DEBUG', true );WordPress może wtedy korzystać z developerskich, nieskompresowanych wersji części własnych plików JS i CSS, co ułatwia analizowanie problemów.
Nie jest to ustawienie, które zostawiam bez potrzeby na stronie produkcyjnej.
Query Monitor – jedno z najbardziej użytecznych narzędzi diagnostycznych
Przy problemach z wydajnością i kodem często pozwala bardzo szybko zawęzić źródło.
Query Monitor jest wtyczką stworzoną właśnie do diagnostyki WordPressa.
Po instalacji mogę analizować m.in.:
- zapytania do bazy danych,
- czas wykonywania zapytań,
- duplikowane zapytania,
- błędy i ostrzeżenia PHP,
- hooki i akcje,
- załadowane pliki PHP,
- skrypty i style,
- wywołania HTTP API,
- żądania AJAX i REST API,
- informacje o aktualnym request.
Przykład: strona produktu ładuje się 8 sekund
Bez diagnostyki mogę tylko podejrzewać hosting.
Query Monitor może jednak pokazać, że jedna konkretna wtyczka wykonuje serię kosztownych zapytań do bazy.
↓
Query Monitor
↓
grupa wolnych zapytań
↓
wszystkie prowadzą do jednego pluginu
↓
mam konkretny obszar do naprawy
To zdecydowanie lepszy punkt wyjścia niż migracja serwisu na droższy hosting bez sprawdzenia przyczyny.
A co z SAVEQUERIES?
WordPress posiada także stałą:
define( 'SAVEQUERIES', true );która pozwala zapisywać informacje dotyczące zapytań SQL.
Korzystam z niej tylko wtedy, gdy rzeczywiście jest potrzebna, ponieważ zbieranie takich danych ma wpływ na wydajność.
Troubleshooting Mode – znajdź konflikt bez wyłączania strony klientom
Bardzo przydatny przy podejrzeniu wtyczki albo motywu.
Jednym z klasycznych testów WordPressa jest:
↓
włącz domyślny motyw
↓
sprawdź, czy problem nadal występuje
↓
aktywuj elementy pojedynczo
Problem? Na stronie produkcyjnej wyłączenie całego zestawu pluginów może zatrzymać formularze, sklep albo inne kluczowe funkcje.
Tryb Troubleshooting pozwala wykonywać taki test w kontrolowanej sesji administratora, podczas gdy zwykli użytkownicy nadal widzą normalną stronę.
Jak wykorzystuję ten test?
Załóżmy, że formularz przestał działać po aktualizacji.
↓
podstawowy motyw + minimum pluginów
↓
formularz zaczyna działać
↓
aktywuję kolejne rozszerzenia
↓
po aktywacji konkretnego pluginu problem wraca
W ten sposób mam dużo mocniejszy dowód na konflikt niż samo podejrzenie.
Troubleshooting Mode pomaga przy izolowaniu konfliktów, ale nie oznacza, że każdą zmianę konfiguracji sklepu wykonuję bezpośrednio na działającej produkcji.
DevTools – gdy WordPress „działa”, ale nie działa frontend
F12 w przeglądarce potrafi powiedzieć więcej niż panel WordPressa.
Jeśli strona się otwiera, ale:
- menu mobilne nie reaguje,
- popup się nie otwiera,
- przycisk nie działa,
- koszyk nie aktualizuje się,
- Elementor przestaje reagować,
- formularz nie wysyła danych,
bardzo często zaczynam od narzędzi developerskich przeglądarki.
Console – błędy JavaScript
Zakładka Console może pokazać np.:
Uncaught TypeError
ReferenceError
Failed to load resource
CORS policy errorWażna jest nie tylko treść komunikatu, ale również nazwa pliku, z którego pochodzi błąd.
Network – co faktycznie pobiera przeglądarka?
Zakładka Network pomaga mi sprawdzić:
- kody 404 dla plików,
- błędy 403 i 500,
- wolne żądania,
- problemy AJAX,
- REST API,
- czas odpowiedzi serwera,
- przekierowania,
- problemy z zasobami zewnętrznymi.
Jeśli kliknięcie „Dodaj do koszyka” wysyła request, który kończy się kodem 500, problem wygląda już zupełnie inaczej niż wtedy, gdy kliknięcie w ogóle nie uruchamia żadnego żądania.
SFTP i menedżer plików – kiedy nie da się wejść do wp-admin
Panel WordPressa nie jest jedynym sposobem dostania się do strony.
Jeśli błędna wtyczka blokuje cały WordPress, mogę nie mieć możliwości wejścia do panelu i kliknięcia „Dezaktywuj”.
Wtedy przydaje się:
- SFTP,
- SSH,
- menedżer plików w panelu hostingu.
Jeśli log wskazuje konkretny plugin, jego katalog znajdę zazwyczaj w:
/wp-content/plugins/nazwa-wtyczki/Tymczasowa zmiana nazwy katalogu może sprawić, że WordPress nie załaduje problematycznej wtyczki podczas kolejnego requestu.
Najpierw sprawdzam log i próbuję zawęzić problem. Szczególnie w WooCommerce masowe wyłączanie rozszerzeń bez planu może stworzyć dodatkowe komplikacje.
WP-CLI – WordPress z poziomu terminala
Przy dostępie SSH wiele czynności wykonuję bez otwierania panelu.
WP-CLI jest szczególnie przydatne, gdy panel działa wolno albo nie działa w ogóle.
Mogę przykładowo sprawdzić zainstalowane pluginy:
wp plugin listwyłączyć problematyczną wtyczkę:
wp plugin deactivate nazwa-wtyczkisprawdzić bazę:
wp db checkalbo zweryfikować pliki WordPressa:
wp core verify-checksumsChecksums są szczególnie przydatne przy podejrzeniu zmienionych plików
Polecenie:
wp core verify-checksumsporównuje pliki rdzenia z sumami kontrolnymi odpowiadającymi danej wersji WordPressa.
Można również sprawdzać część wtyczek pochodzących z repozytorium WordPress.org:
wp plugin verify-checksums --allTrzeba pamiętać, że brak dostępnych checksums dla własnego lub komercyjnego pluginu nie oznacza automatycznie infekcji.
WP-CLI nie jest narzędziem tylko do naprawy
Używam go również do:
- aktualizacji,
- eksportu i importu bazy,
- wyszukiwania i zamiany danych,
- zarządzania użytkownikami,
- kontroli cronów,
- automatyzacji powtarzalnych prac.
Przy poleceniach modyfikujących dane zawsze upewniam się, że wiem dokładnie, na jakiej instalacji je uruchamiam.
phpMyAdmin lub Adminer – kiedy problem znajduje się w bazie danych
WordPress przechowuje ogromną część swojej konfiguracji poza plikami.
Dostęp do bazy jest szczególnie przydatny, gdy problem dotyczy:
- uszkodzonych tabel,
- nieprawidłowego adresu strony,
- ogromnej tabeli options,
- danych pozostawionych przez stare wtyczki,
- sesji WooCommerce,
- problemów po migracji,
- błędnego importu.
phpMyAdmin albo Adminer pozwala podejrzeć strukturę, rekordy, rozmiary tabel i wykonywać zapytania SQL.
Przed operacją DELETE, UPDATE, DROP albo masową zmianą wykonuję eksport lub inną sprawdzoną kopię bazy. Jedna błędna instrukcja SQL może usunąć więcej danych, niż zakładałem.
Logi PHP, serwera i hostingu – gdy WordPress pokazuje tylko skutek
Nie wszystkie błędy powstają na poziomie samego CMS-a.
WordPress może pokazać błąd, którego rzeczywista przyczyna znajduje się głębiej w środowisku serwera.
W panelu hostingu albo przez SSH szukam m.in.:
- PHP error log,
- logów serwera WWW,
- kodów 500, 502, 503 i 504,
- przekroczeń memory_limit,
- timeoutów,
- błędów procesu PHP-FPM,
- limitów workerów,
- problemów z MySQL,
- informacji o CPU, RAM i I/O.
Przykład: server reached max_children
Taki komunikat nie mówi mi, że WordPress potrzebuje kolejnego pluginu optymalizacyjnego.
Informuje, że pula procesów PHP osiągnęła skonfigurowany limit.
Kolejne pytanie brzmi więc:
czy
WordPress generuje niepotrzebnie dużo ciężkich requestów?
Dopiero odpowiedź na to pytanie prowadzi do właściwej naprawy.
Staging i backup to również narzędzia do naprawy WordPressa
Nie służą bezpośrednio do znalezienia fatal error, ale pozwalają diagnozować bez ryzykowania danych klientów.
Na kopii testowej mogę bezpieczniej:
- aktualizować pluginy,
- zmieniać PHP,
- przełączać motywy,
- wyłączać rozszerzenia,
- testować poprawki kodu,
- uruchamiać narzędzia diagnostyczne,
- porównywać zachowanie przed i po zmianie.
Jest to szczególnie ważne przy sklepie, gdzie błędny test może wpłynąć na koszyk, płatności lub nowe zamówienia.
Jakie narzędzie wybrać do konkretnego błędu WordPress?
| Problem | Narzędzie, od którego często zaczynam |
|---|---|
| Wystąpił krytyczny błąd | Recovery Mode + debug.log + log PHP |
| Biały ekran | WP_DEBUG + log PHP + SFTP |
| Strona działa bardzo wolno | Query Monitor + logi i monitoring hostingu |
| Przycisk albo menu nie działa | DevTools → Console i Network |
| Problem po instalacji pluginu | Troubleshooting Mode |
| Brak dostępu do wp-admin | SFTP / WP-CLI / Recovery Mode |
| Błąd połączenia z bazą | wp-config.php + wp db check + narzędzie bazy |
| Podejrzenie zmodyfikowanych plików core | wp core verify-checksums |
| 500 / 502 / 504 | Logi serwera + PHP + monitoring zasobów |
| Problem tylko po aktualizacji | Staging + logi + test konfliktów |
Jak diagnozuję awarię WordPress krok po kroku?
Odtwarzam problem
Sprawdzam dokładnie, co trzeba zrobić, aby błąd wystąpił ponownie.
Ustalam, co zmieniło się wcześniej
Aktualizacja, nowy plugin, migracja, zmiana PHP czy nagły wzrost ruchu często mocno zawężają przyczynę.
Sprawdzam logi
Szukam błędu PHP, komunikatu serwera, odpowiedzi AJAX albo innego konkretnego śladu.
Izoluję problem
Sprawdzam, czy winny jest plugin, motyw, serwer, baza czy kod frontendu.
Testuję poprawkę na kopii
Przy istotnej zmianie wolę najpierw potwierdzić rozwiązanie na stagingu.
Wdrażam minimalną potrzebną zmianę
Nie zmieniam pięciu rzeczy równocześnie, jeśli chcę później wiedzieć, co naprawiło problem.
Powtarzam test
Sprawdzam tę samą ścieżkę, która wcześniej powodowała błąd.
Kontroluję efekty uboczne
Testuję formularze, wersję mobilną, logowanie, koszyk i inne funkcje zależne od zmiany.
Czego nie robię podczas naprawy WordPressa?
- Nie aktualizuję wszystkiego jednocześnie bez backupu.
- Nie usuwam pluginu tylko dlatego, że pojawia się w jednym logu.
- Nie wklejam losowych snippetów znalezionych na forum.
- Nie edytuję bezpośrednio bazy bez zabezpieczenia danych.
- Nie pokazuję publicznie komunikatów debugowania.
- Nie zostawiam SAVEQUERIES włączonego bez potrzeby.
- Nie diagnozuję problemu wyłącznie poprzez wyczyszczenie cache.
- Nie zakładam automatycznie, że winny jest hosting.
- Nie zakładam automatycznie, że winna jest wtyczka.
- Nie testuję ryzykownych zmian na żywym sklepie, jeśli mogę użyć stagingu.
„Wyczyść cache” nie jest uniwersalnym narzędziem naprawczym
Cache rzeczywiście potrafi powodować sytuację, w której widzę starą wersję pliku, CSS albo strony.
Ale nie naprawi:
- fatal error PHP,
- uszkodzonej bazy,
- błędu SQL,
- niezgodnej wersji PHP,
- problemu z uprawnieniami plików,
- przeciążonego procesu PHP-FPM.
Czyszczenie cache jest testem, nie diagnozą całego WordPressa.
Czy narzędzia diagnostyczne można uruchamiać na stronie produkcyjnej?
Zależy od narzędzia i problemu.
Site Health, logi, DevTools czy odczyt części danych mogą być wykorzystane bez modyfikowania strony.
Aktualizacja PHP, masowe wyłączanie pluginów, zapytania SQL czy zmiana kodu wymagają większej kontroli.
Oficjalna dokumentacja WordPressa również rekomenduje, aby narzędzia debugowania i bardziej zaawansowane testy wykorzystywać przede wszystkim w środowisku developerskim lub stagingowym.
Kiedy przestaję szukać „szybkiego fixa” i analizuję całą stronę?
Czasami pojedynczy błąd jest tylko objawem starszego problemu.
Przykładowo strona może mieć jednocześnie:
- nieaktualny motyw,
- kilkanaście nieużywanych pluginów,
- stare PHP,
- ogromną bazę danych,
- customowy kod bez dokumentacji,
- problemy z cronem,
- brak regularnych backupów.
Przy takich instalacjach pojedyncza naprawa może przywrócić działanie, ale kolejny problem pojawi się za kilka tygodni.
W takim przypadku sensowniejsze bywa uporządkowanie lub przebudowanie istniejącej strony zamiast ciągłego gaszenia kolejnych awarii.
Przy regularnie rozwijanej stronie warto mieć stałe wsparcie techniczne
Sklep albo rozbudowana strona zmienia się regularnie: dochodzą nowe pluginy, integracje, aktualizacje WordPressa, zmiany PHP i kolejne funkcje.
Dlatego przy serwisach, które wymagają systematycznej opieki, oferuję również wsparcie techniczne WordPress i WooCommerce .
Dzięki temu problem można diagnozować w kontekście całego serwisu, a nie dopiero wtedy, gdy strona całkowicie przestanie działać.
Chcesz naprawiać WordPress samodzielnie? Zacznij od nauki diagnozy
Najważniejszą umiejętnością nie jest znajomość stu gotowych snippetów.
Dużo bardziej przydaje się umiejętność ustalenia:
↓
co go wywołuje
↓
jak go odtworzyć
↓
jak potwierdzić poprawkę
Jeśli chcesz przeanalizować konkretny problem razem ze mną, ale późniejsze działania wykonywać samodzielnie, odpowiednią opcją może być konsultacja WordPress i WooCommerce .
WordPress daje dużo możliwości diagnostycznych – trzeba tylko wiedzieć, gdzie patrzeć
Na stronynazlecenie.pl pracuję zarówno przy tworzeniu nowych stron, jak i przy istniejących WordPressach, dlatego diagnostyka jest stałą częścią mojej pracy.
Błąd nie zawsze wymaga przebudowy całej strony. Czasem wystarczy jedna konkretna poprawka. Kluczowe jest jednak to, żeby najpierw potwierdzić przyczynę, zamiast modyfikować witrynę metodą prób i błędów.
Moja checklista narzędzi przed naprawą WordPressa
- Sprawdzam Site Health i informacje o środowisku.
- Kontroluję, czy WordPress uruchomił Recovery Mode.
- Włączam WP_DEBUG_LOG, jeśli potrzebuję logu WordPressa.
- Nie pokazuję błędów PHP publicznym użytkownikom.
- Przeglądam PHP error log hostingu.
- Przy wolnej stronie wykorzystuję Query Monitor.
- Przy konflikcie pluginów korzystam z kontrolowanego testu.
- Przy błędzie frontendu otwieram Console i Network.
- Mam dostęp SFTP, SSH albo do menedżera plików.
- Przy dostępie SSH wykorzystuję WP-CLI.
- Przy problemach z core mogę zweryfikować checksums.
- Przy problemach bazodanowych sprawdzam bazę i jej logi.
- Przed zmianami SQL tworzę kopię.
- Ryzykowne poprawki testuję na stagingu.
- Po naprawie powtarzam dokładnie scenariusz powodujący błąd.
- Sprawdzam, czy poprawka nie zepsuła innych funkcji.
Masz błąd WordPressa i nie wiesz, od czego zacząć?
Mogę sprawdzić logi PHP, debug.log, wtyczki, motyw, bazę danych, zapytania, serwer i frontend, a następnie ustalić rzeczywistą przyczynę problemu. Zamiast instalować kolejne „naprawiacze”, diagnozuję konkretny element i dobieram rozwiązanie do Twojej strony lub sklepu WooCommerce.
Narzędzia do naprawy WordPress – najczęstsze pytania
Jakie narzędzia warto znać do naprawy WordPressa?
Najczęściej wykorzystuję Site Health, Recovery Mode, WP_DEBUG i debug.log, Query Monitor, Troubleshooting Mode, narzędzia developerskie przeglądarki, SFTP lub SSH, WP-CLI, narzędzia do obsługi bazy oraz logi serwera. Dobór zależy od rodzaju problemu.
Gdzie sprawdzić błędy WordPressa?
Przy błędach PHP mogę wykorzystać debug.log WordPressa oraz log PHP udostępniany przez hosting. Przy problemach JavaScript sprawdzam konsolę przeglądarki, a przy problemach serwera również jego logi i monitoring.
Do czego służy WP_DEBUG?
WP_DEBUG włącza tryb debugowania WordPressa. W połączeniu z WP_DEBUG_LOG może zapisywać błędy, ostrzeżenia i notice do pliku debug.log, co pomaga ustalić, który fragment kodu powoduje problem.
Do czego służy Query Monitor?
Query Monitor pomaga analizować między innymi zapytania do bazy, błędy PHP, hooki, skrypty, style, wywołania HTTP API oraz część żądań AJAX i REST API. Jest szczególnie przydatny przy diagnostyce wydajności i konfliktów kodu.
Jak znaleźć wtyczkę powodującą błąd WordPress?
Najpierw sprawdzam log błędu, a następnie mogę wykorzystać kontrolowany tryb diagnostyczny, w którym pluginy są wyłączane dla mojej sesji. Włączając je kolejno, można sprawdzić, po aktywacji którego elementu problem wraca.
Co zrobić, gdy nie mogę wejść do panelu WordPress?
Mogę wykorzystać Recovery Mode, SFTP, menedżer plików hostingu albo WP-CLI. Jeśli problem powoduje konkretny plugin, można go tymczasowo wyłączyć bez logowania do standardowego panelu administratora.
Czy WP-CLI pomaga w naprawie WordPressa?
Tak. WP-CLI pozwala między innymi sprawdzać i dezaktywować wtyczki, analizować bazę, wykonywać zadania administracyjne oraz weryfikować pliki rdzenia WordPressa przy użyciu sum kontrolnych.
Czy Query Monitor powinien działać cały czas na stronie?
Traktuję go przede wszystkim jako narzędzie diagnostyczne. Przy analizie strony produkcyjnej używam go świadomie, a bardziej zaawansowane i obciążające testy preferuję wykonywać na środowisku stagingowym.
Czy można naprawiać WordPress bez kopii zapasowej?
Przy samym odczycie logów backup nie zawsze jest potrzebny, ale przed zmianami w bazie, aktualizacją kluczowych komponentów, edycją kodu lub innymi ryzykownymi operacjami zabezpieczam dane w sposób odpowiedni do danej strony.
Czy czyszczenie cache naprawia błędy WordPress?
Tylko niektóre. Cache może powodować wyświetlanie starej wersji strony lub zasobów, ale nie naprawi fatal error PHP, uszkodzonej bazy, błędnego kodu ani przeciążonego serwera. Jest jednym z testów, a nie uniwersalnym rozwiązaniem.
