Installer WordPress med Docker og Composer: moderne utviklingsoppsett for 2026

WordPress-utvikling har vokst forbi FTP-opplastinger og delte hostingpaneler. I 2026 behandler profesjonelle team WordPress som ethvert annet programvareprosjekt, med versjonskontrollerte avhengigheter, containeriserte miljøer og automatiserte distribusjonspipelines. Hvis du fortsatt redigerer filer direkte på en live server, vil denne guiden forandre maten du jobber på.

Denne veiledningen dekker to komplementære tilnærminger til moderne WordPress-utvikling: Docker Compose for reproduserbare servermiljøer og Composer med Bedrock for avhengighetsadministrasjon. Du får komplette, kopieringsklare konfigurasjonsfiler, Xdebug-oppsett for skikkelig PHP-feilsøking og en distribusjonsarbeidsflyt som tar koden din trygt fra lokal maskin til produksjon.

#Hvorfor bruke Docker til WordPress-utvikling

Den klassiske tilnærmingen med å laste ned en ZIP-fil fra wordpress.org og laste den opp via FTP skaper flere problemer som førsterkes over tid:

• Miljoavvik - ditt lokale MAMP- eller XAMPP-oppsett stemmer aldri helt overens med produksjonsserveren, noe som fører til “fungerer på min maskin”-feil.
• Ingen avhengighetssporing - utvidelser og temaer lastes ned og oppdateres manuelt, noe som gjør det umulig å reprodusere nøyaktig samme nettsted på en annen maskin.
• Ingen versjonskontroll for kjernen - WordPress-kjernefiler ligger i repositoryet ditt (eller verre, spores ikke i det hele tatt), og blander applikasjonskode med rammeverkkode.
• Manuelle distribusjoner - kopiering av filer via FTP er feilutsatt og gir ingen tilbakerullingsmekanisme.

Docker og Composer løser hvert av disse problemene systematisk.

#Sette opp WordPress med Docker Compose

Docker Compose lar deg definere hele serverstakken i en enkelt YAML-fil. Hver utvikler i teamet får nøyaktig samme PHP-versjon, MySQL-versjon og serverkonfigurasjon ved å kjøre en kommando.

#Forutsetninger

Installer Docker Desktop for ditt operativsystem. Docker Desktop inkluderer både Docker-motoren og docker compose CLI-pluginen. Verifiser installasjonen:

docker --version
docker compose version

#Prosjektstruktur

Opprett en ren prosjektkatalog:

mkdir wordpress-docker && cd wordpress-docker
mkdir -p wp-content/themes wp-content/plugins wp-content/uploads

#Den komplette docker-compose.yml

Opprett en docker-compose.yml-fil i prosjektets rotkatalog:

services:
  db:
    image: mysql:8.0
    container_name: wp_mysql
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${DB_NAME:-wordpress}
      MYSQL_USER: ${DB_USER:-wpuser}
      MYSQL_PASSWORD: ${DB_PASSWORD:-wppassword}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    volumes:
      - db_data:/var/lib/mysql
    ports:
      - "3306:3306"
    networks:
      - wp_network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:7.1-php8.3-apache
    container_name: wp_app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
      WORDPRESS_DEBUG: ${WP_DEBUG:-1}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('DISALLOW_FILE_EDIT', true);
    volumes:
      - ./wp-content/themes:/var/www/html/wp-content/themes
      - ./wp-content/plugins:/var/www/html/wp-content/plugins
      - ./wp-content/uploads:/var/www/html/wp-content/uploads
      - ./php-custom.ini:/usr/local/etc/php/conf.d/custom.ini
    ports:
      - "8080:80"
    networks:
      - wp_network

  phpmyadmin:
    image: phpmyadmin:5
    container_name: wp_phpmyadmin
    restart: unless-stopped
    depends_on:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    ports:
      - "8081:80"
    networks:
      - wp_network

  mailhog:
    image: mailhog/mailhog:latest
    container_name: wp_mailhog
    ports:
      - "1025:1025"
      - "8025:8025"
    networks:
      - wp_network

