SSH dla WordPress developera: 10 komend, które uratują ci życie

Jako WordPress Developer, pewnie spędzasz dużo czasu w kliencie FTP (FileZilla) lub panelu hostingu. To błąd. To, co w FTP zajmuje 15 minut (np. usuwanie folderu cache z 100,000 plików), w terminalu SSH zajmuje 2 sekundy.

W tym poradniku pokażę Ci zestaw komend, bez których senior developerzy nie wyobrażają sobie pracy.

#Zanim przejdziesz do dziesięciu komend: klucz zamiast hasła

Wszystko poniżej zakłada, że jesteś już na serwerze, a sposób logowania decyduje o tym, czy w ogóle będziesz z tego korzystać. Pytanie o hasło przy każdym połączeniu to dokładnie ta doza tarcia, która odsyła człowieka z powrotem do FileZilli. Wygeneruj parę kluczy przez ssh-keygen -t ed25519, wyślij część publiczną komendą ssh-copy-id user@serwer i logowanie skraca się do jednego słowa. Klucz zabezpiecz hasłem, a hasło wpisz raz na sesję do ssh-agent, bo klucz bez frazy to jeden skradziony laptop od dostępu produkcyjnego. Kiedy klucze już działają, poproś hosting o wyłączenie logowania hasłem albo zrób to sam w sshd_config, bo dopóki hasło jest aktywne, boty dalej je zgadują, a Ty tylko przestałeś je widzieć.

#1. Analiza dysku: co zjada moje miejsce?

Kiedy hosting krzyczy “Quota Exceeded”, FileZilla nie pomoże. Użyj tego:

#du (disk usage)

## Pokaż foldery w bieżącym katalogu, posortowane wg rozmiaru
du -h --max-depth=1 | sort -hr

#ncdu (ncurses disk usage)

Jeśli możesz, wpisz ncdu. To interaktywny menedżer, po którym nawigujesz strzałkami. Na zagraconym serwerze nic tak szybko nie pokazuje, co realnie zajmuje miejsce, zanim zaczniesz czyścić cache i logi. Po du sięgasz, gdy potrzebujesz liczby do wklejenia w zgłoszenie, po ncdu wtedy, gdy jeszcze nie wiesz, czego szukasz. Obie komendy przechodzą całe drzewo katalogów i nie jest to darmowe: na dużym uploads potrafią zająć dysk na minutę, a na współdzielonym hostingu widać to jako wolniejsze ładowanie strony w tym czasie. Jeśli witryna ma ruch, wskaż konkretny podkatalog zamiast katalogu domowego. Żadna z nich nie odpowie Ci, czy miejsce wolno odzyskać, a na typowej instalacji WordPressa podejrzani są zwykle ci sami: paczki zostawione przez wtyczkę backupową w wp-content, stare foldery roczne w uploads i plik error_log odkładany katalog po katalogu.

#2. Logi: debugowanie w czasie rzeczywistym

Zamiast ściągać plik debug.log, otwierać go notatnikiem i szukać błędu… oglądaj go na żywo!

#tail -f

## ŚLedź ostatnie linie pliku w czasie rzeczywistym
tail -f wp-content/debug.log

Teraz odśwież stronę w przeglądarce, a błędy same pojawią się na ekranie. Zakończ skrótem Ctrl+C. Podgląd na żywo ma sens, dopóki potrafisz wywołać błąd na żądanie. Gdy nie potrafisz, interesująca linia dawno przewinęła się w górę, więc zacznij od tail -n 200 wp-content/debug.log i czytaj wstecz. Przy hałaśliwym logu dopisz filtr, tail -f wp-content/debug.log | grep -i fatal zostawia na ekranie tylko to, co wywala stronę, zamiast setek ostrzeżeń o przestarzałych funkcjach. Dwie rzeczy mylą tu najczęściej. Plik powstaje wyłącznie wtedy, gdy w wp-config.php włączone jest WP_DEBUG_LOG, więc pusty terminal zwykle znaczy, że logowanie jest wyłączone, a nie że strona jest zdrowa. I nic tego pliku nie rotuje, więc serwis rzucający notice przy każdym żądaniu urośnie nim do rozmiaru, przez który wrócisz do sekcji o zajętości dysku.

#3. Szukanie w plikach: gdzie jest ten kod?!

Szukasz, w którym pliku użyto funkcji add_image_size? Nie ściągaj całego projektu.

#grep

## Szukaj frazy "add_image_size" we wszystkich plikach PHP rekurencyjnie
grep -r "add_image_size" .

Jeśli chcesz tylko listę plików (bez treści):

grep -rl "add_image_size" .

