Znajomo: wchodzą Państwo na stronę, a tam biały ekran i pamiętne cyfry 404. Przy czym strona główna się otwiera, panel administracyjny działa, ale konkretny wpis lub podstrona już nie. Sprawdzają Państwo URL, ponownie zapisują wpis, czyszczą pamięć podręczną wtyczki, nic.

W dziewięciu przypadkach na dziesięć źródłem problemu są uszkodzone reguły przepisywania WordPress. Bezpośrednie odnośniki (permalinki) przestały być rozpoznawane i silnik nie wie, jaką treść wyświetlić pod danym adresem. Dobra wiadomość: leczy się to w minutę, bez wtyczek i bez edycji kodu.

Poniżej trzy sposoby na zresetowanie bezpośrednich odnośników: od najprostszego (kilka kliknięć w panelu administracyjnym) po ręczną ingerencję w bazę danych przez phpMyAdmin. Po resecie błąd 404 znika, a struktura URL pozostaje nienaruszona.

💡 Szybki przegląd:

• Proszę wejść do panelu administracyjnego WordPress i kliknąć „Zapisz zmiany" na stronie bezpośrednich odnośników.
• Proszę dodać wiersz kodu do pliku functions.php motywu, odświeżyć stronę i usunąć ten wiersz z powrotem.
• Proszę wyczyścić pole rewrite_rules w tabeli wp_options przez phpMyAdmin.
• Proszę sprawdzić rezultat: otworzyć problematyczną stronę i upewnić się, że błąd 404 zniknął.

Czym są bezpośrednie odnośniki i po co je resetować

Bezpośrednie odnośniki (permalinki) to przyjazne dla człowieka adresy URL stron i wpisów WordPress. Zamiast ?p=123 widzą Państwo /blog/kak-sbrosit-ssylki/. Za przekształcanie odpowiada mechanizm rewrite rules, czyli zbiór reguł, który silnik przechowuje w bazie danych i (przy określonych ustawieniach) w pliku .htaccess.

Gdy dodawany jest nowy typ wpisów, zmienia się struktura odnośników lub po migracji witryny reguły przepisywania mogą nie zaktualizować się automatycznie. WordPress nadal używa starej pamięci podręcznej reguł i strona, która fizycznie istnieje, zwraca błąd 404. Reset (flush) wymusza przebudowę rewrite rules od zera: usuwa zapisane reguły i generuje aktualne.

To nie jest „usuwanie" bezpośrednich odnośników, struktura URL zdefiniowana w ustawieniach pozostaje taka sama. Zmienia się jedynie wewnętrzna pamięć podręczna reguł routingu. Operacja jest całkowicie bezpieczna: motywy, wtyczki i treść nie są naruszane.

Sposób 1. Przez panel sterowania WordPress

Najszybsza i najbezpieczniejsza metoda, reset przez panel administracyjny. Sprawdza się, jeśli panel sterowania jest dostępny.

• Proszę zalogować się do konsoli WordPress: ваш-сайт.com/wp-admin.
• Proszę przejść do Ustawienia → Bezpośrednie odnośniki.
• Proszę niczego nie zmieniać w ustawieniach, tylko przewinąć stronę w dół.
• Proszę kliknąć niebieski przycisk „Zapisz zmiany".

WordPress po cichu przebuduje rewrite rules i zaktualizuje .htaccess (jeśli jest używany). Nie pojawi się żadne powiadomienie o sukcesie, proszę po prostu otworzyć problematyczną stronę w nowej karcie przeglądarki i sprawdzić, czy błąd zniknął.

Dlaczego to działa? Gdy klikają Państwo przycisk „Zapisz zmiany", silnik wywołuje wewnętrzną funkcję flush_rewrite_rules(), tę samą, której programiści używają w kodzie. Różnica polega tylko na sposobie uruchomienia: tutaj klikają Państwo myszą, a nie piszą PHP.

Metoda rozwiązuje problem w zdecydowanej większości przypadków. Jeśli nie pomogła, proszę przejść do sposobu 2.

Sposób 2. Przez functions.php motywu

Jeśli panel administracyjny nie ładuje się lub przycisk „Zapisz" nie dał rezultatu, proszę zresetować reguły programowo. Wymaga to dostępu do plików witryny: przez FTP, menedżer plików hostingu lub wbudowany edytor motywów.

Ważne: flush_rewrite_rules() to kosztowna operacja. Przebudowuje całą strukturę URL i wywoływana przy każdym żądaniu wyraźnie spowalnia witrynę. Dlatego dodamy funkcję jednorazowo, odświeżymy witrynę i natychmiast usuniemy wiersz.

• Proszę otworzyć plik functions.php aktywnego motywu. Ścieżka: /wp-content/themes/ваша-тема/functions.php.
• Na samym końcu pliku, przed zamykającym ?> (jeśli występuje), proszę dodać jeden wiersz:

1
flush_rewrite_rules();

• Proszę zapisać plik.
• Proszę odświeżyć dowolną stronę witryny w przeglądarce, funkcja wykona się przy pierwszym żądaniu.
• Proszę ponownie otworzyć functions.php i usunąć dodany wiersz. Koniecznie.

Funkcja wykonała się raz, reguły zostały przebudowane, kod usunięty, witryna działa normalnie bez zbędnego obciążenia. To samo podejście stosują twórcy wtyczek: flush_rewrite_rules() podpina się pod hak aktywacji, a nie pod każde żądanie.