volumes:
  db_data:

networks:
  wp_network:
    driver: bridge

Denne konfigurasjonen gir deg fire tjenester:

• MySQL 8.0 med helsesjekk slik at WordPress venter på at databasen er klar før den starter.
• WordPress 7.1 på PHP 8.3 med Apache, som kun monterer dine egne temaer, utvidelser og opplastinger.
• phpMyAdmin for visuell databaseadministrasjon på http://localhost:8081.
• MailHog for å fange utgående e-poster under utvikling på http://localhost:8025.

#Miljøvariabler med .env

Opprett en .env-fil i prosjektets rotkatalog:

# Database
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_ROOT_PASSWORD=secure_root_password_2026

# WordPress
WP_DEBUG=1

# Nettsted
SITE_URL=http://localhost:8080

Docker Compose leser automatisk .env-filer fra prosjektkatalogen. Legg til .env i .gitignore umiddelbart og commit en .env.example-mål i stedet.

#Lagre databasepassord i Compose-secrets

.env-filen over sender passord som miljøvariabler. Docker-dokumentasjonen om secrets i Compose påpeker at miljøvariabler ofte er tilgjengelige for alle prosesser i en container og kan bli skrevet ut i logger mens du feilsøker. En Compose-secret monteres som en fil under /run/secrets/<secret_name>, og bare tjenestene som oppgir den, kan lese den.

Det offisielle WordPress-imaget på Docker Hub leser slike filer når du legger _FILE til et variabelnavn. Dokumentasjonen støtter dette for databasevert, bruker, passord og navn, de åtte autentiseringsnøklene og saltene, WORDPRESS_TABLE_PREFIX og WORDPRESS_DEBUG. MySQL-imaget følger samme konvensjon:

services:
  db:
    environment:
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets:
      - db_password
      - db_root_password

  wordpress:
    environment:
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
  db_root_password:
    file: ./secrets/db_root_password.txt

_FILE-variabelen erstatter den vanlige variabelen i samme tjeneste, så fjern MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD og WORDPRESS_DB_PASSWORD fra disse tjenestene. Hold katalogen secrets/ utenfor Git, på samme måte som .env. Docker nevner én begrensning: Compose-secrets fungerer bare i Linux-containere, fordi hver secret monteres som én enkelt fil med bind mount.

#Tilpasset PHP-konfigurasjon

Opprett php-custom.ini for utviklingsvennlige PHP-innstillinger:

upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000
display_errors = On
error_reporting = E_ALL

#Starte miljøet

docker compose up -d

Åpne http://localhost:8080 og fullfør WordPress-installasjonen. Tema- og utvidelseskatalogene dine er montert fra vertsmaskinen, så alle endringer du gjør i editoren vises umiddelbart i den kjørende WordPress-instansen.

#Legge til en WP-CLI-container med imaget wordpress:cli

Apache-varianten av WordPress-imaget inneholder ikke kommandoen wp, derfor går WP-CLI-kallene i denne veiledningen gjennom en egen tjeneste, wpcli. Docker Hub publiserer en cli-variant av det samme imaget til dette, som wordpress:cli og med fast PHP-versjon, for eksempel wordpress:cli-php8.3. Legg den til under services::

  wpcli:
    image: wordpress:cli-php8.3
    user: "33:33"
    profiles: ["tools"]
    depends_on:
      - db
      - wordpress
    volumes_from:
      - wordpress
    environment:
      HOME: /tmp
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
    networks:
      - wp_network

Dokumentasjonen for imaget forklarer linjen user. cli-variantene bygger på Alpine, der www-data har UID 82, mens de Debian-baserte WordPress-imagene kjører som UID 33. Uten user: "33:33" tilhører filer som WP-CLI oppretter, en bruker webserveren ikke kjenner. Den samme dokumentasjonen foreslår HOME=/tmp for kommandoer som prøver å skrive til ~/.wp-cli. volumes_from monterer filene til tjenesten wordpress, og databasevariablene lar den delte wp-config.php koble til.

