Moderne WordPress Deployment 2026: FTP vs SSH/Git | WPPoland

Mariusz Szatkowski

Slutt å bruke FTP: Moderne WordPress deployment med SSH, Git & keys

Sist verifisert: 12. oktober 2026

15 min lesetid

Guide

Hvis du ser “Feil 29” i Total Commander eller “Tidsavbrudd for tilkobling” i FileZilla, sender universet deg en melding. Slutt å bruke FTP.

I 2010 var FTP standard. I 2026 er dra-og-slipp av filer til en produksjonsserver hensynsløst. Det fører til:

Nedetid: Hva skjer hvis internettet ditt kutter ut mens du laster opp functions.php?
Sikkerhetsrisiko: FTP sender passord i klartekst (med mindre du bruker FTPS).
Ingen historikk: Hvem endret den filen? Når? Hvorfor?

Å redigere PHP-filer direkte over FTP i produksjon skaper unødvendig risiko for feil og nedetid. En moderne utrullingspipeline basert på kryptografiske nøkler, versjonskontroll med Git og automatiserte verktøy sikrer forutsigbare oppdateringer og øyeblikkelig feilretting.

#Hvorfor FTP er usikkert for drift av WordPress

FTP (File Transfer Protocol) overfører brukernavn, passord og filinnhold ukryptert over nettverket. Enhver aktør på samme lokale nettverk, en usikret ruter eller en delt vertsplattform kan fange opp legitimasjonen. I tillegg mangler protokollen mekanismer for versjonssporing, transaksjonssikkerhet og samtidig samhandling mellom flere utviklere.

Selv om SFTP og FTPS løser krypteringen av transportlaget, fjerner de ikke sårbarhetene i selve arbeidsflyten. Utvikleren velger filer manuelt, overskriver aktive produksjonsfiler og risikerer ufullstendige overføringer. Hvis nettforbindelsen brytes midt under opplasting av en sentral kjernefil eller plugin, havner nettstedet i en tilstand med ufullstendig kode og feilmeldinger mot sluttbrukere.

Den etablerte standarden for profesjonelle team i 2026 hviler på tre lag: SSH for kryptert tilgang og sikker nøkkelautentisering, Git for versjonskontroll og revisjonsspor, og automatiserte deploy-skript for bygging, migrering og atomisk aktivering.

#Hvordan sette opp SFTP og SSH-nøkler for WordPress

Passordbasert innlogging over SSH er utsatt for kontinuerlige brute-force-angrep mot åpne porter. Nøkkelbasert autentisering fjerner denne sårbarheten fullstendig, fordi serveren kun slipper inn klienter som besitter den private delen av nøkkelparet.

#Generer et ED25519 nøkkelpar

ED25519-nøkler er raskere, mer kompakte og kryptografisk sterkere enn eldre RSA-nøkler. Generer et dedikert nøkkelpar fra terminalen:

ssh-keygen -t ed25519 -C "[email protected]"

Kommandoen oppretter to filer: ~/.ssh/id_ed25519 (den hemmelige private nøkkelen som aldri skal deles eller forlate maskinen din) og ~/.ssh/id_ed25519.pub (den offentlige nøkkelen som trygt kan legges inn på serveren).

#Kopier den offentlige nøkkelen til serveren

Bruk ssh-copy-id for å legge den offentlige nøkkelen direkte inn i ~/.ssh/authorized_keys på målserveren:

ssh-copy-id [email protected]

Etter denne operasjonen autentiseres forbindelsen automatisk uten passordinntasting.

#Konfigurer ssh-agent og SSH-konfigurasjonsfilen

For å unngå å taste passfrasen for den private nøkkelen ved hver tilkobling, startes ssh-agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Opprett eller oppdater ~/.ssh/config med ryddige aliaser for miljøene dine:

Host wppoland-prod
    HostName 198.51.100.42
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host wppoland-staging
    HostName 198.51.100.43
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Nå kobler du til med en enkel kommando som ssh wppoland-prod, uten å huske IP-adresser eller håndtere passord manuelt. Hver utvikler på teamet skal ha sitt eget personlige nøkkelpar, og private nøkler skal aldri deles mellom medarbeidere.

