WordPress-Entwickler-Setup, wp-config und Hardening

Die «berühmte 5-Minuten-Installation» ist ein Marketing-Slogan, kein professioneller Standard. Eine Standard-WordPress-Installation ist geschwätzig, unoptimiert und oft unsicher. Als Entwickler installieren wir WordPress nicht nur; wir provisionieren es. Dieser Guide behandelt Konfigurationskonstanten, Debugging-Regeln und Core-Aufräumen, die 2026 in jede Kunden-Boilerplate gehören.

#wp-config.php für Staging und Produktion einrichten

Die Datei steuert Umgebung, Sicherheit und Fehlerverhalten. Nach dem Installer-Wizard darf sie nicht auf Zufallswerten stehen bleiben. Alles Wichtige ist explizit gesetzt, Secrets liegen außerhalb von Git, und die nächste Person im Projekt findet eine kurze Doku neben den Konstanten.

#Umgebungskontrolle

Seit WordPress 5.5 ist WP_ENVIRONMENT_TYPE Standard. Nutze ihn, damit Entwicklungsfehler nicht in Produktion landen.

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

Im eigenen Code:

if ( wp_get_environment_type() === 'production' ) {
	// Caching an, verbose Fehler aus
}

Staging darf Plugin-Installationen und Query Monitor erlauben. Produktion nicht. Eine Konstante ersetzt dann dutzende selbst gebaute WP_LOCAL_DEV-Flags, die Teams vergessen zu synchronisieren.

#Sicherheitshärtung

Verhindere, dass Kunden oder Angreifer die Seite über das Dashboard zerstören.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // nur bei immutable Deployments
define( 'FORCE_SSL_ADMIN', true );

DISALLOW_FILE_EDIT entfernt Theme- und Plugin-Editor. Das stoppt neugierige Redakteure und viele Malware-Pfade, bei denen über den Editor Webshells geschrieben werden. DISALLOW_FILE_MODS ist strenger: keine Installation und kein Update aus der UI. Sinnvoll, wenn CI die Artefakte besitzt. Auf kleineren redaktionellen Sites reicht oft nur DISALLOW_FILE_EDIT, damit Notfall-Updates aus dem Admin noch möglich sind.

#Beitrags-Revisionen und Papierkorb

Datenbank-Wachstum beginnt leise. Hundert Versionen von «Über uns» helfen niemandem.

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

Zehn Revisionen sind ein Kompromiss zwischen Wiederherstellung und Tabellengröße. Kürzere Papierkorb-Fristen reduzieren gelöschte Entwürfe. Ein längeres Autosave-Intervall senkt Schreiblast in hektischen Redaktionen, ohne den Schutz ganz zu entfernen.

#WP_DEBUG_LOG ohne Fehleranzeige einrichten

Zeige niemals Fehler im Frontend. Logge sie.

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' );

Lege die Logdatei außerhalb des Web-Roots ab. /tmp/ ist Notlösung mit oft schlechten Rechten und ohne Rotation. Auf Managed Hosting: Verzeichnis des Anbieters oder eine Ebene über public_html. SAVEQUERIES hilft lokal mit Query Monitor; in Produktion frisst es Speicher.

Live-Diagnose in einer Stunde:

1. WP_DEBUG und WP_DEBUG_LOG einschalten.
2. WP_DEBUG_DISPLAY auf false lassen.
3. Fehler einmal reproduzieren.
4. Logzeile holen, fixen, deployen.
5. Logging noch am selben Tag wieder aus.

Lass keinen «temporären» Debug-Block wochenlang stehen. Er leakt Pfade, SQL und Nutzerdaten an jeden, der die Log-URL findet.

#Emojis und XML-RPC per mu-plugin deaktivieren

WordPress bringt Funktionen mit, die die meisten Business-Sites nicht brauchen: Emoji-Skripte, oEmbeds und XML-RPC. Installiere kein «disable everything»-Plugin. Schreibe ein 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 bleibt ein beliebtes Brute-Force-Ziel. Schalte es ab, außer Jetpack oder eine mobile App brauchen es wirklich. Der Generator-Tag versteckt nur die Versionsnummer; er ersetzt keine Patches. RSD- und Windows-Live-Writer-Links sind für moderne Stacks Rauschen.

Reine Broschüren-Seiten können Feeds schließen. Blogs und News-Sites behalten sie. Kommentiere Feed-Blöcke in der Vorlage aus, statt sie blind zu kopieren.

#Authentifizierungsschlüssel und Salts

Du kennst AUTH_KEY, SECURE_AUTH_KEY und die übrigen Einträge in wp-config.php.

define( 'AUTH_KEY', 'setze-hier-eine-lange-einzigartige-zeichenkette' );
// ... weitere Keys aus der WordPress-Salt-API

