Jak użyć wbudowanego trybu naprawy i optymalizacji bazy WordPress

Wbudowany tryb naprawy udostępnia skrypt WordPressa do sprawdzenia i naprawy tabel bazy oraz ich optymalizacji, ale nie naprawia każdego rodzaju tabeli ani całej witryny. Skrypt znajduje się pod adresem /wp-admin/maint/repair.php, a jego uruchomienie wymaga stałej WP_ALLOW_REPAIR w pliku wp-config.php.

Skuteczność operacji naprawy zależy od silnika tabel. MySQL 8.4 dopuszcza REPAIR TABLE dla tabel MyISAM, ARCHIVE i CSV, ale nie dla InnoDB. InnoDB jest domyślnym silnikiem nowych tabel w MySQL 8.4. W przypadku tabel InnoDB komunikat z repair.php trzeba ocenić według silnika i wyniku MySQL; nie należy zakładać, że skrypt naprawił tabelę. Dokumentację MySQL sprawdziliśmy w październiku 2026 r.

Tryb nie poprawi błędnego hasła do bazy, niedostępnego serwera MySQL, uszkodzonych plików PHP ani błędów wtyczki. Optymalizacja tabel nie diagnozuje również wolnych zapytań, nadmiaru opcji ładowanych automatycznie ani dużego ruchu.

Dokumentacja WordPressa wskazuje, że strona naprawy nie wymaga logowania, ponieważ może być potrzebna przy braku dostępu do panelu. Włącz stałą tylko na czas pracy i usuń ją po zakończeniu. Informacje o WP_ALLOW_REPAIR i ścieżce skryptu sprawdziliśmy w październiku 2026 r.

Tabela pomaga dobrać pierwsze działanie do objawu.

Użyj naprawy tabel przy objawie tabelarycznym, a połączenie i wydajność diagnozuj osobno. Przy szerszej awarii przydatna jest diagnoza problemów z bazą danych WordPress.

Uruchom tryb naprawy, gdy WordPress lub serwer zgłasza problem z konkretną tabelą bazy danych. Sam komunikat o problemie z połączeniem nie potwierdza uszkodzenia tabeli, ponieważ przyczyną mogą być błędne dane dostępowe albo awaria serwera.

Tabela oddziela sytuacje, w których naprawa tabel może być właściwym krokiem, od przypadków wymagających innej diagnozy.

Zatrzymaj procedurę, jeśli nie masz kopii, nie możesz potwierdzić właściwej instalacji albo serwer zgłasza błędy podczas operacji. Zapisz komunikaty przed dalszą diagnozą. Gdy awaria obejmuje pliki lub konfigurację, pomoc w naprawie WordPressa może objąć szerszy zakres.

Przed zmianą wp-config.php wykonaj kopię bazy i potwierdź, że można ją odtworzyć. Sam plik eksportu nie dowodzi, że kopia jest kompletna ani że dotyczy właściwej witryny.

Przygotuj kopię i dostęp w tej kolejności:

1. Zapisz dokładny komunikat błędu, adres strony i godzinę wystąpienia.
2. Wykonaj kopię bazy z panelu hostingu, phpMyAdmin lub używanego narzędzia backupowego.
3. Sprawdź nazwę bazy i prefiks tabel w konfiguracji witryny, aby nie pracować na innej instalacji.
4. Potwierdź możliwość odtworzenia kopii w środowisku testowym lub skorzystaj ze sprawdzonego procesu hostingu.
5. Przygotuj dostęp do katalogu WordPressa przez menedżer plików hostingu albo SFTP.

Przed uruchomieniem repair.php sprawdź silniki tabel. W phpMyAdmin otwórz właściwą bazę i odczytaj kolumnę Type przy tabelach. Administrator może również użyć MySQL do sprawdzenia definicji konkretnej tabeli, na przykład polecenia SHOW CREATE TABLE nazwa_tabeli. W MySQL 8.4 REPAIR TABLE dotyczy MyISAM, ARCHIVE i CSV, a nie InnoDB; przy mieszanych silnikach wynik należy ocenić dla każdej tabeli oddzielnie. Źródłem tej informacji jest dokumentacja MySQL 8.4, sprawdzona w październiku 2026 r.

Plik wp-config.php znajduje się w katalogu instalacji WordPressa i zawiera ustawienia połączenia z bazą. Pobierz jego kopię przed edycją, zachowaj oryginalne kodowanie i nie usuwaj istniejących definicji. Rejestruj czas wykonania kopii i wprowadzonych zmian.

Tryb naprawy włączysz, dodając do wp-config.php definicję WP_ALLOW_REPAIR ustawioną na true. Po zapisaniu pliku otwórz adres https://twoja-domena.pl/wp-admin/maint/repair.php, podstawiając własną domenę.

Dodaj linię:

define( 'WP_ALLOW_REPAIR', true );

Umieść definicję w sekcji konfiguracji przed komentarzem kończącym edycję wp-config.php, zwykle przed linią That's all, stop editing! Happy publishing. Jeśli stała już występuje w pliku, nie dodawaj jej ponownie. Dokumentacja WordPressa zaleca wyłączyć funkcję, gdy problem zostanie rozwiązany.

Po otwarciu strony WordPress pokaże dostępne działania naprawy. Dokumentacja WordPressa potwierdza, że strona nie wymaga zalogowania; dlatego nie przekazuj jej adresu osobom postronnym i nie pozostawiaj aktywnej stałej. Informacje sprawdziliśmy w październiku 2026 r.