#Hvordan strukturere et Git-repository for WordPress

En klassisk feil ved overgang fra FTP er å legge hele WordPress-roten, inkludert opplastede bilder, kjernearkiv og database-dumper, inn i Git. Et ryddig prosjekt skal kun spore kode du selv har skrevet og forvalter.

#Modular oppbygging av repositoriet

Repositoriet inneholder kun egendefinerte temaer, egne utvidelser og prosjektspesifikke mu-plugins. Selve WordPress-kjernen og tredjeparts utvidelser hentes inn via Composer eller holdes utenfor versjonskontroll:

wordpress-prosjekt/
├── .gitignore
├── composer.json
├── wp-content/
│   ├── themes/
│   │   └── wppoland-theme/    # spores i Git
│   ├── plugins/
│   │   └── wppoland-custom/   # spores i Git
│   └── mu-plugins/            # spores i Git
└── wp-config.php              # spores IKKE i Git

#Nødvendige utelukkelsesregler i gitignore

Filen .gitignore skal eksplisitt utelukke kjernefiler, opplastet medieinnhold og sensitive driftsdata:

/wp-admin/
/wp-includes/
/wp-content/uploads/
/wp-content/upgrade/
wp-config.php
.env
*.log
node_modules/
vendor/

Å holde wp-content/uploads/ utenfor Git forhindrer at depotet eser ut i størrelse med gigabyte av medieelementer som hører hjemme på ekstern objektlagring som S3 eller Cloudflare R2.

#Styring av avhengigheter med Composer

Ved å bruke Composer og WPackagist kan eksterne utvidelser defineres med eksakte versjonsnumre:

{
  "require": {
    "wpackagist-plugin/advanced-custom-fields": "^6.0",
    "wpackagist-plugin/wordpress-seo": "^22.0",
    "wpackagist-plugin/wp-super-cache": "^1.9"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ]
}

Kjør composer install --no-dev --optimize-autoloader på serveren eller under byggeprosessen i CI, slik at alle miljøer kjører nøyaktig identiske versjoner.

#Hvordan deploye WordPress med rsync over SSH

Git håndterer kildekodehistorikk, mens rsync er det mest effektive verktøyet for å overføre kompilerte produksjonsfiler til serveren. Verktøyet beregner sjekksummer og sender kun de endrede blokkene i filene.

#Forskjeller mellom rsync, SCP og FTP

SCP kopierer alle filer i sin helhet uansett om bare én linje er endret. FTP mangler deltatilnærming og verifisering av sjekksummer under overføring. rsync sammenligner filstørrelser og tidsstempler, beregner binære endringer og overfører kun differansen over en kryptert SSH-forbindelse.

#Sikker rsync-kommando med tørkjøring

Kjør alltid en testoverføring med --dry-run før du oppdaterer et produksjonsmiljø:

rsync -avz --dry-run --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@server:/var/www/html/

Når listen over endrede filer er verifisert, fjernes --dry-run for å utføre den faktiske synkroniseringen:

rsync -avz --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@server:/var/www/html/

Flagget --delete fjerner filer på serveren som ikke lenger finnes i det lokale bygget, slik at gammel kode ikke blir liggende igjen. Utelukkelsesmønstrene hindrer at opplastede mediefiler og miljøkonfigurasjoner blir slettet eller overskrevet.

#CI/CD-arbeidsflyt for WordPress med GitHub Actions

En automatisert pipeline via GitHub Actions bygger frontend-ressurser, sjekker kodestandarder med PHP_CodeSniffer og ruller ut koden automatisk ved push til hovedgrenen.

name: Deploy WordPress

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Sjekk ut kode
        uses: actions/checkout@v4

      - name: Sett opp PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          tools: composer

      - name: Installer avhengigheter
        run: composer install --no-dev --optimize-autoloader

      - name: PHP linting og standarder
        run: vendor/bin/phpcs --standard=WordPress wp-content/themes/wppoland-theme/

      - name: Bygg frontend-filer
        run: |
          npm ci
          npm run build

      - name: Deploy med rsync
        uses: burnett01/[email protected]
        with:
          switches: -avz --delete --exclude='.git' --exclude='wp-config.php' --exclude='wp-content/uploads'
          path: ./
          remote_path: /var/www/html/
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Tøm hurtigbuffer
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: wp cache flush --path=/var/www/html