Oppføringen profiles hindrer at docker compose up -d starter containeren. Ifølge Compose-dokumentasjonen om profiler kjører en tjeneste du angir eksplisitt, uansett om profilen er aktiv, så docker compose run --rm wpcli wp plugin list virker uten ekstra flagg. En bredere gjennomgang av containere i WordPress-arbeid finner du i vår veiledning om Docker for WordPress-utvikling.

#Nyttige Docker-kommandoer for daglig arbeid

# Vis logger fra alle containere
docker compose logs -f

# Vis logger kun fra WordPress
docker compose logs -f wordpress

# Apne et skall inne i WordPress-containeren
docker compose exec wordpress bash

# Kjør WP-CLI-kommandoer inne i containeren
docker compose run --rm wpcli wp plugin list

# Stopp alle containere (bevarer data)
docker compose stop

# Stopp og fjern containere (bevarer volumdata)
docker compose down

# Fullstendig tilbakestilling inkludert database
docker compose down -v

#Administrere WordPress med Composer og Bedrock

Mens Docker håndterer servermiljøet, omstrukturerer Bedrock fra Roots WordPress selv til en skikkelig Composer-administrert applikasjon. Bedrock behandler WordPress-kjernen som en avhengighet, ikke som prosjektets rotkatalog, noe som endrer alt ved hvordan du administrerer og distribuerer WordPress.

#Hva er Bedrock og hvorfor bruke det

Standard WordPress blander applikasjonskode (temaet ditt, utvidelser) med rammeverkkode (wp-admin, wp-includes) i samme katalog. Bedrock separerer disse bekymringene:

project-root/
  config/              # Miljøspesifikk konfigurasjon
    application.php
    environments/
      development.php
      staging.php
      production.php
  web/                 # Dokumentrot (offentlig)
    app/               # wp-content-ekvivalent
      themes/
      plugins/
      uploads/
    wp/                # WordPress-kjerne (Composer-administrert)
    wp-config.php      # Minimal laster
  vendor/              # Composer-avhengigheter
  .env                 # Miljøvariabler
  composer.json        # Avhengighetsmanifest

WordPress-kjernen ligger i web/wp/ og blir aldri modifisert. Din egendefinerte kode ligger i web/app/. vendor/-katalogen og web/wp/ er begge gitignorert fordi Composer gjenskaper dem fra composer.json.

#Installere Bedrock

composer create-project roots/bedrock my-wordpress-project
cd my-wordpress-project

#composer.json-strukturen

Bedrocks composer.json administrerer WordPress-kjerne, utvidelser og temaer som pakker:

{
  "name": "your-agency/client-project",
  "type": "project",
  "license": "MIT",
  "description": "WordPress project managed with Bedrock and Composer",
  "require": {
    "php": ">=8.3",
    "composer/installers": "^2.3",
    "vlucas/phpdotenv": "^5.6",
    "oscarotero/env": "^2.1",
    "roots/bedrock-autoloader": "^1.0",
    "roots/bedrock-disallow-indexing": "^2.0",
    "roots/wordpress": "7.1.*",
    "roots/wp-config": "1.0.0",
    "wpackagist-plugin/wordpress-seo": "^23.0",
    "wpackagist-plugin/wp-super-cache": "^1.12",
    "wpackagist-plugin/wordfence": "^7.11"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.10",
    "roave/security-advisories": "dev-latest"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": [
        "wpackagist-plugin/*",
        "wpackagist-theme/*"
      ]
    }
  ],
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": [
        "type:wordpress-muplugin"
      ],
      "web/app/plugins/{$name}/": [
        "type:wordpress-plugin"
      ],
      "web/app/themes/{$name}/": [
        "type:wordpress-theme"
      ]
    },
    "wordpress-install-dir": "web/wp"
  }
}

Det viktigste å forstå: WordPress Packagist speiler hele WordPress.org sin utvidelse- og temarepository som Composer-pakker. Å legge til en utvidelse er så enkelt som:

