WordPress: Angaben in der wp-config.php

Die wp-config.php-Datei zählt zu den wichtigsten Dateien in WordPress. Hier werden grundlegende Daten wie zum Beispiel die Verbindung zur Datenbank festgehalten. Darüber hinaus können zusätzliche Einstellungen und Richtlinien vorgenommen werden, die WordPress in vielen Bereichen optimieren.
Vielen Seitenbetreibern ist gar nicht das Potential bewusst, welches sie durch Nicht-Nutzung der wp-config.php verschenken. Deshalb habe ich diesen Artikel geschrieben.

Zwar liegt dem Installationspaket von WordPress auch immer eine wp-config-sample.php Beispieldatei bei, aber dort sind nicht alle potentiellen Einstellungen aufgeführt.

Warnung: Alle Änderungen an der wp-config.php-Datei erfolgen auf eigene Verantwortung. Bei einigen WordPress Plugins und Themes kann es unter Umständen zu Inkompatibilitäten kommen.

wp-config.php Standardeinstellungen

Ohne Verbindung zur Datenbank läuft bei WordPress nichts. Aus diesem Grund steht dieser Anweisungsblock ziemlich weit vorn in der wp-config.php:

Database Name
Hier trägt man den Namen der Datenbank ein

Database Username
Hier trägt man den Datenbank Benutzernamen ein

Database Password
Hier trägt man das Passwort des Benutzers der Datenbank ein

Database Host
Adresse des Datenbankserver.

Beim Host wird meistens localhost eingetragen. Das ist allerdings von eurem Provider abhängig. Abweichungen vom 3306 Standardport werden so eingetragen:

define('DB_HOST', 'localhost:0815');

oder auch so:

define('DB_HOST', 'meindatenbankserver.com:0815');

Arbeitet der Datenbankserver mit Unix Sockets oder Pipes, erfolgt die Notation folgendermaßen:

define('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock');

Database character set

define('DB_CHARSET', 'utf8');

Mit utf8 liegt ihr meistens immer richtig. Da diese Zeichensatz-Problematik nur Schmerzen verursacht, lasse ich auch die nächste Angabe in der Standardeinstellung.

Database collation

define('DB_COLLATE', '');

Sicherheit

Es lassen sich erstaunlich viele Sicherheitseinstellungen in der wp-config.php vornehmen. Das betrifft nicht nur die Security Keys.

Security Keys

Dieser Bereich wurde seit den 2.x Versionen stetig ausgebaut. Die Keys dienen dazu, die Sicherheit der Daten im Nutzer Cookie zu erhöhen. Es empfiehlt sich, den Onlinegenerator zu benutzen und die Werte einfach zu übernehmen. Es sind aber keine zwingend notwendigen Einträge.

define('AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|');
define('SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj');
define('LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^');
define('NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe');
define('AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G');
define('SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #');
define('LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i');
define('NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%');

Plugin und Theme Editor deaktivieren

Ich kann mich nicht mehr an den genauen Zeitpunkt oder die Version erinnern, als es Nutzern gestattet war, den Quellcode von Themes oder Plugins zu verändern. Gut finde ich das bis heute nicht und die Mehrheit der Nutzer weiß auch gar nicht, was sie da tut. Mit diesem Befehl schaltet man diese Möglichkeit ab:

define('DISALLOW_FILE_EDIT', true);

Installation und Updates von Themes und Plugins

Möchte man den Nutzern auf dem System das Installieren und Updaten von Themes und/oder Plugins untersagen, setzt man diese Option:

define('DISALLOW_FILE_MODS', true);

Ist DISALLOW_FILE_MODS gesetzt, ist DISALLOW_FILE_EDIT nicht mehr nötig.

SSL Verbindungen erzwingen

Um die Anmeldung für Nutzer und des Adminbereiches über eine SSL verschlüsselte Verbindung zu erzwingen, stehen die zwei Angaben zur Verfügung:

define('FORCE_SSL_LOGIN', true);

define('FORCE_SSL_ADMIN', true);

Auf Nummer Sicher geht man mit der FORCE_SSL_ADMIN Option.