Autentiseringsdata lagres trygt i GitHub Secrets, og ingen passord eller private nøkler skrives direkte i konfigurasjonsfilen.

#Viktige WP-CLI-kommandoer for administrasjon over SSH

Kommandolinjeverktøyet WP-CLI lar deg drifte alle sider av WordPress direkte fra terminalen over SSH, uten å åpne administrasjonspanelet i nettleseren.

#Kjerneoppdateringer, utvidelser og vedlikehold

# Oppdater kjerne og databaseskjema
wp core update
wp core update-db

# Administrasjon av utvidelser
wp plugin install wordpress-seo --activate
wp plugin update --all
wp plugin deactivate wordfence

# Optimalisering av databasetabeller
wp db optimize
wp db repair

# Regenerer sikkerhetsnøkler (salts)
wp config shuffle-salts

# Sett nettstedet i vedlikeholdsmodus under oppdateringer
wp maintenance-mode activate
wp maintenance-mode deactivate

#Presis søk og erstatt i databasen

Ved flytting mellom domener eller fra test til produksjon inneholder WordPress-databasen serialiserte PHP-arrayer i wp_options og wp_postmeta. Et vanlig tekstsøk i SQL vil ødelegge strenglengdene og gjøre dataene uleselige for PHP. WP-CLI beregner lengdene på nytt automatisk:

wp search-replace 'https://staging.wppoland.com' 'https://wppoland.com' --all-tables --precise

#Fjernkjøring av WP-CLI via SSH-aliaser

Du kan konfigurere snarveier i ~/.wp-cli/config.yml på din lokale datamaskin for å kjøre kommandoer direkte på fjernservere:

@prod:
  ssh: [email protected]/var/www/html
@staging:
  ssh: [email protected]/var/www/html

Deretter kjører du kommandoer lokalt:

wp @prod plugin list
wp @prod cache flush
wp @prod cron event run --due-now

#Miljøkonfigurasjon med phpdotenv og wp-config

Tradisjonelt legges databasetilgang direkte i wp-config.php. Dette gjør det umulig å versjonere filen trygt. En mer robust løsning skiller konfigurasjon fra kode ved hjelp av miljøvariabler og vlucas/phpdotenv.

#Oppsett av .env for ulike miljøer

I prosjektets rotmappe defineres miljøverdiene i en lokal .env-fil som aldri sjekkes inn i Git:

DB_NAME=wppoland_prod
DB_USER=wp_user
DB_PASSWORD=hemmelig_sterkt_passord
DB_HOST=localhost
WP_HOME=https://wppoland.com
WP_SITEURL=https://wppoland.com
WP_ENVIRONMENT_TYPE=production

I wp-config.php lastes verdiene inn via Composers autoloader:

<?php
require_once __DIR__ . '/vendor/autoload.php';

if ( file_exists( __DIR__ . '/.env' ) ) {
    $dotenv = DotenvDotenv::createImmutable( __DIR__ );
    $dotenv->load();
}

define( 'DB_NAME', $_ENV['DB_NAME'] );
define( 'DB_USER', $_ENV['DB_USER'] );
define( 'DB_PASSWORD', $_ENV['DB_PASSWORD'] );
define( 'DB_HOST', $_ENV['DB_HOST'] ?: 'localhost' );
define( 'WP_HOME', $_ENV['WP_HOME'] );
define( 'WP_SITEURL', $_ENV['WP_SITEURL'] );
define( 'WP_ENVIRONMENT_TYPE', $_ENV['WP_ENVIRONMENT_TYPE'] ?: 'production' );

define( 'WP_DEBUG', $_ENV['WP_ENVIRONMENT_TYPE'] !== 'production' );
define( 'WP_DEBUG_LOG', $_ENV['WP_ENVIRONMENT_TYPE'] !== 'production' );
define( 'WP_DEBUG_DISPLAY', false );

Med dette oppsettet forblir wp-config.php uendret på tvers av lokal utvikling, staging-miljø og produksjon.