Alternatywa dla tych, którzy nie chcą dotykać functions.php bezpośrednio: wtyczka Code Snippets. Proszę utworzyć nowy snippet z tym samym kodem, wykonać go raz (przycisk „Execute") i usunąć. Rezultat jest identyczny.

Sposób 3. Przez phpMyAdmin, bezpośredni reset reguł w bazie

Najgłębszy poziom, ręczne wyczyszczenie rewrite rules bezpośrednio w tabeli wp_options. Proszę stosować, gdy nie ma dostępu ani do panelu administracyjnego, ani do plików motywu (na przykład biały ekran śmierci na całej witrynie poza bazą danych).

Koniecznie proszę wykonać kopię zapasową bazy przed jakimikolwiek zmianami w phpMyAdmin. Jedno nieprawidłowe działanie w edytorze SQL może nieodwracalnie uszkodzić witrynę.

• Proszę zalogować się do phpMyAdmin przez panel hostingu (cPanel, ISPmanager, DirectAdmin), sekcja „Bazy danych".
• W lewej kolumnie proszę wybrać bazę danych Państwa witryny WordPress.
• Proszę przejść na zakładkę SQL w górnym menu.
• Proszę wkleić zapytanie w pole tekstowe i kliknąć „Wykonaj" (Go):

1
SELECT * FROM wp_options WHERE option_name = 'rewrite_rules'

• W wynikach zobaczą Państwo jeden wiersz. Proszę kliknąć „Edytuj" (ołówek) obok niego.
• Proszę znaleźć pole option_value, długi tekst z danymi serializowanymi. Proszę zaznaczyć całą zawartość pola i usunąć, a następnie zapisać.

Podczas następnego ładowania dowolnej strony witryny WordPress wykryje pustą wartość rewrite_rules, zrozumie, że nie ma reguł, i wygeneruje je ponownie automatycznie. Nie trzeba niczego dodatkowo uruchamiać.

Uwaga: w niektórych konfiguracjach hostingu prefiks tabel może różnić się od wp_. Jeśli Państwa prefiks jest inny (na przykład wpxy_), proszę zamienić wp_options na wpxy_options. Prefiks można sprawdzić w pliku wp-config.php, w wierszu $table_prefix.

Wideo: resetowanie bezpośrednich odnośników w praktyce

Jeśli wygodniej jest Państwu oglądać niż czytać, na tym wideo pokazano cały proces resetowania bezpośrednich odnośników pierwszym sposobem, od zalogowania do panelu administracyjnego po sprawdzenie rezultatu:

⁉️🤔 Często zadawane pytania

Czy moje adresy URL znikną po resecie bezpośrednich odnośników?

Nie. Reset (flush) nie zmienia struktury odnośników zdefiniowanej w „Ustawienia → Bezpośrednie odnośniki". Jedynie przebudowuje wewnętrzną pamięć podręczną reguł routingu. Wszystkie Państwa adresy /blog/, /product/ i /category/ pozostaną dokładnie takie same. Wyjątek: jeśli ręcznie zmienili Państwo strukturę w ustawieniach przed zapisaniem, wówczas adresy URL zostaną przebudowane według nowego szablonu.

Czy trzeba instalować wtyczkę do resetowania bezpośrednich odnośników?

Do jednorazowej operacji, zdecydowanie nie. Trzy powyższe sposoby pokrywają wszystkie scenariusze bez dodatkowego oprogramowania. Wtyczki takie jak Rewrite Rules Inspector mają sens tylko wtedy, gdy regularnie rejestrują Państwo niestandardowe typy wpisów i taksonomie w kodzie i chcą widzieć stan reguł w czasie rzeczywistym. Do zwykłego naprawienia błędu 404 to przerost formy nad treścią.

Reset przez panel administracyjny nie pomógł. Co dalej?

Proszę sprawdzić, czy plik .htaccess nie jest nadpisywany przez inną wtyczkę (buforowania, bezpieczeństwa, SEO). Proszę tymczasowo dezaktywować podejrzane wtyczki i powtórzyć reset. Jeśli to nie pomogło, proszę przejść do sposobu 2 (PHP), gwarantuje on wywołanie tej samej funkcji flush_rewrite_rules() z pominięciem wszelkich filtrów panelu administracyjnego.

Czy można zresetować reguły przez WP-CLI?

Tak, jeśli na serwerze zainstalowano WP-CLI, polecenie wp rewrite flush robi dokładnie to samo z wiersza poleceń. To najszybszy sposób dla programistów pracujących przez SSH. Wykonuje się natychmiast, nie wymaga otwierania przeglądarki i nie pozostawia śladów w kodzie motywu.

Co zrobić, jeśli po resecie błąd 404 pozostał?

Przyczyna nie leży w bezpośrednich odnośnikach. Proszę sprawdzić trzy rzeczy: (1) czy sama strona lub wpis nie zostały fizycznie usunięte, (2) czy slug nie koliduje z inną treścią lub taksonomią, (3) czy żądań nie blokuje plik .htaccess z nieprawidłowymi regułami przekierowań. W tym ostatnim przypadku proszę tymczasowo zmienić nazwę .htaccess na .htaccess.bak, zapisać bezpośrednie odnośniki przez panel administracyjny (WordPress utworzy nowy .htaccess) i sprawdzić ponownie.

Zresetowali Państwo odnośniki, co dalej?

Wykonali Państwo reset jednym z trzech sposobów i strona się otworzyła. Świetnie. Ale jeśli błąd 404 pojawił się raz, może powrócić: po aktualizacji wtyczki, zmianie motywu lub modyfikacjach w niestandardowych typach wpisów. Proszę dodać tę instrukcję do zakładek, pierwszy sposób (przycisk „Zapisz" w panelu administracyjnym) znają już Państwo na pamięć i wykonają w dziesięć sekund.

I najważniejsza zasada pracy z bazą danych: przed jakąkolwiek ingerencją, kopia zapasowa. phpMyAdmin nie wybacza błędów, a backup bazy przywraca witrynę do życia w kilka minut.