Fakt: Das Ändern dieser Schlüssel meldet alle Benutzer sofort ab. Das ist die Notfalloption nach einem Kompromitt. Praxis: Frische Werte bei der Provisionierung von der offiziellen Salt-API holen, in einem Secrets-Manager oder Host-Environment speichern und bei Vorfällen rotieren. Echte Salts gehören nicht in Git.

In Enterprise-Setups automatisieren wir die Rotation per CLI nach Incident Response. Auf kleineren Sites reicht manuelle Rotation bei Verdacht, solange die Prozedur in der Runbook steht.

#Dateirechte für wp-config.php richtig setzen

wp-config.php sollte nach der Provisionierung für den Web-User nicht schreibbar sein. Typisches Linux-Muster:

• Dateien 644, Verzeichnisse 755
• wp-config.php 440 oder 400, wenn der Host das erlaubt
• Keine PHP-Ausführung in uploads (Serverregel)

Manche Teams legen wp-config.php eine Ebene über dem Document Root. WordPress findet sie dort. Das reduziert Risiko bei falsch gesetzter Document Root. Immer zuerst auf Staging testen; manche Panels erwarten die Config im Web-Root.

#Lokale Entwicklungsumgebung mit wp-env und Docker

Manuelle Apache- und PHP-Installationen auf lokalen Rechnern driften schnell auseinander. Ein Entwickler arbeitet mit PHP 8.2, ein anderer noch mit 8.1, und Fehler treten erst in der CI-Pipeline auf. Der offizielle Standard für wiederholbare Umgebungen ist wp-env, gesteuert über Docker-Container und eine deklarative Konfiguration in .wp-env.json im Projektstamm.

Installiere das Paket als Entwicklungsabhängigkeit:

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

Eine praxiserprobte .wp-env.json für Plugin- und Theme-Entwicklung bindet das Projektverzeichnis direkt in WordPress ein:

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

Vorteile dieses Ansatzes im Entwicklungsteam:

• Die WordPress-Core-Version ist im Git-Repository fixiert, wodurch Versionsunterschiede entfallen.
• Über npx wp-env run cli wp steht das offizielle WP-CLI direkt in denselben Containern zur Verfügung.
• Testskripte und E2E-Pipelines aus dem @wordpress/scripts-Ökosystem greifen nahtlos auf die Instanz zu.

Nützliche Befehle im Alltag nach dem Start des Stacks:

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

#Composer 2 für WordPress-Abhängigkeiten und Plugins einrichten

Composer 2 verwaltet PHP-Bibliotheken, Plugins, Themes und Entwickler-Tools deterministisch im gesamten Team. In professionellen WordPress-Projekten sollten Abhängigkeiten niemals als unversionierte Zip-Dateien manuell in Git committet werden. Über Composer lassen sich Versionen exakt sperren, Sicherheitsupdates automatisieren und Repositories schlank halten.

WordPress-Plugins und Themes von WordPress.org können über das öffentliche Repository WPackagist (wpackagist.org) direkt bezogen werden. Das Paket composer/installers sorgt dafür, dass Plugins im Verzeichnis wp-content/plugins/ und Must-Use-Plugins in wp-content/mu-plugins/ abgelegt werden:

{
  "name": "wppoland/wordpress-projekt",
  "description": "WordPress-Entwickler-Setup mit 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/"
  }
}

Committe composer.lock ausnahmslos in die Versionskontrolle. Die Lock-Datei garantiert identische Paketstände auf allen Entwickler-Laptops und CI-Servern. Auf Produktivservern führst du beim Deployment composer install --no-dev --optimize-autoloader aus, um Entwickler-Tools auszuschließen und den PHP-Klassen-Autoloader zu optimieren.

#Statische Code-Analyse und PHP-Standards mit PHPCS und PHPStan

Während Frontend-Linter JavaScript und CSS prüfen, erfordert serverseitiger PHP-Code die gleiche Sorgfalt. Statische Code-Analyse und Coding-Standards verhindern Syntaxfehler, ungeprüfte Eingaben und fehlende Sicherheits-Nonces vor dem Code-Review.

#WordPress Coding Standards mit PHPCS durchsetzen

WordPress definiert offizielle Programmierstandards (WPCS) über PHP_CodeSniffer. Diese Regeln validieren Namenskonventionen, Array-Strukturen sowie kritische Sicherheitsaspekte wie unmaskierte Eingaben in $_POST oder fehlende Sanitizing-Funktionen wie sanitize_text_field() und esc_html().

Konfiguriere eine phpcs.xml.dist im Projektstamm:

<?xml version="1.0"?>
<ruleset name="WordPress Project Standards">
  <description>PHPCS-Regelsatz für WordPress-Projekte.</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>

Führe composer run phpcs vor jedem Pull Request aus. Bei reinen Formatierungsfehlern korrigiert composer run phpcbf Einrückungen und Whitespaces automatisch, ohne die Programmlogik zu verändern.

#Tiefenanalyse mit PHPStan und phpstan-wordpress

PHPCS prüft Syntax und Formatierung, analysiert jedoch keine Typsicherheit oder Aufrufhierarchien. PHPStan prüft PHP-Code ohne Programmausführung und deckt nicht existierende Methoden, inkompatible Parametertypen und unerreichten Code auf. Da WordPress dynamische Hook-Systeme nutzt, stellt die Erweiterung szepeviktor/phpstan-wordpress Typdefinitionen für Core-Funktionen, WP_Post-Eigenschaften und Hook-Argumente bereit.

Konfiguriere phpstan.neon.dist auf Regelstufe 6:

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

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

Die Einbindung von PHPStan in CI-Pipelines stellt sicher, dass Funktionsanpassungen oder geänderte Filter-Callbacks im Produktivbetrieb keine fatalen Fehler verursachen.

#Xdebug 3 in Docker-Umgebungen und IDE-Schritt-Debugging einrichten

Ausschließliches Debugging über var_dump() oder Logdateien verlangsamt die Fehlersuche bei komplexen Filtern, REST-Endpunkten oder Datenbanktransaktionen. Xdebug 3 ermöglicht schrittweises Debuggen, Aufrufstapel-Prüfung und Variablen-Inspektion direkt in Visual Studio Code oder PhpStorm.

In Docker-Umgebungen wie wp-env läuft Xdebug im Anwendungscontainer und verbindet sich mit der IDE auf dem Host-System:

[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

Die Direktive xdebug.start_with_request=trigger ist entscheidend für die Arbeitsgeschwindigkeit. Wenn Xdebug bei jedem HTTP-Request anspringt, steigen die Antwortzeiten drastisch. Im Trigger-Modus aktiviert sich der Debugger nur bei gesetztem XDEBUG_SESSION-Cookie oder URL-Parameter, steuerbar über Browser-Erweiterungen wie Xdebug Helper.

In Visual Studio Code konfigurierst du .vscode/launch.json mit passenden Pfadzuweisungen:

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

Pfadzuweisungen stellen sicher, dass Breakpoints im Editor exakt mit dem ausgeführten Code im Container übereinstimmen. Aktiviere Xdebug niemals auf Produktivservern; der Performance-Overhead reduziert Durchsatz und legt interne Variablen offen.

#Erweiterte wp-config-Konstanten für Speicher und Datenbank

Die Datei wp-config.php steuert das Laufzeitverhalten, bevor WordPress Themes oder Plugins lädt. Neben grundlegenden Debug-Flags konfigurieren Entwickler Speicherlimits, Cron-Steuerung und Datenbank-Wartungsmodi.

#Speicherlimits und Hintergrundprozesse

Standardmäßig reserviert WordPress 40 MB PHP-Speicher für Frontend-Anfragen. WooCommerce-Shops, Block-Layouts und REST-Aufrufe überschreiten dieses Limit unter Last schnell, was zu Speicherabbrüchen führt. Setze explizite Werte:

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

WP_MAX_MEMORY_LIMIT greift bei Administrationsaufgaben sowie rechenintensiven Hintergrundprozessen wie Bildskalierung, Importläufen und Datenbankschema-Upgrades.

#WP-Cron vom HTTP-Besucherverkehr entkoppeln

Standardmäßig führt WordPress Cron-Jobs während regulärer Seitenaufrufe durch Webseitenbesucher aus. Auf wenig besuchten Seiten verzögern sich geplante Beiträge. Bei starkem Traffic erzeugen gleichzeitige Besucher parallele Cron-Prozesse, die die Datenbank überlasten.

Deaktiviere den besuchergesteuerten Cron in wp-config.php:

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

Richte anschließend einen System-Cronjob auf dem Server oder im Container ein, der WP-CLI alle fünf Minuten ausführt:

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

#Dateisystem-Berechtigungen und Datenbankreparatur

Wenn WordPress bei Uploads nach FTP-Zugangsdaten fragt, greifen manche Teams fälschlicherweise zu 777-Berechtigungen. Die saubere Lösung ist die direkte Zuweisung der Dateisystem-Methode:

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

Bei Datenbankfehlern bietet WordPress unter /wp-admin/maint/repair.php ein Reparaturwerkzeug. Aktiviere es nur für den Wartungszeitraum:

define( WP_ALLOW_REPAIR, true );

Entferne die Konstante WP_ALLOW_REPAIR sofort nach Abschluss der Reparatur. Bleibt sie aktiv, können unauthentifizierte Besucher Reparatur- und Optimierungsläufe anstoßen.

#WP-CLI-Befehle für automatisierte Workflows

Das offizielle WP-CLI-Handbuch definiert die Standardwerkzeuge zur Automatisierung administrativer Aufgaben ohne Web-Dashboard. In Docker- und wp-env-Umgebungen lassen sich Core-Befehle direkt im Terminal absetzen:

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

Besonders bei Migrationen und Datenbank-Imports spart WP-CLI wertvolle Stunden: Es verarbeitet serialisierte PHP-Arrays in der Datenbank korrekt, während ein unüberlegtes Suchen-und-Ersetzen in SQL-Dumps Datenstrukturen beschädigt. Mit --dry-run überprüfst du gefundene Übereinstimmungen vor der Ausführung.

#Staging-Parität und Hygiene im Ordner wp-content

Eine lokale Entwicklungsumgebung, die nur oberflächlich dem Staging-Server ähnelt, führt zu unerwarteten Problemen beim Deployment. Parität bedeutet nicht zwingend eine vollständige Kopie aller Produktivmedien, sondern die Angleichung aller betriebsrelevanten Parameter:

1. Identische PHP- und MySQL-Hauptversionen zwischen lokalem Docker und Staging.
2. Konsistenter WP_ENVIRONMENT_TYPE (lokal local, Staging staging, Live production).
3. Gleiche aktive Plugins, pin-genau über composer.lock verwaltet.
4. Bereinigung von Entwicklungsüberresten: Logdateien wie debug.log, SQL-Dumps und CSV-Exporte dürfen niemals im öffentlich erreichbaren Web-Root verbleiben.
5. Ausschluss des Ordners uploads/ aus der Git-Versionskontrolle, abgesehen von minimalen Test-Fixtures.

#Gutenberg-Blockentwicklung mit create-block und build-Pipelines

Maßgeschneiderte Gutenberg-Blöcke gehören 2026 zum Standard moderner WordPress-Architekturen. Anstelle manueller Webpack-Konfigurationen setzt das Core-Team auf das offizielle Gerüst @wordpress/create-block und die Build-Pipeline von @wordpress/scripts:

npx @wordpress/create-block mein-kundenblock --variant dynamic
cd mein-kundenblock
npm run start

Moderne Blöcke deklarieren ihre Eigenschaften in block.json. Dies ermöglicht serverseitiges Caching der Block-Metadaten und schlanke Registrierung in PHP über register_block_type( __DIR__ . "/build" ). Halte Editor- und Frontend-Skripte in block.json strikt getrennt (editorScript für React-basierte Bearbeitungsoberflächen, viewScript für minimale Interaktivität im Frontend), um keine überflüssigen Abhängigkeiten an Seitenbesucher auszuliefern.

#WordPress-Checkliste vor dem Go-live

1. WP_ENVIRONMENT_TYPE auf production setzen.
2. DISALLOW_FILE_EDIT auf true setzen.
3. DISALLOW_FILE_MODS je nach Deploy-Modell entscheiden.
4. WP_POST_REVISIONS begrenzen (zum Beispiel auf 10).
5. WP_DEBUG_LOG in privaten Ordner legen; Display aus.
6. Emojis und XML-RPC per mu-plugin deaktivieren.
7. FORCE_SSL_ADMIN und HTTPS für den gesamten Admin prüfen.
8. Sicherstellen, dass Salts keine Placeholder-Strings sind.
9. Backup ziehen, bevor Salts oder FILE_MODS live geändert werden.

#Häufige wp-config-Fehler aus Sicherheitsaudits

• Debug-Display in Produktion nach einem «schnellen Fix».
• Standard-Salts aus einer alten Boilerplate, kopiert über Kunden hinweg.
• Dateieditor offen, «weil der Kunde CSS anfassen wollte».
• Sicherheits-Plugin aktiv, während wp-config unberührt blieb.
• Unbegrenzte Revisionen bei täglich geänderten WooCommerce-Texten.

#Zusammenfassung

Eine gut konfigurierte WordPress-Instanz ist leise, sicher und vorhersehbar. Konstanten in der wp-config.php, Logging ohne Leak und ein dünnes mu-plugin für Core-Aufräumen bringen mehr als noch ein Dashboard-Plugin. Nutze die Checkliste oben als Vorlage in jedem Kundenprojekt, nicht als Einmal-Liste.

Mehr über unsere WordPress-Sicherheitsaudits. Für Provisionierung oder das Aufräumen einer bestehenden Installation erreichst du uns über das Kontaktformular.