WordPress-oppsett for utviklere, herding og wp-config

Den berømte 5-minutters installasjonen er et markedsføringsslagord, ikke en profesjonell standard. En standard WordPress-installasjon er pratsom, uoptimalisert og ofte usikker. Som utviklere installerer vi ikke bare WordPress; vi klargjør det. Denne guiden dekker konfigurasjonskonstanter, debugging-regler og kjerne-rydding som bør ligge i malen for kundeprosjekter i 2026.

#Slik setter du opp wp-config.php for staging og produksjon

Filen er hjernen i installasjonen. La den ikke stå på standardverdier etter installasjonsveiviseren. Alt som styrer miljø, sikkerhet og feilsøking bør være eksplisitt, versjonert (uten hemmeligheter i Git) og dokumentert for den som overtar driften.

#Miljøkontroll

Siden WordPress 5.5 er WP_ENVIRONMENT_TYPE standard. Bruk den for å hindre at utviklingsfeil lekker til produksjon.

// I wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'production' ); // local | development | staging | production

I egen kode:

if ( wp_get_environment_type() === 'production' ) {
	// Aktiver hurtigbuffer, skru av verbose feil
}

På staging kan du tillate plugin-installasjon og vise Query Monitor. I produksjon er det motsatt. Én konstant erstatter da en haug med if ( defined( 'WP_LOCAL_DEV' ) )-egendefinerte flagg som lagene glemmer å synce.

#Sikkerhetsherding

Hindre at kunder eller angripere ødelegger siden via dashbordet.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Bare når deploy er uforanderlig
define( 'FORCE_SSL_ADMIN', true );

DISALLOW_FILE_EDIT fjerner tema- og plugin-editoren. Det stopper både nysgjerrige redaktører og mange skadevare-scenarier der angriperen skriver webshells via editoren. DISALLOW_FILE_MODS er strengere: ingen installasjon eller oppdatering fra UI. Bruk den når CI eier artefaktene. På mindre redaksjonelle sites er det ofte nok med DISALLOW_FILE_EDIT alene, slik at sikkerhetsoppdateringer fortsatt kan kjøres fra admin når det haster.

#Innleggsrevisjoner og papirkurv

Databaseoppblåsing starter stille. Hundre revisjoner av «Om oss» hjelper ingen.

define( 'WP_POST_REVISIONS', 10 );
define( 'EMPTY_TRASH_DAYS', 14 );
define( 'AUTOSAVE_INTERVAL', 120 );

Ti revisjoner er et kompromiss mellom gjenoppretting og tabellstørrelse. Kortere papirkurv reduserer lagring av slettet innhold. Lengre autosave-intervall demper skrive-load på travle redaksjoner uten å fjerne vernet helt.

#Slik slår du på WP_DEBUG_LOG uten å vise feil

Vis aldri feil i frontend. Logg dem.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/wordpress/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', false );
@ini_set( 'display_errors', '0' );

Flytt loggfilen utenfor web-roten. /tmp/ fungerer i nød, men har ofte feil rettigheter og ingen rotasjon. På managed hosting: bruk katalogen leverandøren anbefaler, eller en mappe over public_html. SAVEQUERIES er nyttig lokalt med Query Monitor; i produksjon spiser den minne.

Når du må feilsøke live i en time:

1. Skru på WP_DEBUG og WP_DEBUG_LOG.
2. Hold WP_DEBUG_DISPLAY på false.
3. Reproduser feilen én gang.
4. Hent logglinjen, fiks, deploy.
5. Skru logging av igjen samme dag.

La aldri en «midlertidig» debug-blokk ligge i flere uker. Den lekker stier, SQL og brukerdata til den som finner logg-URL-en.

#Slå av emojis og XML-RPC med en mu-plugin

WordPress leveres med funksjoner de fleste bedriftssider ikke trenger: emoji-skript, oEmbeds og XML-RPC. Ikke installer et «disable everything»-plugin. Lag en must-use plugin.

<?php
/**
 * Plugin Name: Lean Core
 */

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
add_filter( 'xmlrpc_enabled', '__return_false' );
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'wp_shortlink_wp_head' );

