Strona internetowa nie działa albo pokazuje błąd

• „W witrynie wystąpił błąd krytyczny.” (po angielsku „There has been a critical error on this website”): błąd w kodzie PHP przerwał ładowanie strony, zwykle po aktualizacji wtyczki, motywu albo wersji PHP.
• „Błąd łączenia się z bazą danych” (Error establishing a database connection): strona nie łączy się z bazą, bo zmieniło się hasło do bazy, serwer jest przeciążony albo tabele są uszkodzone.
• „500 Internal Server Error”: ogólny błąd serwera, zwykle przez błędny plik .htaccess, za mały limit pamięci PHP albo konflikt wtyczek.
• „403 Forbidden” albo „Twoje konto hostingowe zostało zablokowane”: hosting zablokował stronę za nieopłaconą fakturę, przekroczone limity albo złośliwy kod.
• Biała strona albo niedziałający panel wp-admin: zwykle ten sam błąd co „błąd krytyczny”, tylko bez treści komunikatu.
• Strona rejestratora zamiast Twojej: wygasła domena albo zmienione serwery DNS.

Te kroki niczego nie zmieniają na stronie, więc nie pogorszą sytuacji:

1. Otwórz stronę na telefonie przez internet komórkowy, z wyłączonym Wi-Fi. Jeśli działa, przyczyna leży raczej w Twojej sieci lub komputerze.
2. Sprawdź skrzynkę administratora strony. Przy błędzie krytycznym WordPress wysyła e-mail, często z nazwą wtyczki lub motywu, który zatrzymał stronę.
3. Sprawdź, czy hosting i domena są opłacone: faktury i przypomnienia w poczcie, a dla domen .pl wyszukiwarka WHOIS na dns.pl z datą odnowienia.
4. Przypomnij sobie ostatnie zmiany (aktualizacja, nowa wtyczka, inna wersja PHP) i zrób zrzut ekranu komunikatu.
5. Sprawdź, czy w panelu hostingu są kopie zapasowe, ale ich nie przywracaj. Stara kopia przywrócona bez diagnozy skasuje nowsze zamówienia i wiadomości.

Nie usuwaj wtyczek na ślepo i nie instaluj WordPressa od nowa. Jeśli strona to sklep albo właśnie płacisz za reklamy, zadzwoń od razu.

Objaw. W październiku 2026, po aktualizacji do WordPressa 7.1, dwie strony firmowe naszych klientów pokazywały już tylko „W witrynie wystąpił błąd krytyczny” (błąd 500), także w panelu. Razem z aktualizacją serwer przeszedł na PHP 8, a motywy i dwie wtyczki tych stron miały ponad 10 lat.

Co pokazał log serwera przy pierwszej stronie (nazwę motywu zmieniliśmy):

[24/Oct/2026:16:38:41 +0000] "GET / HTTP/1.1" 500 3057
PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function WP_Widget::__construct(), 0 passed in /var/www/html/wp-includes/class-wp-widget-factory.php on line 77 and at least 2 expected in /var/www/html/wp-includes/class-wp-widget.php:163
Stack trace:
#0 /var/www/html/wp-includes/class-wp-widget-factory.php(77): WP_Widget->__construct()
#1 /var/www/html/wp-includes/widgets.php(123): WP_Widget_Factory->register('VMenuWidget')
#2 /var/www/html/wp-content/themes/motyw/library/widgets.php(255): register_widget('VMenuWidget')

Przyczyna. Widżety motywu miały konstruktory w starym stylu PHP 4: funkcję o nazwie klasy. PHP 8 nie traktuje jej już jak konstruktora, więc WordPress tworzył widżet bez wymaganych danych i zatrzymywał całą stronę. Na drugiej stronie motyw i stara wersja WPBakery (4.12) używały funkcji usuniętych w PHP 8 (create_function(), each(), get_magic_quotes_gpc()), wywoływały count() na pustej wartości, miały zagnieżdżony operator ?: bez nawiasów i wyrażenie regularne [\w-_], którego nowe wersje PHP już nie akceptują.

Jak to naprawiliśmy:

1. Kopie plików i baz danych, potem obie strony uruchomione u nas na tych samych wersjach co na serwerze: WordPress 7.1 i PHP 8.3.

2. Poprawki w plikach motywów i wtyczek, bez zmiany wyglądu i treści. Na przykład konstruktor widżetu:

   // przed: w PHP 8 to już nie jest konstruktor
   function VMenuWidget() {
       parent::WP_Widget(false, __('Vertical Menu', THEME_NS), $widget_ops);
   }
   // po
   function __construct() {
       parent::__construct(false, __('Vertical Menu', THEME_NS), $widget_ops);
   }
   

3. Sprawdzenie wszystkich publicznych stron i całego panelu po każdej poprawce. Tak wyszły błędy ukryte za pierwszym komunikatem: wtyczka galerii zatrzymywała edytor i widżety w panelu, bo w PHP 8 znak @ nie wycisza już błędów typu (closedir() wywoływane bez otwartego katalogu).

4. each() w WPBakery zastąpione pętlą, która działa dokładnie tak samo. Zwykły foreach dawał w tym miejscu pętlę bez końca, co wyszło dopiero w testach.
5. Na serwer trafiła tylko paczka ze zmienionymi plikami. Na drugiej stronie po aktualizacji był włączony inny motyw, więc trzeba było jeszcze włączyć z powrotem właściwy.

Wynik. Poprawki były gotowe tego samego dnia. W testach na wersjach z serwera wszystkie strony publiczne i wszystkie strony panelu obu witryn odpowiadały bez błędów. Wniosek: stary motyw nie zawsze oznacza nową stronę, często wystarczy poprawić jego kod. Przed aktualizacją WordPressa albo PHP warto jednak uruchomić kopię strony na nowych wersjach, zanim zrobi to serwer.

Awarie często zaczynają się od aktualizacji bez kopii albo od porzuconej wtyczki. W pakiecie prowde All Inclusive Pro (900 zł netto za rok) WordPress i wtyczki aktualizują się automatycznie, PHP i serwer są zawsze aktualne, a raz w roku naprawiamy stronę, jeśli aktualizacja ją zepsuje. W pakiecie All Inclusive WaaS (2 500 zł netto za rok, ceny: stan na listopad 2026) technicznym utrzymaniem strony zajmuje się człowiek, naprawy po aktualizacjach są bez limitu, a gdy starej strony nie da się już naprawić, budujemy ją od nowa w Elementorze, z zachowaniem wyglądu i podstron.

Szczegóły znajdziesz na stronach naprawa strony WordPress i opieka nad stroną internetową, a ceny w cenniku.