"Klikam Zapisz, a zmian nie ma." To zgłoszenie brzmi jak jeden problem, a kryje się za nim co najmniej siedem różnych przyczyn, i każda ma inne rozwiązanie. Znam je wszystkie z pytań moich kursantek, a najciekawsze jest to, że w większości przypadków WordPress... zapisuje zmiany poprawnie. One tylko nie tam trafiają albo nie tam ich szukasz. W tym artykule przechodzę przez wszystkie przyczyny od najczęstszej do najrzadszej, z osobnym rozdziałem o wersji mobilnej, bo to tam ginie najwięcej nerwów.
Przyczyna 1: pamięć podręczna pokazuje starą wersję (najczęstsza!)
Zmiany są zapisane, ale Ty i odwiedzające widzicie wersję strony sprzed zmian, bo serwuje ją pamięć podręczna. Test rozstrzygający: otwórz stronę w trybie incognito. Widzisz zmiany? Sprawa zamknięta, winne było buforowanie.
Rozwiązanie w trzech warstwach: wyczyść cache we wtyczce buforującej na stronie, wyczyść pamięć podręczną przeglądarki (albo po prostu pracuj z podglądem w incognito) i, jeśli używasz optymalizatorów plików, wyczyść też ich cache. Nawyk czyszczenia cache po każdej większej zmianie opisałam szerzej w artykule o wtyczce cache.
Przyczyna 2: edytujesz wersję mobilną nie tam, gdzie trzeba
A teraz gwiazda tego artykułu, bo ten przypadek potrafi zabrać całe popołudnie. Scenariusz z forum: kursantka w kreatorze przełącza widok na telefon, zmniejsza czcionkę nagłówka, klika Zapisz, i nic. Zmiana znika albo dotyczy wszystkich urządzeń naraz.
Wyjaśnienie: w kreatorach stron (Divi, Elementor i innych) przełącznik komputer/tablet/telefon na dolnym pasku to często tylko tryb podglądu. Pokazuje, jak strona wygląda na danym urządzeniu, ale edycja w tym trybie bywa globalna. Prawdziwa edycja per urządzenie kryje się gdzie indziej:
W Divi: najedź myszką na konkretne ustawienie w opcjach modułu (np. rozmiar tekstu w zakładce Design), a obok pojawią się małe ikonki, w tym ikonka telefonu. Dopiero kliknięcie tej ikonki przy konkretnym ustawieniu otwiera osobne pola dla komputera, tabletu i telefonu, i zmiany tam wprowadzone dotyczą tylko wybranego urządzenia. Dodatkowo globalne style mobilne ustawisz w Wygląd → Dostosuj, a widocznością całych modułów sterujesz w ich zaawansowanych ustawieniach.
W Elementorze: analogicznie, przy ustawieniach responsywnych widnieje ikonka urządzenia, a wartości ustawia się osobno dla każdego widoku. Pisałam o tym więcej w artykule o problemach z Elementorem.
Zasada uniwersalna: jeśli zmiana ma dotyczyć jednego urządzenia, szukaj ikonki urządzenia przy konkretnym ustawieniu, a nie tylko na pasku podglądu. Hierarchia też ma znaczenie: wartości dla tabletu dziedziczą się na telefon, dopóki nie nadpiszesz ich osobno.
Przyczyna 3: własny CSS nadpisuje Twoje zmiany
Podstępna sytuacja: zmieniasz ustawienie w panelu, zapis przechodzi, a na stronie nic. Możliwe, że gdzieś w niestandardowym CSS siedzi reguła (często z dopiskiem !important), która nadpisuje ustawienia z panelu. W Divi własny CSS może mieszkać aż w trzech miejscach: Wygląd → Dostosuj → Dodatkowy CSS, w opcjach szablonu Divi oraz w Stylisty tematów. W innych motywach sprawdź Dodatkowy CSS w personalizacji i pliki motywu potomnego. Jeśli znajdziesz regułę dotyczącą elementu, którego nie możesz zmienić, to Twój winowajca: zmodyfikuj ją lub usuń, zamiast walczyć z nią przez panel.
Przyczyna 4: edytujesz nie tę stronę lub nie tę wersję
Brzmi banalnie, zdarza się nagminnie, zwłaszcza przy przebudowie strony. Typowe warianty: równolegle istnieją stare i nowe wersje podstron (a menu wciąż linkuje do starych), edytujesz szkic, a opublikowana jest inna wersja, albo personalizacja (Wygląd → Dostosuj) otwiera stronę główną ze starą zawartością. Porządek ratuje sytuację: stare wersje stron przełącz w szkice, nowe opublikuj i podepnij w menu, a przebudowę rób etapami, sprawdzając po każdej podmianie, czy nic się nie wysypało. Do większych przebudów rozważ pracę na kopii strony zamiast równoległych wersji podstron.
Przyczyna 5: konflikt wtyczek blokuje zapis
Jeśli przy zapisie pojawia się błąd (a nie cisza), typowym źródłem są konflikty: wtyczki optymalizujące JavaScript potrafią zakłócać działanie edytora, a zabezpieczenia serwera blokować zapis treści z osadzonym kodem. Diagnoza standardowa: wyłącz wtyczki poza kreatorem, sprawdź zapis, włączaj pojedynczo. Pełną procedurę znajdziesz w moim artykule o błędzie krytycznym WordPressa.
Przyczyna 6: limity serwera
Przy bardzo rozbudowanych stronach zapis może przerywać zbyt niski limit pamięci PHP lub czasu wykonania skryptu. Objaw: zapis długo mieli i kończy się błędem albo białą stroną. Limity podniesiesz w panelu hostingu, a przy okazji sprawdź wersję PHP, o czym pisałam w artykule o bezpieczeństwie WordPressa.
Przyczyna 7: przeglądarka
Na koniec czynnik ludzko-sprzętowy: przepełniona pamięć przeglądarki, zawieszona sesja, dziesiątki otwartych kart. Zanim wpadniesz w spiralę diagnozy, wyczyść dane przeglądarki, wyloguj się i zaloguj ponownie, a w razie potrzeby zrestartuj komputer. Wiem, brzmi jak porada z infolinii, ale regularnie kończy sprawę.
A jak cofnąć zmiany, które właśnie namieszały?
Skoro mówimy o zapisywaniu, to dopowiedzmy drugą stronę medalu: co, gdy zapisało się coś, czego wolałabyś nie zapisać. Masz trzy poziomy ratunku:
- Rewizje. WordPress przechowuje historię wersji każdego wpisu i strony: w edycji znajdziesz sekcję Rewizje i porównasz wersje oraz przywrócisz wcześniejszą jednym kliknięciem.
- Kopia zapasowa. Wtyczka typu UpdraftPlus przywróci stronę z wczoraj w kilka minut. Jak ustawić kopie i przywracanie, opisuję w osobnym artykule o kopii zapasowej WordPressa.
- Kopie hostingu. Dobre hostingi trzymają automatyczne kopie z ostatnich dni, dostępne z panelu lub przez support. To Twoje koło ratunkowe, gdy nie masz własnych kopii, choć docelowo miej własne.
Jak opisać problem AI, żeby dostać diagnozę zamiast ogólników
Ten artykuł jest najlepszym dowodem na pewną prawidłowość: "WordPress nie zapisuje zmian" to siedem różnych problemów. Jeśli tak samo ogólnie opiszesz sprawę w czacie AI, dostaniesz listę ogólników. Precyzja wkładu decyduje o precyzji odpowiedzi, dlatego naucz się schematu opisu objawu:
Pracuję w [WordPress + kreator i wersja, np. Divi] na motywie [nazwa]. Problem: [co dokładnie robisz, np. "zmieniam rozmiar czcionki nagłówka w widoku telefonu w opcjach modułu"]. Oczekuję: [co powinno się stać]. Zamiast tego: [co się dzieje, słowo w słowo z komunikatami, albo "zapis przechodzi bez błędu, ale zmiany nie widać"]. Już sprawdziłam: [lista, np. "tryb incognito bez zmian, cache wyczyszczony, inne ustawienia zapisują się poprawnie"]. Podaj możliwe przyczyny od najbardziej prawdopodobnej i sposób weryfikacji każdej.
Sekcja "już sprawdziłam" jest kluczowa: eliminuje z odpowiedzi to, co już wykluczyłaś, i kieruje diagnozę na właściwy tor. Zauważ, że w przypadku z Divi taki opis niemal na pewno zwróci trafną odpowiedź o edycji per ustawienie zamiast trybu podglądu, bo objaw "zapis przechodzi, zmiana globalna zamiast mobilnej" jednoznacznie na to wskazuje. Dobre opisywanie problemów to umiejętność, która procentuje w całej pracy z AI, i systematycznie ćwiczymy ją w Akademii WordPress + AI.
Krok po kroku
- Sprawdź stronę w trybie incognito; jeśli zmiany tam są, wyczyść pamięć podręczną wtyczki i przeglądarki.
- Przy zmianach mobilnych szukaj ikonki urządzenia przy konkretnym ustawieniu w opcjach modułu, nie tylko na pasku podglądu.
- Przejrzyj miejsca z własnym CSS i usuń reguły nadpisujące ustawienia, które próbujesz zmienić.
- Uporządkuj wersje stron: stare w szkice, nowe opublikowane i podpięte w menu.
- Jeśli zapis zgłasza błąd, wykonaj test konfliktu wtyczek i sprawdź limity PHP na hostingu.
- Ustaw kopie zapasowe i zapamiętaj drogę do rewizji, żeby każdą nieudaną zmianę dało się cofnąć w minutę.