composer require wpackagist-plugin/advanced-custom-fields

Aa fjerne den er like rent:

composer remove wpackagist-plugin/advanced-custom-fields

#Committe composer.lock og publisere med composer install

composer.json inneholder versjonsintervaller som ^23.0, mens composer.lock registrerer de eksakte versjonene Composer valgte. Composer-dokumentasjonen om grunnleggende bruk sier at låsefilen skal committes til prosjektets repository, fordi alle som setter opp prosjektet da bruker de samme versjonene av avhengighetene. Når en låsefil finnes, installerer composer install nøyaktig det som står i den. composer update er kommandoen som henter nyere versjoner innenfor intervallene og skriver låsefilen på nytt.

I et WordPress-prosjekt kjører du composer update lokalt, eller composer update wpackagist-plugin/wordpress-seo for én utvidelse, tester resultatet i Docker, committer den endrede composer.lock og lar pipelinen kjøre composer install, slik GitHub Actions-eksempelet nedenfor gjør. En oppdatering av en utvidelse blir da en diff du kan gå gjennom, i stedet for et klikk i wp-admin på det levende nettstedet.

WPackagist-siden oppgir at tjenesten skanner Subversion-repositoryet til WordPress.org hver time og kobler tagger til versjoner, så en ny utgivelse av en utvidelse kan bruke opptil en time på å dukke opp der. For utvidelser legges også trunk til som utviklingsversjon (dev-trunk), som følger upublisert kode og ikke hører hjemme i en låsefil for produksjon. Samme side opplyser at WPackagist nå vedlikeholdes av WP Engine.

#Bedrock-miljøkonfigurasjon

Bedrock bruker .env-filer i stedet for å hardkode verdier i wp-config.php:

# .env-fil for Bedrock
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_HOST=db:3306
DB_PREFIX=wp_

WP_ENV=development
WP_HOME=http://localhost:8080
WP_SITEURL=${WP_HOME}/wp

# Generer disse på https://roots.io/salts.html
AUTH_KEY='generate-unique-key-here'
SECURE_AUTH_KEY='generate-unique-key-here'
LOGGED_IN_KEY='generate-unique-key-here'
NONCE_KEY='generate-unique-key-here'
AUTH_SALT='generate-unique-salt-here'
SECURE_AUTH_SALT='generate-unique-salt-here'
LOGGED_IN_SALT='generate-unique-salt-here'
NONCE_SALT='generate-unique-salt-here'

Hvert miljo (utvikling, staging, produksjon) har sin egen .env-fil på sin respektive server. Samme kodebase kjører overalt, med atferd kontrollert utelukkende av miljøvariabler.

#Kjøre Bedrock i Docker

Den virkelige kraften kommer ved å kjøre Bedrock inne i Docker. Modifiser docker-compose.yml for å montere Bedrock-prosjektet i stedet for standard WordPress-imaget:

services:
  wordpress:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/var/www/html
    environment:
      - WP_ENV=development

Med en tilpasset Dockerfile:

FROM php:8.3-apache

RUN apt-get update && apt-get install -y \
    libzip-dev \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    libicu-dev \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install \
    mysqli \
    pdo_mysql \
    zip \
    gd \
    intl \
    opcache

RUN a2enmod rewrite

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

ENV APACHE_DOCUMENT_ROOT /var/www/html/web

RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' \
    /etc/apache2/sites-available/*.conf \
    /etc/apache2/apache2.conf

WORKDIR /var/www/html

Dette gir deg et fullstendig containerisert Bedrock-miljo der composer install kjøres inne i containeren og dokumentroten peker til Bedrocks web/-katalog.

#Xdebug-oppsett for PHP-feilsøking

Trinnvis feilsøking erstatter var_dump og error_log med en skikkelig debugger som lar deg pause kjøringen, inspisere variabler og gå gjennom koden linje for linje.

#Legge til Xdebug i Docker-containeren

