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 miljoer 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 komplementaere tilnærminger til moderne WordPress-utvikling: Docker Compose for reproduserbare servermiljoer 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 det tradisjonelle WordPress-oppsettet holder deg tilbake

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 foerer til “fungerer på min maskin”-feil.
• Ingen avhengighetssporing - utvidelser og temaer lastes ned og oppdateres manuelt, noe som gjoer det umulig å reprodusere noyaktig 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 loeser 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 noyaktig samme PHP-versjon, MySQL-versjon og serverkonfigurasjon ved å kjoere 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:

version: "3.9"

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:6.7-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 foer den starter.
• WordPress 6.7 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 aa fange utgaende e-poster under utvikling på http://localhost:8025.

#Miljoevariabler 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.

#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

Apne http://localhost:8080 og fullfoel WordPress-installasjonen. Tema- og utvidelseskatalogene dine er montert fra vertsmaskinen, så alle endringer du gjoer i editoren vises umiddelbart i den kjoerende WordPress-instansen.

#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

# Kjoer WP-CLI-kommandoer inne i containeren
docker compose exec wordpress wp plugin list --allow-root

# 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

#Composer-basert WordPress med Bedrock

Mens Docker handterer 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.

#Hvorfor Bedrock er viktig

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

project-root/
  config/              # Miljoespesifikk 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                 # Miljoevariabler
  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.1",
    "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": "6.7.*",
    "roots/wp-config": "1.0.0",
    "roots/wp-password-bcrypt": "1.1.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 aa forstå: WordPress Packagist speiler hele WordPress.org sin utvidelse- og temarepository som Composer-pakker. Aa 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

#Bedrock miljoekonfigurasjon

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 pa 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 kjoerer overalt, med atferd kontrollert utelukkende av miljoevariabler.

#Kombinere Docker og Bedrock

Den virkelige kraften kommer ved å kjoere 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 kjoeres 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 kjoeringen, 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 handterer 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.

#Distribusjonsarbeidsflyt: fra lokalt til staging til produksjon

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

#Tre-miljoer-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 boer inneholde tema-, utvidelse- og Bedrock-konfigurasjonskode. Det boer 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/rsync-deployments@7.0
        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 handtering:

# 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 exec wordpress wp db export /tmp/backup.sql --allow-root
docker cp wp_app:/tmp/backup.sql ./backups/

#Sammenligning: Docker vs Composer vs LocalWP vs MAMP

Hovedpoenget: Docker og Composer er komplementaere, 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).

#Sikkerhetshensyn for lokal utvikling

Selv i lokale miljoer 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 miljoer.
• Kjoer composer audit regelmessig for å sjekke for kjente sarbarheter i avhengighetene dine.
• Fest spesifikke versjoner i composer.json for produksjonsdistribusjoner i stedet for å bruke loese versjonsbegrensninger.

#Feilsøking av vanlige problemer

MySQL-containeren avsluttes umiddelbart Sjekk logger med docker compose logs db. Den vanligste årsaken er et eksisterende volum med inkompatible data. Kjoer 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 foer WordPress starter ved å bruke depends_on-betingelsen vist i konfigurasjonen ovenfor.

Xdebug kobler ikke til Bekreft at host.docker.internal resolves korrekt inne i containeren. På Linux ma 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

#Neste steg for arbeidsflyten din

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 miljoer og Composer med Bedrock for avhengighetsadministrasjon, danner grunnlaget som ethvert serioest WordPress-team trenger i 2026.

Hos wppoland.com bygger og vedlikeholder vi WordPress-prosjekter med noyaktig disse arbeidsflytene. Hvis teamet ditt trenger hjelp med aa modernisere WordPress-utviklingsprosessen, sette opp CI/CD-pipelines eller migrere fra eldre oppsett til containeriserte miljoer, er ingenioerteamet vart tilgjengelig for radgivning og implementering. Prising er alltid individuell og avhenger av omfanget av prosjektet ditt.