Biała strona WordPress to jeden z najbardziej frustrujących problemów, jakie mogą przytrafić się właścicielowi strony. Zamiast Twojej witryny widzisz pustkę – biały ekran bez komunikatu błędu, bez wskazówki, co zawiodło. Dla odwiedzających oznacza to brak treści, dla Ciebie – panikę, bo nie wiesz, od czego zacząć. Dobra wiadomość? To da się stosunkowo szybko zdiagnozować i naprawić. W tym przewodniku przeprowadzę Cię krok po kroku przez najbardziej skuteczne metody, bazując na praktycznych doświadczeniach z dziesiątkami napraw podobnych awarii.
Co to za problem i skąd się bierze?
Biała strona zwykle oznacza krytyczny błąd PHP lub brak zasobów, ale przyczyn może być kilka: wtyczki, motyw, pamięć, .htaccess, wersja PHP, cache lub nawet uszkodzone pliki.
Wyświetlenie pustego ekranu bez błędu (często nazywane White Screen of Death) najczęściej wynika z:
- błędu krytycznego w kodzie (PHP fatal error),
- wyczerpania limitu pamięci,
- konfliktu wtyczek lub motywu,
- niekompatybilnej wersji PHP,
- problemu z plikiem .htaccess,
- błędnych uprawnień plików,
- cachingu na poziomie serwera lub CDN,
- przerwanej aktualizacji i pozostawienia trybu konserwacji,
- w rzadkich przypadkach: problemów z bazą danych lub zainfekowaniem plików.
Najważniejsze: nie działaj chaotycznie. Zacznij od najprostszych testów i prowadź diagnostykę krok po kroku. Każdy etap poniżej pomoże Ci zawęzić źródło problemu i przyspieszy naprawę.
Szybka lista kontrolna (2 minuty)
Jeśli potrzebujesz działać błyskawicznie, wykonaj te szybkie ruchy diagnostyczne, zanim wejdziesz w szczegóły.
- Sprawdź, czy problem występuje tylko na froncie, czy także w panelu wp-admin.
- Wyłącz cache wtyczek (np. W3TC, LiteSpeed Cache, WP Super Cache) oraz ewentualny cache na hostingu/Cloudflare.
- Wejdź w tryb prywatny przeglądarki lub użyj innej przeglądarki/urządzenia.
- Jeśli masz dostęp do FTP/SSH, zmień nazwę folderu wp-content/plugins na plugins.off – jeśli strona wróci, winna jest któraś wtyczka.
- Zmień nazwę katalogu aktualnego motywu (wp-content/themes/nazwamotywu) – jeśli wróci, problemem jest motyw.
- Sprawdź logi błędów PHP, jeśli hosting je udostępnia.
Jeśli po tych krokach pojawi się błąd zamiast białej strony (np. konkretne ostrzeżenie PHP), masz już trop. Jeśli dalej jest pusto, przejdź przez kolejne sekcje.
Najczęstsze przyczyny: biała strona WordPress
Zwykle wygrywają trzy “podejrzane” scenariusze: limit pamięci, wadliwa wtyczka lub motyw, i ukryty błąd PHP bez logów.
- Aktualizacja wtyczki lub motywu, która poszła nie tak.
- Nowo zainstalowana wtyczka konfliktująca z innymi.
- Zbyt mały limit pamięci PHP (np. 64M przy rozbudowanym sklepie WooCommerce).
- Zmiana wersji PHP na serwerze, po której wtyczka/motyw przestaje być kompatybilny.
- Nadpisane lub uszkodzone pliki WordPressa.
- Niepoprawny .htaccess (szczególnie po zmianie struktury linków).
- Zbyt agresywne reguły w wtyczkach bezpieczeństwa lub firewallu.
- Tryb konserwacji zawieszony po przerwanej aktualizacji.
Znając najczęstsze źródła, szybciej dopasujesz działania naprawcze.
Włącz szczegółowe błędy: WP_DEBUG i logi
Najlepszym lekarstwem na “ciszę” jest głośny log – włącz debug, by zobaczyć prawdziwy błąd.
Gdy widzisz pustą stronę, WordPress często ukrywa błędy. Aby je ujawnić:
- Połącz się przez FTP/SSH i edytuj plik wp-config.php. Dodaj lub zmień te linie powyżej “/ To wszystko, zakończ edycję! /”:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // nie wyświetlaj błędów na froncie
@ini_set('display_errors', 0);
- Odśwież stronę. Błędy pojawią się w pliku:
wp-content/debug.log - Otwórz debug.log i poszukaj:
- Fatal error: Allowed memory size…
- Fatal error: Uncaught Error…
- Call to undefined function…
- Parse error: syntax error…
- Jeśli hosting ma osobne logi PHP (np. error_log), pobierz je z panelu hostingu lub z katalogu public_html.
Po zakończeniu napraw wyłącz debug, ustawiając:
define('WP_DEBUG', false);
Wyniki debugowania skrócą ścieżkę naprawy o połowę. Nawet pojedyncza linia potrafi wskazać wtyczkę, plik i numer linii, gdzie zaczyna się problem.
Zwiększ limit pamięci PHP
Biała strona często oznacza, że witrynie zabrakło pamięci – zwiększenie limitu bywa najszybszym “hotfixem”.
Objawy niedoboru pamięci:
- Błąd Allowed memory size of X bytes exhausted… w logu.
- Biała strona pojawiająca się losowo, zwłaszcza przy cięższych operacjach (importy, edycje, generowanie miniatur).
Jak podnieść limit:
- W wp-config.php dodaj (jeśli nie działa, sprawdź niżej):
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // dla panelu admina
- Alternatywnie (zależnie od hostingu):
- w .htaccess:
php_value memory_limit 256M - w php.ini lub user.ini:
memory_limit = 256M
- w .htaccess:
Jeśli hosting ignoruje te ustawienia, ustaw limit w panelu serwera (np. cPanel, Plesk) lub poproś support o zwiększenie. Po zmianie odśwież stronę i sprawdź logi – jeśli znikają błędy pamięci, jesteś na dobrej drodze.
Wyłącz wszystkie wtyczki jednocześnie
Konflikt lub błąd w jednej wtyczce to najczęstszy winowajca – wyłączenie całej paczki pozwala szybko potwierdzić hipotezę.
Kroki:
- Przez FTP/SSH wejdź do wp-content/.
- Zmień nazwę folderu plugins na plugins.off (cokolwiek innego).
- Odśwież stronę – jeśli wróciła, winna jest jakaś wtyczka.
- Przywróć nazwę na plugins, a następnie w katalogu plugins wyłączaj wtyczki pojedynczo, zmieniając nazwę każdego folderu, aż zidentyfikujesz problem.
Pamiętaj, że niektóre wtyczki (np. cache) zostawiają pliki generowane poza wp-content. Po wyłączeniu może być konieczne ręczne usunięcie ich cache (np. w /wp-content/cache/, /lscache/ lub w katalogach hostingu).
Jeśli to wina jednej wtyczki – co dalej?
Ustal przyczynę i podejmij decyzję: aktualizacja, powrót do wcześniejszej wersji, zamiennik albo kontakt z autorem.
- Sprawdź, czy jest dostępna aktualizacja usuwająca błąd.
- Jeśli błąd pojawił się po aktualizacji, wróć do poprzedniej wersji (z repozytorium WordPress.org lub z posiadanej kopii).
- Zmień konfigurację (czasem winne są konkretne ustawienia, np. minifikacja CSS/JS).
- Zastąp wtyczkę inną, mniej konfliktową.
- Zgłoś błąd autorowi – dołącz komunikat z debug.log.
Przywróć domyślny motyw
Motyw może zawierać błąd albo nie być zgodny z obecną wersją PHP – szybki test z motywem Twenty Twenty‑X jest bezcenny.
Kroki:
- W FTP/SSH wejdź do wp-content/themes/.
- Zmień nazwę katalogu aktywnego motywu, np. nazwa-motywu.off.
- WordPress spróbuje przełączyć się na domyślny motyw (np. Twenty Twenty-Four). Jeśli nie masz go zainstalowanego, wgraj folder z repozytorium WordPressa lub użyj WP-CLI:
wp theme install twentytwentyfour --activate
- Jeśli po zmianie motywu strona działa, błąd tkwi w motywie lub w child theme.
Co dalej:
- Zaktualizuj motyw do najnowszej wersji.
- Porównaj pliki functions.php, template-parts, niestandardowe funkcje.
- Przywróć czystą kopię motywu z repo lub backupu.
Odbuduj plik .htaccess
Jedna z częstszych przyczyn na hostingach z Apache – uszkodzony lub nadpisany .htaccess potrafi “wyczyścić” stronę.
- Przez FTP/SSH zlokalizuj .htaccess w katalogu głównym WordPressa.
- Zmień nazwę na .htaccess.bak, by go tymczasowo wyłączyć.
- Sprawdź stronę – jeśli działa, w panelu WP ustaw dowolnie strukturę linków (Ustawienia > Bezpośrednie odnośniki) i zapisz, by wygenerować nowy .htaccess.
- Jeśli nie masz dostępu do panelu, utwórz podstawowy .htaccess ręcznie:
Dla standardowego WordPressa:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>END WordPress
Uwaga: Jeśli używasz wtyczek cache lub bezpieczeństwa, mogą one dodawać własne reguły – po przywróceniu sprawdź ich ustawienia.
Zgodność wersji PHP i rozszerzeń
Nie każda wtyczka nadąża za nowymi wersjami PHP – a czasem to Ty uwięzłeś na zbyt starej.
- Sprawdź w panelu hostingu, jaką wersję PHP ma Twój serwer (7.4, 8.0, 8.1, 8.2, 8.3).
- Upewnij się, że Twój motyw i wtyczki deklarują zgodność z tą wersją.
- Jeśli błąd pojawił się po aktualizacji PHP, rozważ cofnięcie wersji do poprzedniej stabilnej i przetestuj.
- Włącz wymagane rozszerzenia: mysqli, gd, curl, mbstring, intl (zależnie od potrzeb wtyczek).
- Zajrzyj w logi pod kątem komunikatów typu “Call to undefined function …” – często wskazują brakujące rozszerzenie.
Dobrym nawykiem jest testowanie aktualizacji PHP na środowisku staging, a nie na stronie produkcyjnej.
Uprawnienia plików i folderów
Złe uprawnienia blokują ładowanie plików i generują białe ekrany, zwłaszcza po migracjach i ręcznych podmianach.
Zalecane uprawnienia:
- katalogi: 755
- pliki: 644
- wp-config.php czasem 640/600 (w zależności od hostingu)
Przez SSH:
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
Upewnij się, że właścicielem plików jest właściwy użytkownik (na serwerach z suEXEC/suPHP). Jeśli niedawno migrowałeś stronę, poproś support o “naprawę właścicieli” plików.
Problemy z bazą danych – rzadziej, ale dotkliwie
Uszkodzone tabele lub błędny prefix mogą wywołać białą stronę – sprawdź, zanim zaczniesz reinstalować WordPressa.
- Zajrzyj do wp-config.php i sprawdź DB_NAME, DB_USER, DB_PASSWORD, DB_HOST oraz $table_prefix.
- Jeśli masz dostęp do phpMyAdmin:
- użyj opcji Napraw tabelę/Optymalizuj dla podejrzanych tabel,
- sprawdź, czy istnieje tabela wp_options i zapis “siteurl/home”.
- Włącz automatyczną naprawę WordPress:
- w wp-config.php dodaj:
define('WP_ALLOW_REPAIR', true); - odwiedź:
https://twojadomena.pl/wp-admin/maint/repair.php - uruchom naprawę i usuń linię z wp-config po zakończeniu.
- w wp-config.php dodaj:
Jeśli problem zaczął się po imporcie/migracji, zweryfikuj serializowane dane i adresy URL w bazie (Search Replace z narzędziem kompatybilnym z serializacją).
Cache: wtyczki, hosting, CDN/Cloudflare
Biała strona może być tak naprawdę “zatrzaśniętym” starym cachem – wyczyść go na wszystkich warstwach.
- Wtyczki cache (LiteSpeed, W3 Total Cache, WP Rocket, Super Cache):
- Wyczyść cache, wyłącz minifikację, kombajn JS/CSS i lazy-load – sprawdź.
- Cache na serwerze (Varnish, NGINX microcache, LiteSpeed cache na poziomie serwera):
- Wyczyść w panelu hostingu lub poproś support.
- CDN/Cloudflare:
- Użyj opcji Purge Everything,
- wyłącz tryb “Rocket Loader” i minifikację w Cloudflare na czas testów,
- ustaw tryb Development Mode, by ominąć cache.
Po każdej zmianie odśwież stronę w trybie prywatnym lub użyj innej przeglądarki.
Tryb konserwacji i przerwane aktualizacje
Jeśli aktualizacja została przerwana, WordPress może utknąć w trybie konserwacji – to szybka naprawa.
- W katalogu głównym WordPressa sprawdź, czy istnieje plik .maintenance.
- Usuń go i odśwież stronę.
- Upewnij się, że wszystkie aktualizacje doszły do skutku – jeśli nie, uruchom je ponownie.
Czasem biała strona wynika z częściowo zaktualizowanej wtyczki/motywu – porównaj pliki z czystym repozytorium i nadpisz brakujące/uszkodzone.
Biały ekran tylko w panelu wp-admin albo tylko na froncie
Miejsce, gdzie pojawia się biel, podpowiada źródło: front obwinia zwykle motyw/wtyczki frontowe, panel – wtyczki adminsko-edytorskie.
- Tylko wp-admin: podejrzane są wtyczki edytora (Gutenberg/Classic), buildery, wtyczki SEO, bezpieczeństwa, integracje API w panelu.
- Tylko front: motyw, buildery stron (Elementor, Divi), shortcode’y, wtyczki galerii, sliderów.
- Zadziała też metoda “pół na pół”: wyłączasz połowę wtyczek, sprawdzasz; jeśli błąd znika, wiesz, w której połowie szukać – skraca to czas diagnostyki.
Znaki BOM i białe znaki przed PHP
Jedna niewidoczna spacja w złym miejscu potrafi zepsuć całą stronę, szczególnie w plikach PHP i functions.php.
- Sprawdź pliki edytowane ostatnio (functions.php, pliki motywu, wtyczek).
- Upewnij się, że pliki zapisane są w UTF-8 bez BOM.
- Usuń wszelkie spacje/linie przed otwarciem tagu PHP:
<?phporaz po zamknięciu:
?>(w nowoczesnych plikach PHP często nie domyka się tagu “?>”, by uniknąć białych znaków na końcu).
Jeśli biała strona zaczęła się po ręcznej edycji, to bardzo prawdopodobny trop.
Buildery stron i edytor: Gutenberg vs Classic
Rozszerzenia edytora to częsta strefa konfliktów – zbyt agresywna optymalizacja JS/CSS może wyczyścić ekran.
- Jeśli używasz Elementora, Divi, WPBakery – wyłącz na chwilę minifikację i łączenie plików w ustawieniach.
- Przywróć domyślny motyw i sprawdź, czy edytor się ładuje.
- Gdy problem dotyczy samego edytora, wyłącz dodatki rozszerzające Gutenberga (np. bloki premium).
- Sprawdź konsolę JS w przeglądarce (F12) – błędy JS mogą powodować “pusty” interfejs, choć same nie wywołają fatal error PHP.
Logi serwera i limity na hostingu
Gdy WordPress milczy, serwer mówi – logi i limity często zdradzają prawdę.
- Sprawdź error_log w katalogu głównym oraz w folderach wp-admin i wp-includes (czasem hosting umieszcza tam logi).
- W panelu hostingu sprawdź:
- wykorzystanie CPU/RAM,
- limity I/O i inodes,
- dzienniki błędów serwera www.
- Jeśli limity są przekroczone (np. na hostingach współdzielonych), czasem biała strona to po prostu efekt “przydławienia” procesów. Wtedy:
- wyłącz ciężkie wtyczki,
- zwiększ parametry (jeśli plan hostingu pozwala),
- rozważ przeniesienie na wydajniejszy plan lub VPS.
Skan na obecność złośliwego oprogramowania
Infekcje czasem maskują się pod białymi ekranami – skan i porównanie plików potrafi ujawnić nieproszonych gości.
- Użyj skanera (np. Wordfence, MalCare, iThemes Security Pro) – jeśli masz dostęp do panelu.
- Gdy panel jest niedostępny, porównaj pliki WordPressa z czystą paczką tej samej wersji:
- nadpisz wp-admin i wp-includes czystymi plikami z wordpress.org,
- przejrzyj wp-content pod kątem podejrzanych plików .php w katalogach uploadów.
- Sprawdź crony, które mogą się odpalać cyklicznie, i pliki .php o losowych nazwach.
- Zmień hasła do FTP, paneli, bazy; zresetuj klucze uwierzytelniające w wp-config.php (AUTH_KEY itd.).
Jeśli wykryjesz infekcję, rozważ profesjonalne czyszczenie i audyt – to oszczędzi Ci powrotów problemu.
Gdy nic nie działa – przywróć z kopii, ale mądrze
Kopia to koło ratunkowe, ale użyj jej świadomie, by nie nadpisać danych niepotrzebnie i nie zgubić źródła błędu.
- Jeśli masz backup na poziomie hostingu lub wtyczki (UpdraftPlus, Jetpack, BlogVault), przywróć najpierw:
- pliki, bez bazy – by sprawdzić, czy winne były pliki,
- dopiero potem bazę, jeśli to konieczne.
- Zanotuj, co przywracasz i z jakiej daty – aby wiedzieć, jakie aktualizacje cofasz.
- Po przywróceniu włącz debug i dokonaj kontrolowanej aktualizacji krok po kroku, obserwując ewentualny powrót błędu.
Dobra praktyka: utrzymuj środowisko staging i testuj zmiany przed publikacją.
Dodatkowe narzędzia przyspieszające diagnostykę
Kilka trików i narzędzi potrafi skrócić “polowanie” z godzin do minut.
- WP-CLI:
- Dezaktywacja wszystkich wtyczek:
wp plugin deactivate --all - Lista ostatnio aktualizowanych:
wp plugin list --field=name --update=available - Zmiana motywu:
wp theme activate twentytwentyfour
- Dezaktywacja wszystkich wtyczek:
- Health Check & Troubleshooting:
- W trybie diagnostycznym pozwala “wyłączyć” wtyczki i motyw tylko dla Twojej sesji, nie psując witryny dla odwiedzających.
- Query Monitor:
- Gdy już strona działa, pozwala namierzyć powolne zapytania, błędy i ostrzeżenia – przydatne prewencyjnie.
Prewencja: jak zapobiegać podobnym awariom
Dobrze zaplanowane utrzymanie strony minimalizuje ryzyko nagłych “białych ekranów”.
- Staging przed aktualizacjami – zawsze testuj większe zmiany.
- Harmonogram aktualizacji – nie rób wszystkiego naraz, aktualizuj partiami.
- Backup 3-2-1 – trzy kopie, na dwóch różnych nośnikach, jedna poza serwerem.
- Monitorowanie uptime/błędów – narzędzia jak UptimeRobot, Better Uptime, logi błędów.
- Ogranicz liczbę wtyczek – mniej elementów, mniej konfliktów.
- Standardy jakości – motywy i wtyczki tylko z zaufanych źródeł, czytelne changelogi.
- Wersje PHP – aktualizuj rozsądnie, ale nie zwlekaj latami; planuj migracje.
- Dokumentacja zmian – notuj, co było aktualizowane i kiedy, aby szybciej cofnąć się do działającej konfiguracji.
Przykładowy scenariusz naprawy krok po kroku
Modelowy przebieg działań od chwili wykrycia problemu do pełnego rozwiązania – 20–40 minut pracy.
- Włącz WP_DEBUG i przejrzyj wp-content/debug.log.
- Jeśli brak logów, podnieś pamięć do 256–512M.
- Zmień nazwę folderu plugins → jeśli działa, aktywuj wtyczki jedna po drugiej i namierz winowajcę.
- Jeśli to nie wtyczki, przełącz na domyślny motyw.
- Przeładuj .htaccess – usuń, wygeneruj na nowo.
- Sprawdź wersję PHP i rozszerzenia, przetestuj na innej wersji, jeśli masz podejrzenia.
- Wyczyść cache wtyczek, serwera i CDN.
- Sprawdź logi serwera i limity.
- Jeśli dalej nic, porównaj pliki z czystą instalacją WordPressa; nadpisz wp-admin i wp-includes.
- Ostatecznie przywróć działającą kopię i zaplanuj diagnostykę na stagingu.
Ten schemat pokrywa 90% przypadków, w których pomagałem użytkownikom i klientom.
FAQ – krótkie odpowiedzi na częste pytania
Zebrane, konkretne odpowiedzi na wątpliwości, które pojawiają się podczas naprawy.
- Po aktualizacji wyskoczyła biała strona – co zrobiłem źle?
- Nic szczególnego – aktualizacje czasem kolidują. Cofnij aktualizację problematycznej wtyczki/motywu lub przywróć kopię, a potem aktualizuj partiami.
- Czy wyłączenie wszystkich wtyczek zaszkodzi SEO/indeksacji?
- Krótkotrwale – nie. Lepiej mieć działającą stronę bez części funkcji niż białą stronę. Pamiętaj o zachowaniu kopii ustawień.
- Jak długo trzymać podwyższony limit pamięci?
- Docelowo zoptymalizuj wtyczki/motyw. 256M bywa “złotym środkiem” dla wielu stron; sklepy i buildery czasem potrzebują 512M.
- Czy mogę bezpiecznie nadpisać wp-admin i wp-includes?
- Tak, z paczki tej samej wersji WordPressa. Upewnij się jednak, że wp-content pozostaje nienaruszony.
- Czy biała strona może być winą przeglądarki?
- Sporadycznie cache przeglądarki może mieszać, ale jeśli problem pojawia się dla wszystkich użytkowników i urządzeń – to serwer/WordPress.
- Co z trybem diagnostycznym Health Check?
- Świetny do testów na produkcji bez wpływu na użytkowników – polecam.
Checklista do wydrukowania
Zestaw kroków w punktach, które możesz odhaczać w trakcie naprawy.
- [ ] Włącz WP_DEBUG i sprawdź wp-content/debug.log
- [ ] Podnieś memory_limit do 256–512M
- [ ] Wyłącz wszystkie wtyczki (zmiana nazwy wp-content/plugins)
- [ ] Aktywuj wtyczki pojedynczo, aby znaleźć winowajcę
- [ ] Przełącz na domyślny motyw (Twenty Twenty‑Four)
- [ ] Odśwież .htaccess (usuń i wygeneruj)
- [ ] Sprawdź wersję PHP i rozszerzenia
- [ ] Wyczyść cache wtyczek, hostingu i CDN
- [ ] Sprawdź uprawnienia plików i własność
- [ ] Przejrzyj logi serwera i limity
- [ ] Sprawdź bazę danych i napraw tabele
- [ ] Zweryfikuj pliki pod kątem BOM/whitespace
- [ ] Przeskanuj stronę pod kątem malware
- [ ] W razie potrzeby przywróć kopię i testuj na stagingu
Kiedy poprosić o pomoc specjalisty
Jeśli stoisz w miejscu ponad godzinę lub strona jest kluczowa biznesowo – skróć czas przestoju i zleć naprawę.
- Brak dostępu do logów i panelu hostingu.
- Ciągłe powroty białej strony po krótkim czasie.
- Złożone konflikty między builderem a motywem/wtyczkami premium.
- Podejrzenie infekcji i brak pewności co do pełnego oczyszczenia.
Dobry specjalista nie tylko naprawi, ale przygotuje plan prewencji, by sytuacja nie wracała.
Podsumowanie i dobre praktyki na przyszłość
Biała strona WordPress nie musi oznaczać katastrofy – metodyczna diagnostyka pozwala wrócić do gry nawet w kilkanaście minut.
Zacznij od włączenia debugowania i logów, podnieś limit pamięci, wyłącz wtyczki, zmień motyw, odbuduj .htaccess i sprawdź cache. Zadbaj o zgodną wersję PHP oraz o poprawne uprawnienia. Gdy nic nie pomaga, porównaj pliki z czystą instalacją i – w razie konieczności – przywróć kopię. A na przyszłość wdroż staging, regularne backupy i przemyślane aktualizacje. Taki zestaw nawyków sprawi, że nawet jeśli kiedyś znów zobaczysz pusty ekran, będziesz wiedzieć dokładnie, co robić i jak szybko wyprowadzić stronę na prostą.