Pełnej wersji używasz, gdy chcesz zobaczyć kod wokół trafienia, wersji z -l, gdy interesuje Cię tylko, która wtyczka odpowiada za dane zachowanie. W motywie to koszt pomijalny, w wp-content/plugins już nie, bo rekurencja wchodzi w każdy katalog vendor, jaki napotka. Dlatego warto dopisać --include='*.php' i --exclude-dir=node_modules. Trafienie zweryfikuj, otwierając plik w tym miejscu, a nie licząc wyniki: ta sama nazwa funkcji pojawia się w kodzie wtyczki, w jej komentarzu dokumentacyjnym i w pliku tłumaczeń, a definicja jest tylko w jednym z tych miejsc.

#4. Uprawnienia: naprawa “403 forbidden”

Często po migracji pliki mają złe uprawnienia. Pamiętaj zasadę:

• Katalogi: 755
• Pliki: 644

#find + chmod

Nie rób tego ręcznie. Użyj automatu:

## Ustaw 755 dla wszystkich katalogów
find . -type d -exec chmod 755 {} \;

## Ustaw 644 dla wszystkich plików
find . -type f -exec chmod 644 {} \;

Uruchamiaj to, gdy masz objaw: błąd 403 albo nieudany upload. Nie jako profilaktykę. Masowy chmod zrównuje wszystkie świadome wyjątki na instalacji, a najważniejszy z nich to wp-config.php, który trzyma dane dostępowe do bazy i powinien mieć 640 lub mniej, a nie 644, które właśnie mu nadałeś. Pętla dotyka tylko plików należących do Twojego użytkownika, więc na hostingu, gdzie serwer WWW działa na innym koncie, potrafi nie naprawić niczego i nie zgłosić przy tym błędu. Sprawdzaj efekt przez ls -l wp-config.php i przez wejście na stronę, która nie działała, nigdy przez powtórzenie tej samej komendy.

#5. Kopia zapasowa: szybki backup

Chcesz zrobić szybki backup przed aktualizacją? Nie kopiuj przez FTP (trwa wieki). Spakuj na serwerze.

#tar

## Stwórz archiwum backup.tar.gz z całego katalogu
tar -czf backup.tar.gz .

Rozpakowanie:

tar -xzf backup.tar.gz

Pakowanie na serwerze jest właściwym ruchem przed aktualizacją wtyczki, bo archiwum nie przechodzi przez Twoje łącze. Nie jest za to strategią backupu: paczka leży na tym samym dysku co strona, więc przetrwa nieudaną aktualizację, ale nie awarię wolumenu. Dopisz --exclude='wp-content/cache', chyba że chcesz zarchiwizować dokładnie to, co za chwilę skasujesz. Zanim uwierzysz archiwum, zajrzyj do niego przez tar -tzf backup.tar.gz | head, bo paczka ucięta przez pełny dysk w listingu katalogu wygląda jak każdy inny plik.

#6. Baza danych (wp-CLI)

Jeśli masz WP-CLI (a powinieneś), nie musisz logować się do phpMyAdmin.

## Eksport bazy (backup)
wp db export backup.sql

## Import bazy
wp db import backup.sql

## Wyczyść bazę (uwaga!)
wp db reset

WP-CLI wygrywa w chwili, w której baza jest na tyle duża, że przeglądarka odpuszcza w połowie eksportu. Działa jako Twój użytkownik powłoki, a nie przez serwer WWW, więc limity uploadu i czasu wykonania PHP przestają obowiązywać. Czego nie pominie, to fakt, że strona żyje: wp db import kasuje i odtwarza tabele w trakcie, gdy ktoś czyta stronę, więc okno serwisowe jest częścią tej komendy, a nie dodatkiem. Wynik sprawdzisz jednym wp option get siteurl, które zgłosi błąd natychmiast, jeśli import wszedł tylko w połowie.

#7. Masowe usuwanie plików

Usuwanie folderu cache wtyczki, który ma milion małych plików, przez FTP może zająć godzinę (FTP kasuje plik po pliku).

#rm

## Usuń folder i wszystko w środku (bez powrotu!)
rm -rf wp-content/cache/

Czas trwania: 0.5 sekundy. To właściwe narzędzie do katalogu z cache i prawie nigdy właściwe do czegokolwiek innego, bo nie ma tu pytania o potwierdzenie ani drogi powrotnej. Nawyk, który ratuje, jest jeden: najpierw ls na dokładnie tej samej ścieżce, kasowanie dopiero wtedy, gdy listing zgadza się z tym, co masz w głowie. Szczególnie pilnuj końcówki ścieżki, bo przypadkowa spacja robi z jednego celu dwa, a tym drugim bywa katalog nadrzędny. Na ruchliwym serwisie wtyczka odbuduje cache przy najbliższym żądaniu, więc płacisz jednym wolniejszym wczytaniem strony, a nie niedostępnością.

#8. Synchronizacja plików między maszynami

FTP za każdym razem wysyła wszystko od nowa. rsync najpierw porównuje obie strony i przesyła wyłącznie różnicę, więc synchronizacja katalogu uploads przestaje być pretekstem na kawę.

#rsync

