Dos and Don’ts: WordPress anpassen mit der wp-config.php

In der wp-config.php kann man die Grundeinstellungen von WordPress beeinflussen

Die wp-config.php-Datei ist eine Art Schaltzentrale des WordPress-Systems. Hier kann man Einstellungen für die eigenen Bedürfnisse anpassen oder auch neue Funktionalitäten mit einem Codesnippet hinzufügen.

Doch Vorsicht: Nimmt man falsche Einstellungen vor oder entfernt aus Versehen etwas, kann im schlimmsten Fall das ganze System zerschossen werden. Daher empfiehlt es sich immer, Tests in einer lokalen Installation durchzuführen oder zumindest ein Backup anzulegen, bevor man das Ganze in die „richtige“ Website einfügt.

Je besser man die Datei kennt, desto geringer ist die Wahrscheinlichkeit, dass man aus Versehen etwas kaputt macht. Daher folgt zunächst eine kurze Beschreibung der wp-config.php, und welche Daten man besser nicht ändert. Danach gehe ich auf die aus meiner Sicht wichtigsten zusätzlichen Konstanten ein.

Was macht die wp-config.php?

Die wp-config.php wird beim Installationsprozess von WordPress automatisch erstellt. Die während der Installation eingegebenen Daten kommen dort hinein. Nach der erfolgreichen Installation findet man die Datei im Wurzelverzeichnis. Folgender Code ist dann standardmäßig darin:

Verbindung zur Datenbank

define('DB_NAME', 'database_name_here');
define('DB_USER', 'username_here');
define('DB_PASSWORD', 'password_here');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

In die ersten drei Zeilen DB_USER, DB_PASSWORD und DB_HOST wurden automatisch die Zugangsdaten zur Datenbank eingetragen, die bei der Installation abgefragt worden sind. Danach folgt der Datenbankzeichensatz und der collate type.

Die Zugangsdaten darf man nur im Falle eines Umzuges der Website ändern, ansonsten kann das WordPress-System nicht auf die Datenbank zugreifen. Das hat zur Folge, das die Website nicht mehr funktioniert.

Sicherheitsschlüssel

Hier darf man nach der Installation Hand anlegen. Im Installationsprozess werden keine Sicherheitsschlüssel angelegt. Doch das Einfügen solcher Schlüssel ist für die Sicherheit der Installation ratsam.

define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');

Bei einem Blick in die wp-config.php wird man in den Kommentaren darauf hingewiesen, die sicherheitsrelevanten Schlüssel zu generieren und einzufügen. Freundlicherweise stellt WordPress hierfür folgenden Generator zur Verfügung: https://api.wordpress.org/secret-key/1.1/salt/

Ruft man diesen Link auf, werden die Schlüssel neu generiert und der fertige Codeblock bereitgestellt. Diesen kopiert man und fügt ihn anstatt dem obigen Code ein.

Das Datenbanktabellen-Präfix

$table_prefix = 'wp_';

Zunächst gibt WordPress standardmäßig das Präfix wp_ vor. Doch schon während der Installation hat man die Möglichkeit, ein eigenes Präfix anzugeben. Das sollte man auch tun, um es Angreifern schwerer zu machen. Am besten wählt man eine beliebige, fünfstellige Kombination aus Buchstaben und Zahlen. Diese Kombination wird dort eingetragen.

Hat man es versäumt, das Präfix während der Installation zu individualisieren, kann man das auch nachträglich noch tun. Wie das geht, erfährt man in folgendem Artikel (Dritter Absatz): WordPress absichern: 11 Tipps gegen Hackerangriffe

Der Debugging Mode für Entwickler

define('WP_DEBUG', false);

Diese Konstante gibt an, ob der Debug-Modus aktiviert ist. Nach der Installation steht dieser auf „false“. Das sollte man auch so lassen, es sei denn, man möchte einen Fehler ausmerzen. Soll WordPress Fehlermeldungen ausgeben, trägt man anstatt „false“ hier „true“ ein und man bekommt nähere Informationen zu vorhandenen Fehlern.

Allerdings darf man nicht vergessen, den Modus wieder auszuschalten, bevor man die Website online stellt. Ein aktivierter Debug-Modus stellt ein Sicherheitsrisiko dar, da so potentielle Angreifer mit Informationen zu Sicherheitslücken versorgt werden.

Ab jetzt Finger weg!

That’s all, stop editing! Happy blogging – Diesen freundlichen Hinweis erhält man in den Kommentaren vor diesen beiden Einstellungen. Denn ändert man hier etwas, funktioniert die Installation nicht mehr. Zuerst steht der absolute Pfad zur Installation, diesen braucht WordPress, sonst geht garnichts mehr. Dann wird die Datei wp-settings.php eingebunden. Daraus holt sich WordPress wichtige Informationen die zum Funktionieren notwendig sind.

if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');

Das System anpassen mit zusätzlichen Einträgen

Anstatt Einträge zu ändern, kann man weitere Konstanten hinzufügen, um die Funktionalität von WordPress zu erweitern. Diese zusätzlichen Einträge fügt man zwischen WP_DEBUG und ABSPATH ein, keinesfalls gleich am Anfang oder am Ende des Dokumentes. Hier folgt eine Auswahl der Konstanten:

Revisionen von Beiträgen bestimmen

WordPress erstellt bei jedem Beitrag automatisch Revisionen. So kann der Nutzer im Bedarfsfall zu früheren Versionen zurückkehren. Möchte man diese Funktion ganz ausschalten oder die Revisionen limitieren, gibt es hierfür folgende Konstanten:

Hiermit werden Revisionen der Beiträge komplett abgeschaltet:

define('WP_POST_REVISIONS', false);

