Elementor nie działa? Szybka diagnoza problemu
Klikasz „Edytuj w Elementorze”, a zamiast edytora widzisz kręcące się kółko, szary ekran albo pusty panel bez widżetów. Znam to z autopsji, bo w ostatnich latach naprawiałem dziesiątki stron, na których Elementor odmówił współpracy. Dobra wiadomość jest taka, że w zdecydowanej większości przypadków przyczyna jest banalna, a naprawa zajmuje kilkanaście minut. W tym wpisie pokazuję, jak sam diagnozuję problem krok po kroku, od najczęstszych winowajców do tych rzadszych.
Najpierw ustal, co dokładnie nie działa
„Elementor nie działa” to bardzo pojemne hasło. Zanim cokolwiek zmienisz, nazwij objaw, bo od niego zależy, gdzie zacznę szukać. Najczęściej spotykam takie sytuacje:
- Edytor ładuje się w nieskończoność, czyli widzisz logo albo spinner, który nigdy nie znika.
- Panel widżetów jest pusty albo kręci się tylko lewa kolumna.
- Zmiany się nie zapisują, a przycisk „Opublikuj” lub „Aktualizuj” zwraca błąd. Jeśli widzisz komunikat o nieprawidłowej odpowiedzi JSON, zajrzyj do mojego wpisu o błędzie Updating failed. The response is not a valid JSON response.
- W edytorze wszystko wygląda dobrze, a na stronie już nie, bo style się rozjeżdżają albo zmiany w ogóle nie są widoczne.
- Biały ekran lub błąd 500 po aktualizacji Elementora albo innej wtyczki. Ten przypadek szerzej opisałem w artykule o białej stronie (WSOD) w WordPressie.
Zapisz sobie, kiedy problem się pojawił. Jeśli dzień wcześniej była aktualizacja wtyczki, motywu albo zmiana wersji PHP na serwerze, to masz już bardzo mocny trop.
Zanim zaczniesz: kopia zapasowa i informacje o systemie
Zawsze zaczynam od kopii zapasowej plików i bazy danych. Większość kroków poniżej jest bezpieczna, ale przy grzebaniu w wp-config.php czy przywracaniu starszej wersji wtyczki wolę mieć drogę odwrotu.
Druga rzecz to zakładka Elementor > Informacje o systemie. Znajdziesz tam wersję PHP, limit pamięci, wersję WordPressa i listę aktywnych wtyczek, a na dole log błędów. To pierwsze miejsce, do którego zaglądam, bo często już tutaj widać czerwone ostrzeżenie, które wskazuje przyczynę.
Przyczyna nr 1: za niski limit pamięci PHP
To mój absolutny numer jeden, szczególnie przy edytorze, który ładuje się bez końca. Według oficjalnych wymagań Elementor potrzebuje minimum 256 MB pamięci dla WordPressa, producent zaleca 512 MB, a dla najlepszej wydajności nawet 768 MB. Jeśli na stronie działa też WooCommerce albo kilka rozbudowanych dodatków, 256 MB bardzo szybko przestaje wystarczać. Przy okazji zwiększony apetyt na pamięć często idzie w parze z ogólnym spowolnieniem, o czym pisałem w tekście dlaczego sklep WooCommerce działa wolno.
Limit podnoszę w pliku wp-config.php, dopisując poniższe linie nad komentarzem „To wszystko, zakończ edycję”:
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Pamiętaj, że WordPress nie przeskoczy limitu ustawionego na serwerze. Jeśli po zmianie w Informacjach o systemie dalej widzisz stare wartości, musisz podnieść memory_limit w panelu hostingu (zwykle w ustawieniach PHP) albo poprosić o to support. Przy okazji sprawdzam też max_execution_time (u mnie minimum 300) oraz max_input_vars, bo zbyt niska wartość tego drugiego potrafi powodować, że duże strony po prostu się nie zapisują lub tracą część ustawień. Wszystkie sposoby na podniesienie limitu oraz sytuacje, w których to nie pomoże, zebrałem w osobnym poradniku: Allowed memory size exhausted, czyli jak zwiększyć limit pamięci PHP.
Przyczyna nr 2: konflikt z inną wtyczką lub motywem
Drugi najczęstszy scenariusz. Wystarczy jedna wtyczka, która ładuje swój skrypt JavaScript w panelu administracyjnym, i edytor Elementora się wysypuje. Moja procedura wygląda tak:
- Wyłączam wszystkie wtyczki poza Elementorem i Elementorem Pro.
- Przełączam motyw na lekki i sprawdzony, na przykład Hello Elementor lub domyślny motyw WordPressa.
- Sprawdzam, czy edytor działa. Jeśli tak, włączam wtyczki po jednej i za każdym razem odświeżam edytor.
- Gdy problem wraca, wiem już, która wtyczka jest winna.
Na działającej stronie produkcyjnej nie wyłączam wtyczek „na żywo”. Zamiast tego używam wtyczki Health Check & Troubleshooting, która uruchamia tryb rozwiązywania problemów tylko dla mojej sesji. Odwiedzający widzą normalną stronę, a ja testuję wtyczki po kolei. Warto też zajrzeć do Elementor > Narzędzia i włączyć Tryb bezpieczny, który ładuje edytor bez wpływu innych wtyczek i motywu. Jeśli w trybie bezpiecznym wszystko działa, masz pewność, że przyczyna leży poza samym Elementorem.
Przyczyna nr 3: nieaktualna lub niewłaściwa wersja PHP
Elementor formalnie działa od PHP 7.4, ale sam producent mocno zaleca PHP 8.x i ja się pod tym podpisuję. Wymagany jest też WordPress w wersji 6.5 lub nowszej. Na starym PHP problemy pojawiają się zwykle po aktualizacji wtyczki, bo nowy kod korzysta z funkcji, których serwer nie obsługuje.
Działa to też w drugą stronę. Zdarzało mi się, że hosting automatycznie podbił PHP do najnowszej wersji, a starsze dodatki do Elementora zaczęły sypać błędami. Dlatego po każdej zmianie wersji PHP sprawdzam log błędów i w razie kłopotów tymczasowo wracam do poprzedniej wersji, dopóki autorzy wtyczek nie wydadzą poprawek.
Przyczyna nr 4: cache, minifikacja i CDN
Wtyczki optymalizacyjne to częsty cichy sabotażysta. Łączenie i minifikacja plików JavaScript, opóźnione ładowanie skryptów czy funkcje w stylu Rocket Loadera w Cloudflare potrafią rozbić edytor albo sprawić, że strona wygląda inaczej niż w podglądzie. Gdy widzę taki problem, robię kolejno:
- czyszczę cache wtyczki, serwera i CDN,
- wyłączam na próbę łączenie i opóźnianie JS,
- dodaję edytor Elementora i strony podglądu do wykluczeń w cache,
- testuję w oknie prywatnym przeglądarki, z wyłączonymi rozszerzeniami (blokery reklam też potrafią namieszać).
Przyczyna nr 5: uszkodzone pliki CSS i dane Elementora
Jeśli edytor działa, ale na stronie style się rozjeżdżają, zmiany nie są widoczne albo po migracji wszystko wygląda dziwnie, przechodzę do Elementor > Narzędzia > Ogólne i klikam Wygeneruj ponownie pliki i dane. Elementor zapisuje style w osobnych plikach CSS i czasem te pliki po prostu się rozjeżdżają z bazą danych. W tym samym miejscu warto użyć opcji synchronizacji biblioteki.
Po przeprowadzce strony na nową domenę lub po przejściu z HTTP na HTTPS korzystam z zakładki Zastąp URL w tych samych narzędziach. Elementor przechowuje adresy w swoich danych i zwykła zmiana adresu w ustawieniach WordPressa nie zawsze wystarczy. Upewniam się też, że adres WordPressa i adres witryny w Ustawienia > Ogólne są identyczne i oba zaczynają się od https. Jeśli po przejściu na SSL kłódka w przeglądarce nie jest zielona, a część stylów się nie ładuje, problemem jest najpewniej mixed content po włączeniu SSL.
Przyczyna nr 6: niezgodne wersje Elementora i Elementora Pro
Darmowy Elementor i wersja Pro muszą iść w parze. Jeśli zaktualizujesz jedno, a drugie zostanie kilka wersji w tyle, licz się z błędami. Zawsze aktualizuję je razem i sprawdzam, czy licencja Pro jest aktywna, bo bez niej aktualizacje Pro nie przychodzą.
Gdy problem pojawił się zaraz po aktualizacji, a nie mam czasu szukać przyczyny, używam funkcji Przywracanie wersji w Elementor > Narzędzia. Pozwala wrócić do wcześniejszego wydania jednym kliknięciem. Traktuję to jednak jako rozwiązanie tymczasowe, a nie stały stan strony, bo starsze wersje nie dostają poprawek bezpieczeństwa. Jeśli po aktualizacji posypała się cała strona, a nie tylko edytor, skorzystaj z mojej instrukcji jak wrócić do działającej wersji po aktualizacji wtyczki lub motywu.
Przyczyna nr 7: ustawienia serwera i zabezpieczeń
Kiedy wszystko powyżej jest w porządku, a edytor dalej nie działa, szukam przyczyny na serwerze. Najczęściej trafiam na:
- mod_security lub zaporę aplikacyjną, która blokuje zapytania wysyłane przez edytor przy zapisie. Objaw to błąd przy zapisywaniu albo zerwane połączenie. Pomaga wpis w wykluczeniach lub kontakt z hostingiem.
- Nagłówek Content-Security-Policy z ustawieniem frame-ancestors none. Edytor wyświetla podgląd strony w ramce iframe, a ta reguła ją blokuje, więc edytor nie ma szans się załadować.
- Wyłączone lub zablokowane REST API, na przykład przez wtyczki bezpieczeństwa, które zbyt agresywnie ograniczają dostęp.
- Brak rozszerzenia Zlib w PHP, które Elementor zaleca mieć włączone.
Jedna uwaga praktyczna: edycja w Elementorze jest przewidziana na komputery. Na telefonie edytor po prostu nie zadziała poprawnie, więc to nie jest awaria, tylko ograniczenie narzędzia.
Biały ekran albo błąd 500? Włącz log błędów
Przy białym ekranie zgadywanie nie ma sensu. Włączam tryb debugowania w wp-config.php, ale tak, żeby błędy trafiały do pliku, a nie na ekran odwiedzających:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Potem odtwarzam problem i zaglądam do pliku wp-content/debug.log. Prawie zawsze znajduję tam ścieżkę do konkretnej wtyczki, która spowodowała błąd krytyczny. Jeśli przez ten błąd nie możesz wejść do panelu, zmień przez FTP lub menedżer plików nazwę folderu tej wtyczki w wp-content/plugins. WordPress ją wtedy dezaktywuje i odzyskasz dostęp. Po zakończeniu diagnozy wyłączam debugowanie. Gdy WordPress wyświetla komunikat „Na tej stronie wystąpił błąd krytyczny”, postępuj według mojego poradnika jak naprawić błąd krytyczny w WordPressie.
Moja kolejność działania w skrócie
Kiedy klient pisze do mnie, że Elementor nie działa, przechodzę zawsze tę samą ścieżkę:
- Kopia zapasowa.
- Elementor > Informacje o systemie i log błędów.
- Limit pamięci na 512 MB lub więcej.
- Tryb bezpieczny i test konfliktu wtyczek oraz motywu.
- Wersja PHP i zgodność Elementora z Elementorem Pro.
- Czyszczenie cache i wyłączenie optymalizacji JS.
- Ponowne wygenerowanie plików i danych Elementora.
- Ustawienia serwera: zapora, nagłówki bezpieczeństwa, REST API.
W mojej praktyce pierwsze cztery kroki rozwiązują zdecydowaną większość przypadków. Do ustawień serwera schodzę rzadko, ale gdy już tam trafiam, to zwykle jest to problem, którego bez dostępu do konfiguracji hostingu nie da się obejść. Szerszy obraz tego, co najczęściej kładzie strony, znajdziesz w zestawieniu 5 najczęstszych przyczyn awarii strony internetowej.
Kiedy warto oddać to w ręce specjalisty?
Jeśli przeszedłeś całą listę i dalej stoisz w miejscu, albo po prostu nie czujesz się pewnie, edytując wp-config.php czy pliki na serwerze, nie ryzykuj. Niezręczna zmiana w konfiguracji potrafi zamienić drobną usterkę edytora w niedziałającą stronę. Chętnie zajmę się tym za Ciebie: zdiagnozuję przyczynę, naprawię Elementora i podpowiem, jak ustawić stronę, żeby problem nie wracał po kolejnej aktualizacji.
Nie chcesz robić tego samodzielnie?
Zajmę się tym za Ciebie. Napisz krótko, co się dzieje - odpowiem tego samego dnia roboczego.