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.

#Die Rolle der wp-config.php

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.

#Professionelles Debugging

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.

#Core-Ballast entfernen

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 und Config-Lage

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.

#Checkliste vor dem Launch

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.

#Typische Befunde aus Audits

• 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.