## Najpierw na sucho: pokaż co zostałoby skopiowane, nie zmieniaj niczego
rsync -avzn --exclude 'cache/' ./wp-content/uploads/ user@serwer:/var/www/przyklad.pl/wp-content/uploads/

Kiedy lista plików wygląda sensownie, usuń n z -avzn. Dwa nawyki warto mieć na stałe. Ukośnik na końcu ścieżki źródłowej znaczy “zawartość tego katalogu”; bez niego wyląduje Ci uploads/uploads. A --delete odwzorowuje też kasowanie, czyli usuwa z serwera to, czego nie ma lokalnie. Odpalone z nieaktualnej kopii na żywym sklepie nie synchronizuje biblioteki mediów, tylko ją czyści.

Na części polskich hostingów współdzielonych rsync nie jest zainstalowany po stronie serwera, a bez niego komenda nie zadziała, bo potrzebuje binarki po obu stronach. Sprawdź to jednym ssh user@serwer 'which rsync' zanim zaplanujesz na tym wdrożenie.

#9. Tunelowanie portów: dostęp do bazy zza firewalla

Hostingi zarządzane zwykle zamykają MySQL na świat. Port 3306 odpowiada tylko z localhosta, więc klient na desktopie się nie połączy, a w panelu zostaje phpMyAdmin. Nie potrzebujesz otwartego portu, potrzebujesz tunelu.

#ssh -L

## Przepnij lokalny port 3307 na MySQL serwera, bez otwierania zdalnej powłoki
ssh -N -L 3307:127.0.0.1:3306 user@serwer

Zostaw ten terminal otwarty i ustaw w TablePlus, DBeaverze albo w zwykłym kliencie mysql adres 127.0.0.1:3307. -N znaczy “żadnej zdalnej komendy”, sesja tylko przekazuje ruch. Tym samym sposobem dosięgniesz wszystkiego, co nasłuchuje na localhoście: Redisa na 6379, aplikacji stagingowej na 8080, endpointu, który nigdy nie miał być publiczny. Wybierz lokalny port, który faktycznie jest wolny, bo ssh zgłosi nieudany bind i mimo to utrzyma sesję, co wygląda na działający tunel aż do pierwszego zapytania, które zawiśnie.

#10. Zmiana domeny: próba na sucho przed przepisaniem bazy

Po migracji w bazie siedzi stara domena, a spora jej część leży w serializowanych tablicach PHP, gdzie każdy string ma zapisaną własną długość. Zwykłe UPDATE ... REPLACE podmieni tekst i zostawi błędną długość, więc widgety, opcje motywu i układy z page buildera wrócą puste. WP-CLI rozumie serializację i zanim cokolwiek ruszy, pokaże Ci co zamierza ruszyć.

#wp search-replace --dry-run

## Policz co by się zmieniło, nie zapisuj nic
wp search-replace 'https://staging.przyklad.pl' 'https://przyklad.pl' --dry-run --all-tables-with-prefix --report-changed-only

Dostajesz tabelę z liczbą trafień w każdej kolumnie. Kiedy liczby zgadzają się z tym, czego się spodziewasz, powtórz komendę bez --dry-run. Dodaj --precise, jeśli strona ma zagnieżdżoną serializację, bo wymusza wolniejszą ścieżkę po stronie PHP zamiast skrótu po SQL, a --recurse-objects, gdy w grę wchodzą serializowane obiekty. Tak czy inaczej zrób najpierw wp db export: search-replace nie ma cofnięcia.

#Gdy hosting daje tylko SFTP

Część pakietów współdzielonych reklamuje SSH, a dostarcza SFTP, czyli transfer plików tym samym protokołem, tylko bez powłoki po drugiej stronie. Dowiadujesz się o tym w momencie, gdy ssh user@host 'ls' odpowiada exec request failed on channel 0. Nic z tego poradnika, co wykonuje się na serwerze, tam nie zadziała: ani du, ani tar, ani WP-CLI, bo nie ma procesu, który mógłby je uruchomić. Warstwa transferu nadal działa, więc sftp i rsync po nim przenoszą pliki szybciej i pewniej niż klient z oknem, a robota przy bazie wraca do przeglądarki, do phpMyAdmina i wtyczki backupowej. Zanim się z tym pogodzisz, sprawdź, czy dostawca nie wystawia powłoki na innym porcie albo nie włącza jej na zgłoszenie, bo u kilku polskich hostingów to ustawienie w panelu, a nie granica usługi. Jeśli faktycznie tego nie ma, masz twardy argument za migracją, bo cały ten artykuł jest w tym pakiecie zamknięty.

#Podsumowanie

Terminal SSH nie gryzie. Pozwala Ci pracować z prędkością dysku serwera, a nie prędkością Twojego łącza internetowego. Zacznij od ncdu i tail -f, zobaczysz, że nie będziesz chciał wracać do klikania myszką.