Opprett en xdebug.ini-fil:

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

Legg til Xdebug-installasjon i Dockerfile:

RUN pecl install xdebug-3.3.2 \
    && docker-php-ext-enable xdebug

COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

#VS Code-konfigurasjon

Opprett .vscode/launch.json i prosjektets rotkatalog:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug (Docker)",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      },
      "log": true
    }
  ]
}

Installer PHP Debug-utvidelsen fra Xdebug i VS Code, sett et breakpoint i en hvilken som helst PHP-fil, trykk F5 for å begynne å lytte, og last inn WordPress-siden på nytt. Debuggeren vil stoppe ved breakpointet ditt.

#PhpStorm-konfigurasjon

PhpStorm håndterer Docker Xdebug-tilkoblinger innebygd:

1. Gå til Settings > PHP > Debug og verifiser at port 9003 er satt.
2. Gå til Settings > PHP > Servers, legg til en ny server med localhost på port 8080, og konfigurer stitilordningen fra /var/www/html til prosjektets rotkatalog.
3. Klikk på knappen Start Listening for PHP Debug Connections i verktøylinjen.

#Publisere WordPress fra lokalt via staging til produksjon

#Kjøre composer install uten SSH-tilgang

I prosjektene vi følger i Norge ender kjeden oftest hos en nordisk leverandør med panel, og SSH-tilgang avhenger av planen, ikke av leverandøren. Sjekk det før du velger Bedrock, for uten SSH må composer install kjøre i pipelinen og vendor følger med releasen.

En profesjonell distribusjonspipeline sikrer at kodeendringer flyter forutsigbart fra utvikling til produksjon uten manuell filkopiering.

#Tre-miljøer-modellen

1. Lokalt (Docker) - der du skriver og tester kode.
2. Staging - en server som speiler produksjon for endelig testing.
3. Produksjon - det aktive nettstedet.

#Git-basert distribusjon med GitHub Actions

Repositoryet ditt bør inneholde tema-, utvidelse- og Bedrock-konfigurasjonskode. Det bør ikke inneholde WordPress-kjerne, vendor/ eller uploads/.

Eksempel .github/workflows/deploy.yml:

name: Deploy to staging

