Kaum eine andere Datei einer WordPress-Installation ist so wichtig wie die wp-config.php und dennoch fristet sie in den meisten Fällen ein Schattendasein. Höchste Zeit, dass wir uns genauer ansehen, was diese zentrale Datei tut, wie sie bearbeitet werden kann und warum sich das Bearbeiten lohnen könnte.
Die Konfigurationsdatei
Neben vielen Einstellungen, die ein Admin-Benutzer in WordPress über das Admin-Interface setzen kann, gibt es eine Reihe von Einstellungen, für die WordPress die wp-config.php zu Rate zieht.
Würden wir diese Datei aus einer WordPress-Installation entfernen, müsste diese sofort den Betrieb einstellen. Nach einigen einleitenden Kommentaren enthält die Konfigurationsdatei nämlich gleich am Anfang Zugangsdaten und Einstellungen für die Datenbank, in der WordPress einen Großteil seiner Inhalte ablegt.
Diese Daten werden, zusammen mit ein paar anderen grundlegenden Voreinstellungen, bei der Ersteinrichtung von WordPress in der wp-config.php abgelegt. Wenn eine Website später zu einem anderen Hoster umzieht oder eine Test-Umgebung eingerichtet wird, muss die Konfigurationsdatei in der Regel angepasst werden, um WordPress wieder/weiterhin Zugang zur Datenbank zu geben.
Darüber hinaus gibt es eine ganze Batterie praktischer Ergänzungen, die zur wp-config.php hinzugefügt werden können.
wp-config.php bearbeiten
Zum Bearbeiten der wp-config.php müssen wir uns zunächst per FTP mit dem Server verbinden. Vor irgendwelchen Änderungen an der Datei empfiehlt sich dringend eine Sicherheitskopie, mit der im Zweifelsfall der Originalzustand wiederhergestellt werden kann, falls etwas schief läuft.
Auch wenn die Datei theoretisch eine Ebene weiter nach oben verschoben werden kann, findet sie sich in der Regel im Hauptverzeichnis einer WordPress-Installation, sollte also auf derselben Ebene liegen, wie beispielsweise das wp-content-Verzeichnis.
Bestandsaufnahme
In den allermeisten Fällen sollte die Konfigurationsdatei mit diesen Standard-Werten ausgestattet sein. Beim Einsatz automatischer Installer von Hostern können dort auch zusätzliche Informationen abgelegt worden sein.
Datenbank-Einstellungen
Neben Datenbankname, Datenbankbenutzer, Datenbank-Host und -Passwort, die allesamt in der Regel angepasst werden müssen, wenn die Website auf einen neuen Server umzieht, finden sich hier mit DB_CHARSET auch der Zeichensatz der Datenbank und DB_COLLATE mit Regeln zur Sortierung der Datenbank.
$table_prefix enthält ein Präfix, das zur Benennung der Datenbank-Tabellen genutzt wird, die WordPress anlegt. Dieses Präfix kann nach der Installation geändert werden. In diesem Fall müssen aber auch die Namen der Tabellen geändert werden, sonst verhält sich die bestehende WordPress-Installation plötzlich wie fabrikneu und „vergisst“ zumindest vorübergehend alle Inhalte. Das Ändern des Präfix von wp_ auf eine eigene Zeichenfolge bringt im Übrigen keinen Zugewinn an Sicherheit für die Website, auch wenn sich dieses Gerücht hartnäckig hält.
// ** MySQL settings ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'krautpress' );
/** MySQL database username */
define( 'DB_USER', 'krautpress' );
/** MySQL database password */
define( 'DB_PASSWORD', 'as9upQ/JAscdoq2' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );
/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8mb4' );
/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );
/** WordPress Database Table prefix. */
$table_prefix = 'wp_';Code-Sprache: PHP (php)Keys und Salts
Mit einer Reihe bei der Installation zufällig generierter Zeichenketten sichert WordPress zum Beispiel Passwörter und Anmelde-Cookies ab.
Sollten die Keys und Salts aus irgendwelche Gründen leer sein, empfiehlt es sich, neue zu generieren und einzutragen.
Debug-Einstellungen
WP_DEBUG sollte in der Regel auf false gestellt sein, weil sonst Fehler, die beim Seitenaufbau auftreten, direkt ausgegeben würden. Diese Option ist für Entwicklerinnen und Entwickler aber häufig nützlich.
define( 'WP_DEBUG', false );Code-Sprache: JavaScript (javascript)Fixe Einträge
Die folgenden Verweise auf weitere WordPress-Core-Dateien und den Pfad zur WordPress-Installation sollten nicht verändert werden. Oberhalb dieses Abschnitts können aber eigene Einträge hinzugefügt werden.
Eigene Ergänzungen
Ich würde grundsätzlich in zwei Kategorien von Ergänzungen für die wp-config.php unterscheiden. Auf der einen Seite die Einstellungen, die WordPress bei der Installation nicht automatisch setzt, die aber dennoch vom WordPress-Core zur Nutzung vorgesehen sind.
Auf der anderen Seite nutzen Plugins von Zeit zu Zeit PHP-Konstanten, die in die Konfigurationsdatei eingesetzt werden können um das Verhalten des Plugins zu beeinflussen und z.B. Einstellungen fix auf einen bestimmten Wert zu setzen.
Website-URLs
Einer der häufigsten WordPress-Fehler, die ich in den letzten Jahren gesehen habe, wurde durch die Änderung einer einzigen Einstellung im WordPress-Backend ausgelöst.
Werden die beiden Werte WP_HOME und WP_SITEURL hingegen über die wp-config.php gesetzt, sind die Optionen im Backend inaktiv und die beiden Werte für die Home-URL und die Website-URL sind dauerhaft festgeschrieben.
/* Custom WordPress URL. */
define( 'WP_SITEURL', 'https://krautpress.de/' );
define( 'WP_HOME', 'https://krautpress.de/' );Code-Sprache: JavaScript (javascript)Update-Verhalten
Wie ich vor wenigen Tagen beschrieben habe, kann über WP_AUTO_UPDATE_CORE das Update-Verhalten des WordPress-Core angepasst werden. Neben dem einfachen Deaktivieren von Core-Updates über den Wert false, kleine Versionssprünge mit minor und alle Versionsspürnge mit true sind hier zum Beispiel auch beta und RC Auswahlmöglichkeiten, was vor allem für interessierte Entwicklerinnen und Entwickler hilfreich sein kann.
define( 'WP_AUTO_UPDATE_CORE', true );Code-Sprache: JavaScript (javascript)Datei-Editor deaktivieren
Für mich gehört eine Änderung an der Konfiguration zu den ersten Amtshandlungen bei jeder WordPress-Installation, die ich in die Finger bekomme: das Deaktivieren des Datei-Editors für Plugins und Themes. Damit unterbinde ich, dass Admin-User Änderungen an Dateien vornehmen können.
Damit verhindere ich nicht nur versehentliche Änderungen an diesen Dateien, sondern sichere sie auch gegen mutwillige Bearbeitung ab, die zum Beispiel ein Angreifer vornehmen könnte, der einen Benutzer-Zugang geknackt hat.
define( 'DISALLOW_FILE_EDIT', true );Code-Sprache: JavaScript (javascript)Revisionen limitieren
Die Anzahl der Speicherstände, die WordPress für den Bearbeitungsverlauf einer Seite oder eines Beitrags aufbewahrt, lässt sich mit WP_POST_REVISIONS entweder durch die Angabe einer Ziffer limitieren oder mit false ganz abschalten, was ich nicht empfehlen würde.
define( 'WP_POST_REVISIONS', 3 );Code-Sprache: JavaScript (javascript)Multisite
Der Multisite-Modus, in dem aus einer WordPress-Installation gleich mehrere Websites mit unterschiedlichen (Sub-)Domains, Themes und Usern betrieben werden können, wird ebenfalls über die wp-config.php aktiviert.
Ist die Konstante WP_ALLOW_MULTISITE gesetzt, wird die weitere Einrichtung der Multisite über das Interface im WordPress-Backend durchgeführt.
define( 'WP_ALLOW_MULTISITE', true );Code-Sprache: JavaScript (javascript)Auf WordPress.org findet sich eine vollständige Liste der nutzbaren Konstanten für die wp-config.php.
Eine Änderung der von dir erwähnten Konstanten `WP_SITEURL` und `WP_HOME` in der `wp-config.php` wird leider in vielen Blog-Beiträgen als bequeme Möglichkeit genannt, einen Domain-Wechsel umzusetzen. Ich glaube nicht, dass das im Sinne der Erfinder ist, weil durch die Konstanten die vorhandenen Einträge in der Datenbank nicht ersetzt, sondern überschrieben werden. Im Ergebnis sind die beiden Eingabefelder im Menü Einstellungen > Allgemein ausgegraut und spätestens bei der Übernahme der Website durch einen neuen Administrator taucht dann die Frage auf, warum das so ist. Dabei ist eine Ersetzung der URL in der Datenbank trotzdem nötig, weil WordPress durch die Definition dieser Konstanten nicht in Blogbeiträgen verwendete Links oder die für Mediendateien verwendeten, absoluten URLs anpasst.
Die Verwendung der Konstanten halte ich hingegen für sinnvoll, wenn eine Website parallel in einer Entwicklungsumgebung geführt wird. Überträgt der Entwickler alle Dateien mit Ausnahme der Konfigurationsdatei `wp-config.php`, kann auch die Datenbank unverändert übernommen werden, weil der Eintrag der Konstanten die Datenbankeinträge (diesmal erwünscht) überschreibt.
Deine „erste Amtshandlung“, den internen Theme- und Plugin-Editor durch die Konstante `define( ‚DISALLOW_FILE_EDIT‘, true );` zu deaktivieren, sehe ich mit gemischten Gefühlen. Gegenüber älteren Versionen des Editor, der die komplette Website bei all zu unbedarften Anpassungen komplett unbrauchbar machte, gibt es einerseits einige Verbesserungen, die AnwenderInnen vor sich selbst schützen. Andererseits wird in der Dokumentation (https://wordpress.org/support/article/editing-wp-config-php/#disable-the-plugin-and-theme-editor) auch darauf hingewiesen, dass Plugins fehlerhaft funktionieren könnten, wenn sie die Abfrage `current_user_can(‚edit_plugins‘)` als Nachweis der Legitimation des Benutzers abfragen, die mit der Konstante ausgeschlossen wird. Die Beantwortung der Frage „warum funktiert bloss dieses Plugin bei mir nicht?“ wird dann recht kniffelig.
Da gibst du mir viel zu denken. 🙂
Zu
WP_SITEURLundWP_HOME: definitiv, zum Umzug taugt das nicht. Die dafür passendedefine( 'RELOCATE', true );habe ich im Artikel tatsächlich unterschlagen.Das den Code-Editor angeht: tatsächlich hatte ich da noch nie Probleme. Aber das Set an Drittanbieter-Plugins, das zu meinem regulären Fuhrpark gehört, ist auch relativ überschaubar.
Hallo Simon,
danke für den Artikel.
Ich habe eine Frage zu Multisite: Hast du einen Tipp, wo ich die Einrichtungsschritte zu einer Multisite aus einer „einfachen“ WP Installation nachlesen kann (möglichst deutsch)?
Danke
Hi Jonas,
sehr gute Frage. Tatsächlich fällt mir spontan kein passender Artikel ein, den ich weiterempfehlen würde.
Hättest du das mal ein paar Tage früher gefragt, wäre es perfekt für den Adventskalender gewesen. 🙂
Ich schreibe es mir mal ganz oben auf die Liste und versuche Anfang des Jahres ein bisschen was dazu zu schreiben.