Externe URL Requests blockieren

Welcher Server darf Anfragen an das WordPress System stellen? Bzw. welcher nicht? Setzt man die folgende Einstellung auf true, darf nur localhost Requests an WordPress richten:

define('WP_HTTP_BLOCK_EXTERNAL', true);

Möchte man dennoch Anfragen bestimmter Server oder Dienste durchlassen, muss man den (oder die) Server explizit auflisten:

define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.externerserver.de');

Sind es mehrere Server, so werden sie durch Kommata getrennt hintereinander weggeschrieben. Alle Subdomains können durch die * Angabe eingeschlossen werden. IP Adressen müssten auch funktionieren.

Table Prefix

$table_prefix = 'thx1138';

Standardmäßig erhalten die Tabellennamen einer WordPress-Installation das Präfix wp_. Möchte man einen anderen Namensvorsatz vergeben (zum Beispiel aus Sicherheitsgründen), stellt man das mittels dieser Angabe ein. Es sind nur Zahlen, Buchstaben und der Unterstrich erlaubt.

WP SITEURL

Diese Angabe legt fest, wo die Kerndateien einer WordPress Installation zu finden sind. Eventuell anderslautende Einträge im Backend bzw. in der options Tabelle werden hiervon überschrieben. Bei dieser Angabe darf kein Slash am Ende der URL stehen:

define('WP_SITEURL', 'https://beispiel.de/meinwordpressverzeichnis');

Es ist auch möglich, den Servernamen als Bestandteil der URL dynamisch ausgeben zu lassen:

define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/pfadzuwordpress');

Da man dort aber ein Sicherheitsrisiko sieht, wird diese statische Methode empfohlen:

define('WP_SITEURL', 'https://' . $_SERVER['SERVER_NAME'] . '/pfadzuwordpress');

WP Home

Welche URL müssen die Nutzer eintippen, um auf den Blog zu gelangen? Der Eintrag WP_Home legt dies fest und überschreibt auch hier wieder den eigentlichen Wert in der wp_options Tabelle. Wieder darf kein Slash am Ende der URL stehen und dynamische Werte sind auch möglich:

define('WP_HOME', 'https://beispielseite.de/wordpressverzeichnis');

Gebraucht wird diese Option vor allem, wenn WordPress in einem Unterverzeichnis einer Domain liegt, aber dennoch über die Domain URL aufgerufen werden soll.

WP Content verschieben

Seit WordPress 2.6 kann man den gesamten WP Content Ordner verschieben. WordPress sucht die Plugins, Uploads und Themes am angegebenen Ort:

define('WP_CONTENT_DIR', dirname(__FILE__) . '/andererordner/wp-content');

Und dann, wie die URI dafür lautet:

define('WP_CONTENT_URL', 'https://beispielseite/anderesverzeichnis/wp-content');

Das geht natürlich auch nur mit dem Plugin Ordner:

define('WP_PLUGIN_DIR', dirname(__FILE__) . '/anderesverzeichnis/wp-content/plugins');
define('WP_PLUGIN_URL', 'https://example/anderesverzeichnis/wp-content/plugins');

Der Themes Ordner hingegen ist fest verdrahtet, wie hier ersichtlich wird:

$theme_root = WP_CONTENT_DIR . '/themes';

Der Pfad zum Uploads Ordner wird hier festgelegt:

define('UPLOADS', '/blog/wp-content/uploads');

Den Upload aller Dateitypen zulassen

Das klingt verlockend, öffnet aber meiner Ansicht nach den Tentakelwesen aus der Kerkerdimension Tür und Tor:

define('ALLOW_UNFILTERED_UPLOADS', true);

Autosave Interval

define('AUTOSAVE_INTERVAL', 300);

Standardmäßig speichert WordPress alle 60 Sekunden den aktuellen Stand eines gerade zu bearbeitenden Artikels als Revision ab. In meinem Beispiel habe ich den Wert mal auf 5 Minuten gesetzt. Die Angabe hat immer in Sekunden zu erfolgen.

