Som WordPress-utvikler bruker du sannsynligvis mye tid i en FTP-klient (FileZilla). Det er en feil. Det som tar 15 minutter i FTP (f.eks. slette en cache-mappe med 100 000 filer), tar 2 sekunder i SSH-terminalen.
I denne guiden viser jeg deg et sett med kommandoer som seniorutviklere ikke kan leve uten.
Før de ti kommandoene: logg inn med nøkkel, ikke passord
Alt under forutsetter at du allerede er inne på serveren, og måten du kommer inn på avgjør om du faktisk kommer til å bruke noe av dette. Et passordspørsmål ved hver eneste tilkobling er akkurat nok friksjon til å sende deg tilbake til FTP-klienten. Lag et nøkkelpar med ssh-keygen -t ed25519, send den offentlige delen med ssh-copy-id user@server, og innloggingen blir ett ord. Lag én nøkkel per maskin i stedet for å kopiere den samme rundt mellom laptop, hjemmemaskin og byggeserver. Det koster ingenting ekstra og gir deg noe du trenger den dagen en maskin forsvinner: du fjerner én linje fra ~/.ssh/authorized_keys på serveren, og akkurat den maskinen er ute, mens alle de andre fortsetter å virke. Deler flere personer på samme driftsbruker, er det også den eneste måten å se hvem som faktisk har tilgang.
1. Diskanalyse: Hva spiser opp plassen min?
Når webhotellet roper “Quota Exceeded”, hjelper ikke FileZilla. Bruk dette:
Du (disk usage)
## Vis mapper i nåværende katalog, sortert etter størrelse
du -h --max-depth=1 | sort -hrNcdu (ncurses disk usage)
Hvis du kan, kjør ncdu. Det er en interaktiv manager du navigerer med piltastene. På en travel server er det første steget å se hva som fyller disken før du sletter caches og logger. du bruker du når du trenger et tall å lime inn i en sak, ncdu når du ennå ikke vet hva du leter etter. Begge går gjennom hele katalogtreet, og det er ikke gratis: på en stor uploads-katalog holder de disken opptatt i et minutt, og på delt webhotell merkes det som tregere sidevisninger mens de kjører. Pek dem mot en underkatalog i stedet for hjemmekatalogen hvis nettstedet har trafikk. Ingen av dem sier noe om hva du trygt kan fjerne, og på en WordPress-installasjon er den vanligste overraskelsen ikke bilder i det hele tatt, men en node_modules-katalog som ble liggende igjen i temaet etter et byggesteg og som aldri hadde noe på serveren å gjøre.
2. Logger: Debugging i sanntid
I stedet for å laste ned debug.log, åpne den i Notisblokk og lete etter feil… se den live!
Tail -f
## Følg de siste linjene i filen i sanntid
tail -f wp-content/debug.logOppdater nå siden i nettleseren, og feilene vil dukke opp på skjermen. Avslutt med Ctrl+C. Å lese loggen direkte er riktig så lenge du kan utløse feilen på kommando. Klarer du ikke det, har linjen du er ute etter for lengst rullet forbi, og da begynner du heller med tail -n 200 wp-content/debug.log og leser bakover. tail -f tar flere filer samtidig, så tail -f wp-content/debug.log /var/log/nginx/error.log viser deg PHP-feilen og webserverens versjon av samme hendelse ved siden av hverandre, med filnavn som skillelinje. To ting lurer folk her. Filen finnes bare når WP_DEBUG_LOG er slått på i wp-config.php, så et tomt vindu betyr som regel at logging er av, ikke at nettstedet er friskt. Og ingenting roterer filen av seg selv, så et nettsted som kaster en advarsel ved hvert kall skriver seg selv full disk over tid.
3. Søke i filer: Hvor er den koden?!
Leter du etter hvor add_image_size ble brukt? Ikke last ned hele prosjektet.
Grep
## Søk etter frasen "add_image_size" i alle PHP-filer rekursivt
grep -r "add_image_size" .Den fulle formen bruker du når du vil lese koden rundt treffet, grep -rl når du bare vil vite hvilken utvidelse som eier en oppførsel. I et tema koster det nesten ingenting, i wp-content/plugins koster det en del, fordi rekursjonen går inn i hver eneste vendor-katalog den finner. --include='*.php' og --exclude-dir=node_modules er de to tilleggene som betaler seg umiddelbart. Bekreft et treff ved å åpne filen på det stedet, ikke ved å telle antall treff: det samme funksjonsnavnet står i utvidelsens egen kode, i dokumentasjonsblokken over den og i oversettelsesfilen, og bare ett av de tre stedene er definisjonen.
4. Rettigheter: Fiks “403 forbidden”
Ofte etter migrering har filer feil rettigheter. Husk regelen:
- Mapper: 755
- Filer: 644
Find + chmod
Ikke gjør det manuelt. Automatiser det:
## Sett 755 for alle mapper
find . -type d -exec chmod 755 {} \;
## Sett 644 for alle filer
find . -type f -exec chmod 644 {} \;Kjør dette når du har et symptom, en 403 eller en opplasting som feiler, ikke som rutinevedlikehold. En chmod over hele treet jevner ut hvert bevisste unntak på installasjonen, og det viktigste av dem er wp-config.php: den bærer databasepassordet og hører hjemme på 640 eller strammere, ikke på de 644 løkken nettopp ga den. Løkken rører dessuten bare filer din egen bruker eier, så på et webhotell der webserveren kjører som en annen konto kan den fikse ingenting uten å melde fra om det. Kontroller med ls -l wp-config.php og ved å laste siden som ikke virket, aldri ved å kjøre den samme kommandoen en gang til.
5. Backup: Raskt arkiv
Vil du ha en rask backup før oppdatering? Ikke kopier via FTP. Pakk det på serveren.
Tar
## Lag arkiv backup.tar.gz av nåværende katalog
tar -czf backup.tar.gz .Utpakking:
tar -xzf backup.tar.gzÅ pakke på serveren er riktig trekk før en oppdatering, fordi arkivet aldri går gjennom linjen din. Det er likevel ingen sikkerhetskopistrategi: filen ligger på samme disk som nettstedet, så den overlever en mislykket oppdatering, men ikke at disken ryker. Legg til --exclude='wp-content/cache' med mindre du vil arkivere nøyaktig det du straks skal slette. Og se inn i den med tar -tzf backup.tar.gz | head før du stoler på den, for et arkiv som ble kuttet av en full disk ser ut som en helt vanlig fil i katalogen.
6. Database (WP-CLI)
Har du WP-CLI på serveren, og det bør du ha, trenger du ikke phpMyAdmin. Ingen eksport som ryker på tidsavbrudd i nettleseren, ingen opplastingsgrense ved import.
## Eksporter databasen
wp db export backup.sql
## Importer databasen
wp db import backup.sql
## Tøm databasen (vær forsiktig!)
wp db resetDumpen skrives til serverdisken, ikke gjennom linjen din. På en nettbutikk som har gått noen år er det forskjellen mellom en eksport på sekunder og en nettleser som gir opp midt i wp_postmeta. WP-CLI kjører som din skallbruker og ikke gjennom webserveren, så opplastingsgrenser og max_execution_time slutter å gjelde. Det den ikke kan overse, er at nettstedet er i drift: wp db import slipper tabellene og bygger dem opp igjen mens noen står i kassen, så et vedlikeholdsvindu er en del av kommandoen og ikke et tillegg. Resultatet sjekker du med en enkelt wp option get siteurl, som feiler høyt og med en gang dersom importen bare kom halvveis.
7. Massesletting av filer
Å slette en cache-mappe med en million små filer over FTP kan ta en time, fordi FTP kvitterer for hver eneste fil.
Rm
## Slett mappen og alt i den (ingen angremulighet!)
rm -rf wp-content/cache/Tidsbruk: et halvt sekund. Det finnes ingen papirkurv. Ikke skriv stien fra hukommelsen, bruk tabulator til å fullføre den, så blir ikke wp-content/cache/ til wp-content/. Dette er riktig verktøy for en cache-katalog og nesten aldri riktig for noe annet, siden det verken spør først eller lar seg angre etterpå. Vanen som redder deg er å kjøre ls mot nøyaktig samme sti først, og slette først når listen stemmer med det du hadde i hodet. Se særlig på slutten av stien, for et feilplassert mellomrom gjør ett mål om til to, og det andre er som regel katalogen over. På et nettsted med trafikk bygger utvidelsen cachen opp igjen ved neste forespørsel, så prisen er én treg sidelasting, ikke nedetid.
8. Synkronisering av filer mellom maskiner
FTP laster opp alt på nytt hver gang. rsync sammenligner de to sidene først og sender bare differansen.
Rsync
## Tørrkjør først: vis hva som ville blitt kopiert, endre ingenting
rsync -avzn --exclude 'cache/' ./wp-content/uploads/ user@server:/var/www/eksempel.no/wp-content/uploads/Fjern n fra -avzn når fillisten ser riktig ut. To detaljer avgjør resultatet. Skråstreken på slutten av kildestien betyr “innholdet i denne katalogen”; uten den ender du med uploads/uploads. Og --delete speiler også slettinger, altså fjerner alt på målet som mangler lokalt. Kjørt fra en utdatert lokal kopi rydder den bort mediebiblioteket i stedet for å synkronisere det. rsync må dessuten finnes i begge ender, og på enkelte delte webhotell er den ikke installert på serveren. Sjekk med ssh user@server 'which rsync' før du bygger en rutine på den.
9. Portvideresending: nå databasen bak brannmuren
Managed webhotell stenger MySQL mot omverdenen. Port 3306 svarer bare på localhost, skrivebordsklienten går i tidsavbrudd, og i kontrollpanelet sitter du igjen med phpMyAdmin. Du trenger ikke en åpen port, du trenger en tunnel.
Ssh -L
## Koble lokal port 3307 til serverens MySQL, uten å åpne et fjernskall
ssh -N -L 3307:127.0.0.1:3306 user@serverLa det terminalvinduet stå åpent og pek TablePlus, DBeaver eller vanlige mysql mot 127.0.0.1:3307. -N betyr “ingen fjernkommando”, økten gjør ingenting annet enn å videresende. Samme grep når alt annet som bare lytter lokalt på serveren: Redis på 6379, en staging-applikasjon på 8080, et endepunkt som aldri var ment å være offentlig. Velg en lokal port som faktisk er ledig, for ssh melder fra om at bindingen feilet og holder likevel økten åpen. Det ser ut som en fungerende tunnel helt til første spørring henger.
10. Domenebytte: tørrkjøring før du skriver til databasen
Etter en migrering står det gamle domenet fortsatt i databasen, og en god del av det ligger inne i serialiserte PHP-tabeller der hver streng bærer sin egen lengde. Et vanlig UPDATE ... REPLACE bytter teksten og lar lengden bli stående feil, og da kommer widgets, temainnstillinger og page builder-oppsett tilbake tomme. WP-CLI forstår serialisering, og viser deg hva den har tenkt å røre før den rører det.
Wp search-replace --dry-run
## Tell opp hva som ville endret seg, skriv ingenting
wp search-replace 'https://staging.eksempel.no' 'https://eksempel.no' --dry-run --all-tables-with-prefix --report-changed-onlyDu får en tabell med antall treff per kolonne. Når tallene stemmer med forventningen, kjører du samme kommando uten --dry-run. Legg til --precise hvis nettstedet har nøstet serialisering, det tvinger den tregere veien gjennom PHP i stedet for snarveien i SQL, og --recurse-objects når serialiserte objekter er involvert. Ta en wp db export først uansett: search-replace har ingen angreknapp.
Når webhotellet bare tilbyr SFTP
Enkelte delte pakker selger SSH og leverer SFTP, altså filoverføring over samme protokoll uten et skall bak. Du oppdager det i det øyeblikket ssh user@host 'ls' svarer med exec request failed on channel 0. Ingenting i denne guiden som kjører på serveren overlever det: verken du, tar eller WP-CLI, fordi det ikke finnes noen prosess å kjøre dem i. Overføringslaget virker fortsatt, så sftp og rsync over det flytter filer raskere og tryggere enn en klient med vindu, og databasearbeidet flytter tilbake til nettleseren, til phpMyAdmin og en sikkerhetskopiutvidelse. Før du slår deg til ro med det, sjekk om leverandøren tilbyr skall på en annen port eller skrur det på ved henvendelse, for hos flere av dem er dette en innstilling og ikke en produktgrense. Finnes det virkelig ikke i den pakken, har du et konkret argument for å flytte, siden hver eneste arbeidsflyt over er stengt for deg der.
Oppsummering
SSH-terminalen biter ikke. Den lar deg jobbe med hastigheten til serverdisken, ikke internetthastigheten din. Start med ncdu og tail -f.