XML-RPC er fortsatt et populært brute-force-mål. Skru det av med mindre Jetpack eller en mobilapp faktisk trenger det. Generator-taggen skjuler bare versjonsnummeret; den erstatter ikke patching. RSD og Windows Live Writer-lenker er støy for moderne stacks.

For rene brosjyresider kan du også stenge feeds, men blogger og nyhetssider skal beholde dem. Kommentér ut feed-blokkene i malen i stedet for å kopiere dem blindt.

#Autentiseringsnøkler og salts

Du kjenner AUTH_KEY, SECURE_AUTH_KEY og resten i wp-config.php.

define( 'AUTH_KEY', 'sett-en-lang-unik-streng-her' );
// ... øvrige nøkler fra WordPress API

Faktum: Endring av disse logger ut alle brukere med en gang. Det er nødknappen etter kompromittering. Praksis: Hent ferske verdier fra den offisielle salt-API-en ved provisjonering, lagre dem i secrets-manager eller host-miljøvariabler, og roter ved hendelse. Ikke commit ekte salts til Git.

På enterprise-oppsett automatiserer vi rotasjon via CLI etter hendelsesrespons. På mindre sites er manuell rotasjon etter mistanke om lekkasje nok, så lenge prosedyren står i runbooken.

#Riktige filrettigheter for wp-config.php

wp-config.php bør ikke være skrivbar for web-brukeren etter provisjonering. Typisk mønster på Linux-hosting:

• Filer 644, kataloger 755
• wp-config.php 440 eller 400 der hosten tillater det
• Ingen plugin-uploads med PHP-utførelse i uploads (serverregel)

Noen flytter wp-config.php ett nivå over web-roten. WordPress finner den der. Det reduserer eksponering hvis dokumentroten miskonfigureres. Test alltid på staging først; enkelte paneler forventer config i web-roten.

#Lokalt utviklingsmiljø med wp-env og Docker

Manuelle Apache- og PHP-installasjoner på utviklermaskiner spriker fort. Én utvikler kjører PHP 8.2, en annen sitter på 8.1, og feil avdekkes først i CI-pipelinen. Den offisielle standarden for et forutsigbart miljø er wp-env, drevet av Docker-containere og en deklarativ .wp-env.json i prosjektets rotmappe.

Installer pakken som en utviklingsavhengighet:

npm install --save-dev @wordpress/env
npx wp-env start

En utprøvd .wp-env.json for plugin- og tema-utvikling monterer kildekoden direkte inn i WordPress:

{
  "core": "WordPress/WordPress#6.7",
  "plugins": [ "." ],
  "config": {
    "WP_DEBUG": true,
    "WP_DEBUG_LOG": true,
    "WP_DEBUG_DISPLAY": false,
    "SCRIPT_DEBUG": true
  }
}

Fordeler for ingeniørteamet:

• WordPress-kjerneversjonen er låst i Git, så «det virker på min maskin» opphører som diskusjonstema.
• Med npx wp-env run cli wp kjører du WP-CLI direkte inne i de samme containerne nettleseren treffer.
• Testskript og E2E-kjøringer fra @wordpress/scripts forventer nøyaktig denne container-strukturen.

Nyttige daglige kommandoer:

npx wp-env run cli wp plugin list
npx wp-env run cli wp cache flush
npx wp-env logs
npx wp-env stop

#Slik setter du opp Composer 2 for WordPress-avhengigheter og plugins

Composer 2 håndterer PHP-pakker, utvidelser, temaer og utviklerverktøy deterministisk i teamet. I profesjonell WordPress-utvikling skal avhengigheter aldri committes manuelt som uversjonerte zip-arkiver fra plugin-katalogen. Med Composer erklærer du eksakte versjoner, automatiserer sikkerhetsoppdateringer i CI og holder Git-historikken ryddig.

WordPress-plugins og temaer fra WordPress.org kan installeres via Composer ved hjelp av det åpne WPackagist-depotet (wpackagist.org). Pakken composer/installers sørger for at utvidelser havner i wp-content/plugins/ og must-use-plugins i wp-content/mu-plugins/:

{
  "name": "wppoland/wordpress-prosjekt",
  "description": "WordPress-oppsett for utviklere med Composer 2",
  "type": "project",
  "license": "GPL-2.0-or-later",
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ],
  "require": {
    "php": ">=8.2",
    "composer/installers": "^2.3"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.11",
    "wp-coding-standards/wpcs": "^3.1",
    "phpstan/phpstan": "^1.12",
    "szepeviktor/phpstan-wordpress": "^1.3",
    "roave/security-advisories": "dev-latest"
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "dealerdirect/phpcodesniffer-composer-installer": true
    },
    "optimize-autoloader": true,
    "sort-packages": true
  },
  "scripts": {
    "phpcs": "phpcs --standard=WordPress src/",
    "phpcbf": "phpcbf --standard=WordPress src/",
    "phpstan": "phpstan analyse --level=6 src/"
  }
}

Commit alltid composer.lock til Git. Låsefilen garanterer identiske pakkeversjoner på alle maskiner og CI-servere. På produksjonsservere kjører du composer install --no-dev --optimize-autoloader ved deploy for å utelate testverktøy og bygge en optimalisert autoloader-klasseoversikt.

#Statisk kodeanalyse og PHP-standarder med PHPCS og PHPStan

Mens frontend-verktøy sikrer JavaScript og CSS, krever PHP-koden på serversiden tilsvarende presisjon. Statisk analyse lokalt fanger opp syntaksfeil, usikre databasespørringer, manglende escaping og fravær av nonces før koden går til pull request.

#Håndheving av WordPress Coding Standards med PHPCS

WordPress har offisielle kodestandarder (WPCS) gjennom PHP_CodeSniffer. Reglene sjekker navnekonvensjoner, matriseformatering og sikkerhetshull som rådata i $_POST eller manglende sanitiseringsfunksjoner som sanitize_text_field() og esc_html().

Konfigurer phpcs.xml.dist i prosjektroten:

<?xml version="1.0"?>
<ruleset name="WordPress Project Standards">
  <description>PHPCS-regelsett for WordPress-prosjekter.</description>
  <file>./src</file>
  <arg name="basepath" value="."/>
  <arg name="colors"/>
  <arg name="extensions" value="php"/>
  <arg name="parallel" value="8"/>

  <rule ref="WordPress-Core"/>
  <rule ref="WordPress-Docs"/>
  <rule ref="WordPress.Security.EscapeOutput"/>
  <rule ref="WordPress.Security.ValidatedSanitizedInput"/>

  <exclude-pattern>*/vendor/*</exclude-pattern>
  <exclude-pattern>*/node_modules/*</exclude-pattern>
  <exclude-pattern>*/build/*</exclude-pattern>
</ruleset>

Kjør composer run phpcs lokalt før du åpner en pull request. Ved formateringsavvik retter composer run phpcbf innrykk og mellomrom automatisk uten å endre programlogikken.

#Dyp statisk analyse med PHPStan og phpstan-wordpress

PHPCS sjekker struktur og formatering, men evaluerer ikke typesikkerhet eller kallgrafer. PHPStan analyserer PHP-kode uten å kjøre den, og avdekker udefinerte metoder, ugyldige parametertyper og død kode. Ettersom WordPress benytter dynamiske filtre og globale variabler, lærer utvidelsen szepeviktor/phpstan-wordpress PHPStan om kjernefunksjoner, WP_Post-egenskaper og hook-argumenter.

Konfigurer phpstan.neon.dist på regel-nivå 6:

includes:
  - vendor/szepeviktor/phpstan-wordpress/extension.neon

parameters:
  level: 6
  paths:
    - src/
  excludePaths:
    - vendor/
    - node_modules/
    - build/

Ved å inkludere PHPStan i CI-pipelinen unngår du at en endret funksjonssignatur eller en feilstavet hook-callback fører til nedetid i produksjon.

#Slik konfigurerer du Xdebug 3 for Docker og trinnvis feilsøking i IDE

Å stole utelukkende på var_dump() eller loggfiler sinker feilsøking ved kompliserte filtre, REST-endepunkter eller databasetransaksjoner. Xdebug 3 gir trinnvis kjøring, inspeksjon av kallstakken og variabelovervåking direkte i Visual Studio Code eller PhpStorm.

I Docker-oppsett som wp-env kjører Xdebug inne i applikasjonscontaineren og kobler tilbake til utviklerens IDE:

[xdebug]
zend_extension=xdebug.so
xdebug.mode=debug,develop
xdebug.start_with_request=trigger
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log
xdebug.discover_client_host=0

Innstillingen xdebug.start_with_request=trigger er essensiell for ytelsen. Hvis Xdebug kjører på hver eneste forespørsel, øker responstiden merkbart. I trigger-modus aktiveres feilsøkeren kun når en XDEBUG_SESSION-informasjonskapsel eller URL-parameter sendes, noe du enkelt styrer med nettlesertillegg som Xdebug Helper.

I Visual Studio Code setter du opp .vscode/launch.json med mappetilknytninger mellom vertsmaskinen og containeren:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html/wp-content/plugins/min-plugin": "${workspaceFolder}"
      }
    }
  ]
}

Mappetilknytningene sikrer at stoppunkter i editoren treffer nøyaktig linje under kjøring i containeren. Installer aldri Xdebug på en produksjonsserver; ressursbruken svekker kapasiteten og eksponerer interne systemvariabler.

#Avanserte wp-config-konstanter for minne og databaser

Filen wp-config.php styrer kjøremiljøet før WordPress laster inn temaer og utvidelser. I tillegg til vanlige debug-flagg bør utviklere sette eksplisitte minnegrenser, håndtere cron-kjøringer og klargjøre reparasjonsrutiner for databasen.

#Minnegrenser og bakgrunnsoppgaver

Standardgrensen i WordPress er 40 MB PHP-minne for vanlige nettsideforespørsler. WooCommerce-butikker, store blokkoppsett og tunge REST API-kall overskrider dette raskt under trafikktopper. Sett eksplisitte rammer i wp-config.php:

define( WP_MEMORY_LIMIT, 256M );
define( WP_MAX_MEMORY_LIMIT, 512M );

Konstanten WP_MAX_MEMORY_LIMIT gjelder i administrasjonspanelet og ved tunge bakgrunnsjobber som bildeskalering, masseimport og databaseskjema-oppdateringer.

#Frakobling av WP-Cron fra ordinær besøkstrafikk

Som standard kjører WordPress cron-oppgaver i bakgrunnen under vanlige sidevisninger. På nettsteder med lite trafikk henger planlagte innlegg og vedlikeholdsjobber etter. På travle nettsteder utløser samtidige sidevisninger parallelle cron-prosesser som gir plutselige belastningstopper mot databasen.

Deaktiver besøksstyrt cron i wp-config.php:

define( DISABLE_WP_CRON, true );
define( WP_CRON_LOCK_TIMEOUT, 60 );

Sett deretter opp en ekte system-cronjob på serveren eller i en dedikert container som kjører WP-CLI hvert femte minutt:

*/5 * * * * wp cron event run --due-now --path=/var/www/html > /dev/null 2>&1

#Filsystem-rettigheter og databasereparasjon

Dersom WordPress ber om FTP-innlogging under medieopplasting eller oppdateringer, tyr enkelte til usikre 777-rettigheter. Riktig metode er å angi filsystem-metoden direkte:

define( FS_METHOD, direct );
define( FS_CHMOD_DIR, 0755 );
define( FS_CHMOD_FILE, 0644 );

Ved databasetrøbbel har WordPress et innebygd reparasjonsverktøy på /wp-admin/maint/repair.php. Aktiver det kun under feilretting:

define( WP_ALLOW_REPAIR, true );

Fjern konstanten WP_ALLOW_REPAIR straks arbeidet er fullført. Lar du den stå aktiv, kan uautoriserte besøkende starte reparasjons- og optimaliseringsrutiner mot databasen.