Mit einer eingetragenen Zahl beeinflusst man die Anzahl der Revisionen, die vorgehalten werden sollen. In diesem Falle 5:

define('WP_POST_REVISIONS', 5);

Genauere Fehlerberichte

Schon oben erwähnte ich, wie man den standardmäßig deaktivierten Debug-Modus einschalten kann um sich Fehlermeldungen anzeigen zu lassen. Doch mit weiteren Konstanten kann man noch genauere Angaben über die Ausgabe der Fehler machen.

Fügt man nach dem Code für den aktivierten Debug-Modus WP_DEBUG_LOG ein, wird ein Fehlerbericht erstellt:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Mit folgender Konstante werden die Fehler direkt ausgegeben:

define('WP_DEBUG_DISPLAY', true);

Bei diesen Konstanten ist es wichtig, diese auf „false“ zu setzen oder ganz zu entfernen, bevor die Website produktiv eingesetzt wird, um Hackerangriffe zu erschweren.

Komprimierung von Styles und Skripten aufheben

Hilfreich bei der Fehlersuche kann auch SCRIPT_DEBUG sein. Fügt man diese in die wp-config.php ein, werden die Stylesheets und JavaScript-Dateien in unkomprimierter Form ausgegeben:

define('SCRIPT_DEBUG', true);

Auch diese Konstante sollte man nur zu Testzwecken einsetzen. Durch die fehlende Komprimierung kann die Website u. U. langsam werden.

Automatische Updates beeinflussen

Seit Version 3.7 werden standardmäßig kleinere Wartungs- und Sicherheitsupdates vom WordPress-System automatisch durchgeführt. Lediglich bei großen Versionssprüngen (z. B. Major-Update von 3.7 auf 3.8) muss man das Update selbst ausführen.

Wenn man vorab prüfen möchte, ob die installierten Themes und Plugins mit der neuen WordPress-Version zurechtkommen, kann man automatische Updates ganz oder teilweise unterbinden. Oder im gegenteiligen Fall die Installation so konfigurieren, dass auch Major Updates automatisch durchgeführt werden:

Mit folgendem Code verbietet man sämtliche automatische Updates:

define('WP_AUTO_UPDATE_CORE',false);

Ersetzt man das „false“ durch „minor“, werden nur Minor-Updates automatisch durchgeführt.

define('WP_AUTO_UPDATE_CORE',minor);

Setzt man den Wert auf „true“, werden sämtliche Updates automatisch durchgeführt.

define('WP_AUTO_UPDATE_CORE',true);

Weitere Informationen und Filter zur noch feineren Justierung findet man in folgendem Beitrag von WordPress: Automatische Hintergrund-Aktualisierungen konfigurieren

Automatisches Speichern der Beiträge

Standardmäßig speichert WordPress den Beitrag oder Seite, an dem/der gerade gearbeitet wird alle 60 Sekunden. Mit AUTOSAVE_INTERVAL beeinflusst man diesen Wert. Die Zahl dahinter gibt in Sekunden an, in welchem Zeitraum eine Speicherung erfolgen soll. Hier werden Beiträge und Seiten alle 30 Sekunden gespeichert:

define('AUTOSAVE_INTERVAL', 30);

Papierkorb leeren

Löscht man Beiträge, Seiten, Kommentare und Medien, landen diese im Papierkorb. Standardmäßig leert WordPress diesen nach 30 Tagen. In diesen Zeitraum kann man es sich noch einmal anders überlegen. Ist einem dieser Intervall zu kurz oder zu lang, ändert man ihn mit EMPTY_TRASH_DAYS.

Die nachfolgende Zahl gibt die Zeit in Tagen an, bis der Inhalt des Papierkorbs endgültig gelöscht wird, hier 90 Tage:

define('EMPTY_TRASH_DAYS', 90);

Möchte man den Papierkorb garnicht haben, setzt man die Konstante auf null. In diesem Fall werden sämtliche Daten sofort und unwiederbringlich gelöscht. Es wird vorher nicht noch einmal gefragt, ob man sich sicher ist:

define('EMPTY_TRASH_DAYS', 0);

WordPress- und Website-URL des Blogs festlegen

Generell findet man diese im Backendbereich unter Einstellungen –> Allgemein. Ändert hier jemand versehentlich etwas, funktioniert die Website nicht mehr. Man gelangt auch nicht mehr ins Backend um den Fehler zu korrigieren. Hier muss man sich mit der wp-config.php behelfen oder auf die Datenbank zugreifen.

Doch man kann als Sicherheitsmaßnahme die sog. Site- und Home-URL’s schon vorab in der wp-config.php festlegen. Das hat zur Folge, dass die Optionen im Backendbereich ausgegraut sind. Somit kann ein unbedarfter Benutzer diese nicht mehr aus Versehen ändern. Folgende Konstanten fügt man hierfür ein und trägt die richtige URL ein:

define('WP_SITEURL','http://www.divo-webdesign.de/blog');>
define('WP_HOME','http://www.divo-webdesign.de/blog');

Fazit:

Die wp-config.php ist also mehr als nur die Datei, in der die Zugangsdaten zur Datenbank abgespeichert werden. Man kann zahlreiche Einstellungen treffen, um das System an die eigenen Bedürfnisse anzupassen.

Es empfiehlt sich, die gewünschten Einstellungen in einer lokalen Installation vorab zu testen oder ein Backup des gesamten WordPress-Systems vorzunehmen, bevor man etwas ändert. Denn wenn man an heiklen Stellen aus Versehen etwas ändert, kann das dazu führen, dass die Seite nicht mehr erreichbar ist.

Wer sich weitergehend informieren möchte, kommt hier zum Artikel Editing wp-config.php im WordPress Codex.