#Hvordan kjøre atomiske WordPress-deployments

Utrulling med git pull direkte i produksjonsmappen eller filopplasting via FTP skaper en sårbar overgangstilstand. Mens filene overføres kan besøkende hente PHP-filer fra to ulike versjoner samtidig, noe som fører til fatale kjøretidsfeil.

#Mappestruktur for atomiske utrullinger

Atomisk utrulling løser dette ved å skille bygg, fellesressurser og aktiv versjon etter mønster fra Deployer og Capistrano:

/var/www/minside/
├── current -> /var/www/minside/releases/20261012120000/
├── releases/
│   ├── 20261012100000/
│   ├── 20261012110000/
│   └── 20261012120000/
└── shared/
    ├── .env
    └── wp-content/
        └── uploads/

#Atomisk bytte av symbolsk lenke

Hver utrulling plasserer koden i en ny katalog under releases/ merket med tidsstempel.
Det opprettes symbolske lenker til delte ressurser i shared/, som medieopplastinger og .env.
Avhengigheter installeres, skript bygges og helsesjekker utføres.
Når bygget er godkjent, oppdateres symlinken current i én atomisk operasjon på filsystemnivå:

ln -sfn /var/www/minside/releases/20261012120000 /var/www/minside/current_temp && mv -Tf /var/www/minside/current_temp /var/www/minside/current

Systemkallet rename() i Linux er atomisk. Nettserveren bytter til den nye versjonen på mikrosekunder. Hvis bygget eller avhengighetene feiler, røres aldri symlinken, og den aktive siden forblir oppe uten forstyrrelser for brukerne.

#Rask tilbakerulling ved uforutsette feil

Dersom en feil oppdages etter utrulling, kreves ingen gjenoppretting fra sikkerhetskopi. Det er tilstrekkelig å peke symlinken tilbake til forrige versjonsmappe og tømme hurtigbufferen:

ln -sfn /var/www/minside/releases/20261012110000 /var/www/minside/current
wp cache flush
sudo systemctl reload php8.3-fpm

#Automatisk deployment med Git bare repository og post-receive hooks

For oppsett uten eksterne CI-tjenester kan du implementere push-to-deploy med Git direkte på serveren ved hjelp av et nakent arkiv (bare repository) og en post-receive-hook.

#Opprett et bare repository på serveren

mkdir -p /var/repo/minside.git
cd /var/repo/minside.git
git init --bare

#Konfigurer post-receive hook

Opprett skriptet /var/repo/minside.git/hooks/post-receive:

#!/bin/bash
TARGET_DIR="/var/www/minside/releases/$(date +%Y%m%d%H%M%S)"
SHARED_DIR="/var/www/minside/shared"
CURRENT_LINK="/var/www/minside/current"

echo "===> Starter utrulling av WordPress..."
mkdir -p "$TARGET_DIR"

# Sjekk ut kildekoden fra hovedgrenen
git --work-tree="$TARGET_DIR" --git-dir=/var/repo/minside.git checkout -f main

# Lenk opp delte ressurser
ln -s "$SHARED_DIR/.env" "$TARGET_DIR/.env"
rm -rf "$TARGET_DIR/wp-content/uploads"
ln -s "$SHARED_DIR/wp-content/uploads" "$TARGET_DIR/wp-content/uploads"

# Installer Composer-avhengigheter dersom filen eksisterer
if [ -f "$TARGET_DIR/composer.json" ]; then
    cd "$TARGET_DIR" && composer install --no-dev --optimize-autoloader --quiet
fi

# Oppdater databaseskjema ved behov
wp core update-db --path="$TARGET_DIR" --quiet

# Atomisk bytte av symlink
ln -sfn "$TARGET_DIR" "${CURRENT_LINK}_temp" && mv -Tf "${CURRENT_LINK}_temp" "$CURRENT_LINK"

# Tøm hurtigbuffer og last PHP-FPM på nytt
wp cache flush --path="$CURRENT_LINK" --quiet
sudo systemctl reload php8.3-fpm

echo "===> Utrulling fullført uten nedetid."

Gjør skriptet kjørbart:

chmod +x /var/repo/minside.git/hooks/post-receive

Legg til tjeneren som et eksternt Git-mål lokalt:

git remote add production deploy@server:/var/repo/minside.git
git push production main

Ved hver push overføres endringene over SSH, skriptet oppretter en ny release, installerer pakker og bytter symlinken umiddelbart.

#Sikkerhetsherding av serveren etter utrulling

Når nøkkelbasert innlogging og automatisert utrulling er etablert, må de resterende delene av servermiljøet sikres mot angrep.

#Deaktiver XML-RPC

XML-RPC-grensesnittet er en historisk protokoll som hyppig utnyttes til brute-force- og DDoS-angrep. Med mindre eksterne mobilapper krever det, deaktiveres funksjonen via et filter i mu-plugins:

add_filter( 'xmlrpc_enabled', '__return_false' );

I Nginx kan tilgangen blokkeres helt på webservernivå:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

#Sett korrekte filrettigheter i Linux

Webserverprosessen (www-data) skal aldri eie PHP-kodefilene. Utvikleren eller deploy-brukeren eier filene, mens webserveren kun har lesetilgang til koden og skrivetilgang til uploads-mappen:

# Standardrettigheter for kodefiler og kataloger
find /var/www/minside/current -type f -exec chmod 644 {} \;
find /var/www/minside/current -type d -exec chmod 755 {} \;

# Streng tilgang for miljøvariabler med passord
chmod 600 /var/www/minside/shared/.env

# Skrivetilgang til felles opplastingsmappe for webserveren
chown -R deploy:www-data /var/www/minside/shared/wp-content/uploads
chmod -R 775 /var/www/minside/shared/wp-content/uploads

#Beskytt SSH mot brute-force med fail2ban

Installer fail2ban for automatisk utestengelse av IP-adresser med gjentatte mislykkede påloggingsforsøk:

sudo apt update && sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

I /etc/fail2ban/jail.local tilpasses SSH-konfigurasjonen med lengre utestengelsestid:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h
findtime = 10m

#Hvorfor du ikke bør bruke git pull direkte i produksjon

En vanlig overgangsfase for utviklere som forlater FTP er å logge inn på serveren og kjøre `git pull origin main` direkte i webroot-katalogen `/var/www/html`. Selv om dette gir en historikklogg, introduserer metoden flere alvorlige produksjonsrisikoer.

#Ufullstendige filtilstander under nedlasting

Når Git oppdaterer filer på serveren via nettverket, skjer ikke endringen øyeblikkelig over hele filtreet. Dersom en oppdatering endrer både et tema og en utvidelse som er avhengig av nye funksjoner, vil PHP-FPM-prosessene betjene innkommende HTTP-forespørsler i brøkdeler av sekunder der bare halvparten av filene er oppdatert. Dette resulterer i `Fatal error: Uncaught Error: Call to undefined function` og blanke sider for aktive brukere og søkemotorroboter.

#Konflikter fra modifiserte filer på produksjonsserveren

Dersom en administrator, en utvidelse eller en automatisk oversettingsrutine endrer en fil på serveren, vil neste `git pull` feile med merge-konflikter (`Your local changes to the following files would be overwritten by merge`). Utrullingen stopper opp midt i prosessen, og serveren blir stående i en udefinert tilstand inntil noen manuelt løser konflikten via SSH.

#Sikkerhetsrisiko ved eksponert git-katalog

Når du kjører Git direkte i webroot, opprettes mappen `.git/`. Dersom webserveren (Nginx eller Apache) ikke er eksplisitt konfigurert til å blokkere tilgang til skjulte mapper, kan eksterne angripere laste ned hele `.git/index` og gjenskape kildekoden, inkludert interne kommentarer og sensitive referanser.

#Testing og verifisering etter produksjonsutrulling

Utrullingspipelinen er ikke fullført idet filene er overført eller symlinken er byttet. Profesjonelle team etablerer automatiserte eller faste rutiner for å verifisere at nettstedet fungerer som forventet etter hver endring.

#Automatiserte helsesjekker med HTTP-statuskoder

Kjør et skript som sjekker HTTP-responsen på kritiske landingssider og API-endepunkter like etter at hurtigbufferen er tømt:

# Verifiser at forsiden og nøkkelruter svarer med HTTP 200
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/nb/wordpress-utvikler/
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/wp-json/

Dersom en forespørsel returnerer en 500-feilkode, kan pipelinen automatisk trigge en symlink-tilbakerulling til forrige release før trafikk blir påvirket.

#Overvåking av PHP-feillogger og feilsøkingsdata

Inspiser `debug.log` eller feilloggen til PHP-FPM umiddelbart etter utrulling for å fange opp skjulte advarsler og utdaterte funksjonskall:

tail -n 100 /var/log/php8.3-fpm.log
tail -n 100 /var/www/minside/shared/wp-content/debug.log

Dette avslører raskt om oppdaterte utvidelser forsøker å kalle funksjoner som kolliderer med eksisterende filtre.

#Sikker håndtering av hemmeligheter og nøkler i produksjon

Når du går bort fra FTP til Git, endrer sikkerhetsmodellen seg. Passord skal aldri ligge i kildekoden eller i versjonskontrollen.

#Prinsipper for håndtering av tilgangsnøkler

Private SSH-nøkler forlater aldri maskinen din: Den private nøkkelen beskyttes av en sterk passfrase lokalt. Serveren kjenner bare den offentlige nøkkelen i `authorized_keys`.
Pipelines bruker dedikerte distribusjonsnøkler (Deploy Keys): Hvis en CI/CD-server som GitHub Actions må hente kode eller koble til serveren, opprettes et eget nøkkelpar med begrensede rettigheter spesifikt for dette formålet.
Databasepassord i isolerte miljøfiler: Konfigurasjonsdata for produksjonsdatabasen plasseres i `/var/www/minside/shared/.env` med filrettighet 600, slik at ingen andre brukere på serveren kan lese den.
Håndtering av utilsiktede commits: Dersom et passord eller en hemmelighet ved en feiltakelse blir committet til Git, holder det ikke å slette filen i neste commit. Nøkkelen ligger lagret i repositoriets historikk. Passordet må umiddelbart roteres og erklæres kompromittert.

#Sjekkliste for migrering fra FTP til Git og SSH

Fase 1: Grunnlag
- Opprett ED25519 SSH-nøkler for alle utviklere på teamet.
- Deaktiver passordautentisering i /etc/ssh/sshd_config (PasswordAuthentication no).
- Installer WP-CLI på produksjons- og testservere.
- Sett opp snarveier i ~/.ssh/config.
Fase 2: Versjonskontroll
- Initialiser Git i prosjektet og sett opp en streng .gitignore.
- Flytt utvidelser og temaer over til Composer-avhengigheter der det passer.
- Definer en tydelig grenstrategi med main for produksjon og egne funksjonsgrener.
Fase 3: Automatisert utrulling
- Etabler et staging-miljø med paritet mot produksjon.
- Skriv et rsync- eller Deployer-skript med presise utelukkelsesregler.
- Sett opp GitHub Actions eller post-receive-hooks på serveren.
Fase 4: Sikring og drift
- Flytt hemmeligheter og passord over i .env-filer.
- Lås filrettigheter (644 for filer, 755 for mapper, 600 for konfigurasjon).
- Installer fail2ban og deaktiver XML-RPC.
- Verifiser at tilbakerulling fungerer feilfritt ved simulert feil.

#Teknisk sammendrag for moderne WordPress-drift

“Feil 29” er ikke en uforklarlig feil, men en påminnelse om at filoverføring over FTP hører fortiden til.

Erstatt FTP med SFTP for sporadiske manuelle oppgaver.
Gå over til ED25519 SSH-nøkler for all servertilgang.
Bruk Git-baserte pipelines og rsync for å automatisere bygg og utrulling.
Benytt atomiske utrullinger med symbolske lenker for å fjerne nedetid og sikre umiddelbar tilbakerulling.

Dette fundamentet sparer tid og sikrer forutsigbar drift for både utviklere og nettstedseiere. Trenger du hjelp med oppsett av infrastruktur, sjekk WordPress-utvikling med moderne arbeidsflyt hos WPPoland.