Wie man sieht, kann diese Funktion dafür sorgen, dass eure Revisions schnell anwachsen und die Datenbank immer größer wird. Dagegen kann man aber etwas tun:

Revisionen

Post Revisions

Entweder, ihr schaltet die Revisions Funktion ganz ab:

define('WP_POST_REVISIONS', false);

Oder beschränkt diese auf die letzten x (ich finde, 5 ist ein guter Wert) Versionen:

define('WP_POST_REVISIONS', 5);

Cookie Domain

So setzt man eine spezielle Cookie Domain für WordPress:

define('COOKIE_DOMAIN', 'www.askapache.com');

Debugging

Die Debugging Funktion in WordPress ist standardmäßig abgeschaltet. Wer Fehler in der Installation auswerten möchte, muss das Debuging aktivieren:

define('WP_DEBUG', true);

Dann sind auch WP_DEBUG_DISPLAY und WP_DEBUG_LOG möglich.

Ich halte es persönlich nicht für sinnvoll, in den Javascript bzw. CSS Dateien vom WordPress Kernsystem zu arbeiten. Aber wer das tun möchte, sollte folgende Einstellung setzen:

define('SCRIPT_DEBUG', true);

Javascript Concatenation

Damit das Arbeiten für den Admin schneller geht, fasst WordPress die Javascript Dateien zusammen und liefert diese gebündelt aus. Sollte dies unerwarteterweise Probleme bereiten, schaltet man dieses Verhalten ab:

define('CONCATENATE_SCRIPTS', false);

PHP Memory Limit

Je nach Provider und Hostingumgebung kann der PHP Arbeitsspeicher erhöht werden, den WordPress belegen kann, bevor der Webserver aussteigt. Mittlerweile sind die 32 MB oder 64 MB für ein voll ausgestattetes WordPress viel zu wenig. Dann kann man den Speicher mit dieser Angabe erhöhen:

define('WP_MEMORY_LIMIT', '128M');

Die folgene Angabe wirkt sich extra auf den Adminbereich aus:

define('WP_MAX_MEMORY_LIMIT', '256M');

WP Cache

Viele Cache Plugins benötigen diesen Eintrag:

define('WP_CACHE', true);

CustomUser Table und Custom User Meta Table

Man kann auch eigene Tabellen für die WordPress Nutzer verwenden. Ich weiss allerdings nicht, ob das ergänzend zu den Standardtabellen geschieht oder diese dadurch inaktiv sind:

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

WP Language

Diese Angabe ist seit WordPress Version 6.x (?) veraltet und wird nicht mehr berücksichtigt.
Diese Optionen teilen dem System mit, wo sich das Verzeichnis mit den Übersetzungsdateien befindet und wie diese benannt sind:

define('WPLANG', 'de_DE');
define('WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages');

Save Queries

Manchmal ist es hilfreich zu analysieren, welche Datenbankabfragen das System generiert. Die folgende Variable speichert alle Anfragen (aufgerufene Funktion, Zeitdauer etc.) in einem Array und sollte daher nur während des Debugging aktiv sein:

define('SAVEQUERIES', true);

File Permissions

Hat der Webhoster strikte Regeln bei den Datei/Verzeichnisberechtigungen erlassen, ist das automatische Einspielen von Updates nicht mehr möglich ist. Mit dieser Einstellung kann man sich behelfen, aber ich halte wenig davon. Der Webhoster wird schon wissen, weshalb er dieses Setup gewählt hat. Nichtsdestotrotz hier die Befehle zum Aushebeln dieses Sicherheitsfeatures:

define('FS_CHMOD_DIR', ( 0755 & ~ umask() ));
define('FS_CHMOD_FILE', ( 0644 & ~ umask() ));

WordPress Upgrade

So ein Update auf Knopfdruck ist super komfortabel, aber eben auch nicht wirklich ein Ausweis einer strikten Sicherheitsarchitektur. Wer auf Serverumgebungen mit getrennten Webserver- und FTP-Usern Updates einspielen will, ohne jedesmal die FTP Zugangsdaten eingeben zu müssen – kann es mit diesen erweiterten Einträgen für die wp-config.php versuchen:

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/pfadzuwordpress/');
define('FTP_CONTENT_DIR', '/pfadzuwordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/pfadzuwordpress/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.beispielseite.de');
define('FTP_SSL', false);