#Nyttige WP-CLI-kommandoer for automatisering

Det offisielle WP-CLI-handboken er nøkkelen til å automatisere administrasjon uten å klikke i kontrollpanelet. I Docker- og wp-env-oppsett kjøres kommandoer direkte fra terminalen:

npx wp-env run cli wp core version
npx wp-env run cli wp plugin list --status=active
npx wp-env run cli wp option get siteurl
npx wp-env run cli wp rewrite flush --hard
npx wp-env run cli wp search-replace "https://staging.example.com" "https://example.com" --dry-run

Spesielt under migreringer sparer WP-CLI verdifulle timer: verktøyet håndterer serialiserte PHP-matriser i databasen trygt, i motsetning til et uforsiktig søk-og-erstatt i SQL-filer. Med --dry-run verifiserer du endringene før de lagres.

#Paritet mellom lokalt miljø og staging

Et lokalt miljø som avviker fra staging skaper uforutsette feil under lansering. Paritet handler om å harmonisere de operative parameterne som styrer koden:

1. Samme hovedversjoner av PHP og MySQL i lokalt Docker-miljø som på staging.
2. Konsistent WP_ENVIRONMENT_TYPE (lokalt local, staging staging, produksjon production).
3. Identiske aktive utvidelser styrt pin-presist gjennom composer.lock.
4. Rengjøring av restfiler: loggfiler som debug.log, SQL-dumper og CSV-eksport skal aldri ligge i den offentlige web-roten.
5. Ekskludering av mappen uploads/ fra versjonskontroll, med unntak av små test-fixtures.

#Utvikling av Gutenberg-blokker med create-block

Skreddersydde blokker er i 2026 en naturlig del av moderne WordPress-utvikling. I stedet for manuelle Webpack-oppsett anbefaler kjerneteamet stillaset @wordpress/create-block og byggeverktøyene i @wordpress/scripts:

npx @wordpress/create-block min-blokk --variant dynamic
cd min-blokk
npm run start

Blokkens egenskaper deklareres i block.json. Dette muliggjør hurtigbufring av blokkmetadata på serversiden og enkel registrering i PHP via register_block_type( __DIR__ . "/build" ). Hold skript for redigering og frontend adskilt i block.json (editorScript for React-grensesnittet i editoren og viewScript for minimal interaktivitet på klientsiden) for å unngå å sende overflødige ressurser til vanlige besøkende.

#WordPress sjekkliste før lansering for utviklere

1. Sett WP_ENVIRONMENT_TYPE til production.
2. Sett DISALLOW_FILE_EDIT til true.
3. Vurder DISALLOW_FILE_MODS ut fra deploy-modell.
4. Begrens WP_POST_REVISIONS (for eksempel til 10).
5. Flytt WP_DEBUG_LOG til privat katalog; hold display av.
6. Deaktiver emoji og XML-RPC via mu-plugin.
7. Bekreft FORCE_SSL_ADMIN og HTTPS på hele admin.
8. Verifiser at salts ikke er standard-placeholder-tekst.
9. Ta backup før du endrer salts eller FILE_MODS på live.

#Vanlige wp-config-feil fra sikkerhetsrevisjoner

• Debug display på i produksjon etter «rask fiks».
• Standard salts fra en gammel boilerplate kopiert mellom kunder.
• File editor åpen «fordi kunden ville redigere CSS».
• Et sikkerhetsplugin som lover herding, mens wp-config fortsatt er urørt.
• Revisjoner ubegrenset på WooCommerce-produktbeskrivelser som endres daglig.

#Oppsummering

En godt konfigurert WordPress-instans er stille, sikker og forutsigbar. Konstanter i wp-config.php, logging uten lekkasje, og en tynn mu-plugin for kjerne-rydding gir mer effekt enn nok et dashboard-plugin. Bruk sjekklisten over som mal i hvert kundeprosjekt, ikke som engangsliste.

Se også vår WordPress-sikkerhetsrevisjon. Trenger du hjelp til å provisjonere eller rydde en eksisterende installasjon, ta kontakt via kontaktskjemaet.