on:
  push:
    branches: [staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run code quality checks
        run: vendor/bin/phpcs --standard=WordPress web/app/themes/

      - name: Deploy via rsync
        uses: burnett01/[email protected]
        with:
          switches: -avz --delete --exclude='.env' --exclude='web/app/uploads/'
          path: ./
          remote_path: /var/www/staging.example.com/
          remote_host: ${{ secrets.STAGING_HOST }}
          remote_user: ${{ secrets.STAGING_USER }}
          remote_key: ${{ secrets.STAGING_SSH_KEY }}

#Database- og opplastingssynkronisering

Kode distribueres gjennom Git, men databaser og medieopplastinger krever separat håndtering:

# Eksporter produksjonsdatabase
wp db export production-backup.sql --ssh=user@production

# Importer til staging
wp db import production-backup.sql --ssh=user@staging

# Søk-og-erstatt URL-er
wp search-replace 'https://example.com' 'https://staging.example.com' --ssh=user@staging

# Synkroniser opplastinger fra produksjon til staging
rsync -avz user@production:/var/www/html/web/app/uploads/ \
  user@staging:/var/www/html/web/app/uploads/

For lokal utvikling, bruk WP-CLI sine wp db export og wp db import-kommandoer gjennom Docker:

docker compose run --rm -T wpcli wp db export - > ./backups/backup.sql

#Sammenligning: Docker vs Composer vs LocalWP vs MAMP

Hovedpoenget: Docker og Composer er komplementære, ikke konkurrerende. Docker erstatter MAMP/XAMPP som servermiljo, mens Composer erstatter manuell utvidelse-/temaadministrasjon. LocalWP forblir et gyldig valg for rask prototyping, men mangler reproduserbarheten og CI/CD-integrasjonen som profesjonelle team trenger.

#Ytelsestips for Docker på macOS

Docker på macOS har historisk lidd av treg filsystemytelse på grunn av virtualiseringslaget. I 2026 bruker Docker Desktop VirtioFS som standard, noe som dramatisk forbedrer I/O-hastigheten. Hvis du fortsatt opplever treghet:

• Verifiser at VirtioFS er aktivert i Docker Desktop > Settings > General.
• Begrens monterte volumer til kun det du trenger (temaer, utvidelser, opplastinger), ikke hele WordPress-installasjonen.
• Bruk Dockers innebygde caching-direktiver ved behov: volumes: - ./wp-content:/var/www/html/wp-content:cached.
• Tildel tilstrekkelige ressurser i Docker Desktop > Settings > Resources (minst 4 GB RAM og 2 CPU-er).

#Sikre et lokalt WordPress-miljø i Docker

Selv i lokale miljøer er sikkerhetsvaner viktige fordi konfigurasjoner ofte lekker til produksjon:

• Aldri commit .env-filer til Git. Bruk .env.example som mål.
• Bruk sterke, unike passord i .env selv lokalt, slik at du aldri ved et uhell distribuerer svake legitimasjoner.
• Hold DISALLOW_FILE_EDIT satt til true i alle miljøer.
• Kjør composer audit regelmessig for å sjekke for kjente sårbarheter i avhengighetene dine.
• Fest spesifikke versjoner i composer.json for produksjonsdistribusjoner i stedet for å bruke løse versjonsbegrensninger.

#Vanlige feil med WordPress i Docker

MySQL-containeren avsluttes umiddelbart Sjekk logger med docker compose logs db. Den vanligste årsaken er et eksisterende volum med inkompatible data. Kjør docker compose down -v for å fjerne volumer og starte på nytt.

WordPress kan ikke koble til databasen Verifiser at WORDPRESS_DB_HOST-verdien samsvarer med tjenestenavnet i docker-compose.yml (vanligvis db:3306). Sikre at databasecontaineren er sunn før WordPress starter ved å bruke depends_on-betingelsen vist i konfigurasjonen ovenfor.

Xdebug kobler ikke til Bekreft at host.docker.internal løses opp korrekt inne i containeren. På Linux må du kanskje legge til extra_hosts: - "host.docker.internal:host-gateway" i WordPress-tjenestedefinisjonen din.

Filtillatelsefeil Hvis WordPress ikke kan skrive til wp-content/uploads, juster tillatelsene inne i containeren:

docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content/uploads

#Flere verktøy for WordPress i Docker

Når du har Docker og Composer i gang, vurder disse tilleggene for å ytterligere profesjonalisere oppsettet ditt:

• WP-CLI som Composer-avhengighet for skriptbasert WordPress-administrasjon.
• PHPStan eller Psalm for statisk analyse av tema- og utvidelse-PHP-koden din.
• GitHub Actions eller GitLab CI for automatisert testing på hver pull request.
• Redis eller Memcached som en ekstra Docker-tjeneste for objektcaching under utvikling.
• Traefik eller Nginx Proxy for å administrere flere lokale WordPress-prosjekter med egendefinerte domener i stedet for portnumre.

Moderne WordPress-engineering betyr å behandle nettstedet ditt som et programvareprodukt, med reproduserbare bygg, automatisert testing og sikre distribusjoner. Verktoyene dekket i denne guiden, Docker Compose for miljøer og Composer med Bedrock for avhengighetsadministrasjon, danner grunnlaget som ethvert seriøst WordPress-team trenger i 2026.

Hos wppoland.com bygger og vedlikeholder vi WordPress-prosjekter med nøyaktig disse arbeidsflytene. Hvis teamet ditt trenger hjelp med å modernisere WordPress-utviklingsprosessen, sette opp CI/CD-pipelines eller migrere fra eldre oppsett til containeriserte miljøer, er ingeniørteamet vårt tilgjengelig for rådgivning og implementering. Prising er alltid individuell og avhenger av omfanget av prosjektet ditt.