Jeżeli strona nadal prosi o dodanie stałej, sprawdź, czy edytujesz wp-config.php właściwej instalacji, zapisujesz plik w odpowiednim katalogu i czy serwer odczytuje aktualną wersję. Przy błędzie składni PHP przywróć kopię pliku i popraw zmianę przed kolejną próbą.

Naprawę uruchamiaj po potwierdzeniu problemu z tabelą, a optymalizację wybieraj tylko wtedy, gdy znasz jej zakres i masz kopię bazy. Przed kliknięciem operacji sprawdź silnik każdej tabeli i porównaj wynik narzędzia z komunikatem MySQL.

Strona repair.php udostępnia opcję naprawy oraz opcję naprawy połączonej z optymalizacją tabel. Zapisz wybrany wariant i komunikaty zwrócone przy tabelach. MySQL 8.4 obsługuje REPAIR TABLE dla MyISAM, ARCHIVE i CSV, ale nie dla InnoDB; przy tabeli InnoDB nie uznawaj samego komunikatu skryptu za potwierdzenie naprawy. Dokumentacja MySQL zaleca dla niektórych problemów InnoDB odbudowę przez eksport i ponowne wczytanie albo postępowanie właściwe dla konkretnego komunikatu. Zleć ocenę administratorowi bazy lub hostingowi, jeśli wynik jest niejednoznaczny.

Tabela ułatwia odczyt typowych wyników, ale nie zastępuje oceny silnika i komunikatu MySQL.

Przerwij, jeśli tabela InnoDB nadal zgłasza problem, narzędzie zwraca błąd albo operacja nie kończy pracy. Po zakończeniu sprawdź stronę główną, logowanie do wp-admin, edycję wpisu i zapis formularza lub zamówienia.

Wyłącz tryb naprawy, usuwając definicję WP_ALLOW_REPAIR z wp-config.php natychmiast po zakończeniu operacji. Strona naprawy nie usuwa stałej automatycznie, a jej pozostawienie może udostępniać narzędzie bez logowania.

Usuń linię, zapisz plik i sprawdź działanie witryny. Otwórz /wp-admin/maint/repair.php w prywatnym oknie przeglądarki. Strona nie powinna udostępniać przycisków naprawy ani optymalizacji; może wyświetlić informację o konieczności włączenia trybu lub odmowę dostępu.

Tabela zawiera kontrolę zamknięcia dostępu i podstawowych funkcji po operacji.

Procedura jest zamknięta, gdy stała nie występuje w konfiguracji, a strona naprawy nie udostępnia operacji.

Jeśli naprawa nie przywróci działania, zachowaj komunikaty i sprawdź połączenie, silnik tabel, uprawnienia oraz logi serwera. Nie ponawiaj operacji, gdy wynik jest niejednoznaczny albo nie możesz odtworzyć kopii.

Sprawdź kolejno:

• Czy DB_NAME, DB_USER, DB_PASSWORD i DB_HOST w wp-config.php wskazują właściwą bazę i konto.
• Czy baza odpowiada w panelu hostingu lub phpMyAdmin.
• Czy prefiks tabel w wp-config.php odpowiada nazwom w bazie.
• Czy log PHP, serwera WWW lub bazy zawiera błąd z czasu awarii.
• Czy tabela używa silnika zgodnego z operacją naprawy.

Dokumentacja WordPressa wskazuje, że błąd Error establishing a database connection może wynikać z błędnych ustawień wp-config.php albo problemu po stronie hostingu. Dokumentacja MySQL opisuje osobne metody postępowania z tabelami InnoDB i MyISAM; dobór metody zależy od silnika oraz komunikatu. Obie dokumentacje sprawdziliśmy w październiku 2026 r.

Jeżeli strona wyświetla błąd 500, sprawdź log PHP i ostatnie zmiany wtyczek, motywu lub wersji PHP przed następną modyfikacją bazy. Pomocna może być procedura diagnozowania błędu 500 w WordPressie. Gdy awaria blokuje klientów lub sprzedaż, zlecenie naprawy WordPressa może objąć diagnostykę plików, konfiguracji i bazy.

Optymalizacja tabel może zmienić sposób przechowywania danych przez silnik bazy, ale sama nie gwarantuje szybszego WordPressa. Czas ładowania zależy też od zapytań, serwera, wtyczek, pamięci podręcznej i danych ładowanych przy każdym żądaniu.

Najpierw zmierz, która część witryny działa wolno, a dopiero potem dobierz działanie. Optymalizacja tabel nie usuwa automatycznie starych wpisów, transientów ani nadmiarowych opcji w wp_options. Nie poprawia też zapytania wykonywanego przez wtyczkę przy każdym wejściu na stronę.

Tabela łączy objaw z kierunkiem diagnozy.

Optymalizuj po pomiarze przyczyny spowolnienia; tryb naprawy służy do diagnozy problemów tabel, a nie jako ogólny zabieg przyspieszający stronę.

Perspektywa KC Mobile: sama optymalizacja tabel nie zastępuje sprawdzenia zapytań wykonywanych przez sklep i wtyczki. Zalecamy wskazać wolny widok i przejrzeć logi przed zmianami w bazie.

• Wtyczki do zarządzania bazą danych WordPress: porównanie i bezpieczny wybór
• WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji
• Jak włączyć WP_DEBUG w wp-config.php i sprawdzić log błędów
• Błąd strony po przeniesieniu WordPressa: jak znaleźć przyczynę i naprawić problem