WP Cron Jobs

Cron Jobs sind eine feine Sache und in WordPress teilweise auch zu steuern. Wenn z.B. der normale Cron-Job bei den geplanten Artikelveröffentlichungen seine Arbeit einstellt, kann man den alternativen Dienst aktivieren:

define('ALTERNATE_WP_CRON', true);

Die Cron-Jobs deaktiviert man so:

define('DISABLE_WP_CRON', true);

Jeder Crob-Job kann nur einmal in einem bestimmten Zeitraum (in Sekunden anzugeben) angestossen werden:

define('WP_CRON_LOCK_TIMEOUT', 120);

Papierkorb / Trash

Empty Trash

Der WordPress eigene Papierkorb (Trash) speichert alle gelöschten Beiträge, Seiten, Artikelbilder und Kommentare so lange, bis man den Papierkorb expliziert leert. Allerdings gibt es dafür auch einen Automatismus. Die Angabe erfolgt in Tagen:

define('EMPTY_TRASH_DAYS', 7);

Mit der Angabe 0 kann man den Papierkorb ganz abschalten. Dann wird beim Löschen gleich richtig gelöscht. Weg ist dann weg.

define('EMPTY_TRASH_DAYS', 0);

Selbst mir war die Papierkorb-Funktion nur für die Mediathek unbekannt:

define('MEDIA_TRASH', true);

Database Optimization

define('WP_ALLOW_REPAIR', true);

Wenn ich das richtig verstanden habe, setzt man diese Funktion auf true, wenn man sich im Falle einer verhauenen Datenbank nicht mehr in das System selbst einloggen kann. Dabei wird die Funktion nur aktiviert, während der Aufruf des Skriptes händisch erfolgen muss:

{deinewordpressseite}/wp-admin/maint/repair.php

Upgrades bei globalen Tabellen

Es gibt Fälle, da sind die globalen Tabellen so angewachsen (User und Usermeta), dass ein Upgrade auf diese Tabellen zu lange dauert und eventuell sogar abbricht. Um das zu verhindern, kann man diese Tabellen von Änderungs- oder Löschungs-Anfragen ausnehmen:

define('DO_NOT_UPGRADE_GLOBAL_TABLES', true);

Automatisches Update der Kerndateien einstellen

Man kann auch die Kerndateien vom automatischen Update ausschliessen.

define('WP_AUTO_UPDATE_CORE', false);

Der Wert true würde ein automatisches Updaten erlauben.

Interessant ist auch die Idee, nur Minor Updates zuzulassen:

define('WP_AUTO_UPDATE_CORE', 'minor');

Hiermit setzt ihr die automatische Update Funktion aus:

define('AUTOMATIC_UPDATER_DISABLED', true);

Wenn ihr nur die Themes und Plugins vom automatischen Update ausnehmen wollt, definiert das so:

define('CORE_UPGRADE_SKIP_NEW_BUNDLED', true);

Verbindung zur wordpress.com API

Den API-Key eines Accounts bei wordpress.com kann man auch in der wp-config.php hinterlegen. Der einzige, mir bekannte, Fall wo das gebraucht wird, liegt in der Verwendung der Jetpack-Pluginsammlung:

define('WPCOM_API_KEY', 'API-Key-Eingeben');

Fazit

Wie ihr seht, bietet einem die wp-config.php Datei vielseitige Einstellungsmöglichkeiten für das WordPress System, die über den Grundzustand weit hinausgehen. Manche Anweisungen wird man häufiger einsetzen, manche eher selten und einige gar nicht. Der Vorteil bei dieser Methode zu Fuß liegt in der Einsparung von Plugins (die auch nur dieselben Befehle injizieren würden) und im Lerneffekt beim Benutzer. Und dabei habe ich hier auch nur die WordPress-eigenen Befehle vorgestellt.