Eine der wichtigsten Dateien einer WordPress-Installation ist die Konfigurationsdatei. Sie befindet sich im Stammverzeichnis und enthält Konstantendefinitionen und PHP-Anweisungen, die dafür sorgen, dass WordPress so funktioniert, wie man es sich wünscht.

Die Datei wp-config.php speichert Daten wie Datenbankverbindungsdetails, Tabellenpräfix, Pfade zu bestimmten Verzeichnissen und eine Menge Einstellungen, die sich auf bestimmte Funktionen beziehen, auf die wir in diesem Beitrag eingehen werden.

Grundlegende wp-config.php-Datei

Wenn man WordPress zum ersten Mal installiert, wird man aufgefordert, erforderliche Informationen wie Datenbankdetails und Tabellenpräfix einzugeben. Manchmal richtet der Host WordPress für dich ein, ohne dass du die Einrichtung manuell durchführen musst. Wenn du aber die 5-minütige Installation manuell durchführst, wirst du gebeten, einige der wichtigsten Daten, die in wp-config gespeichert sind, einzugeben.

Wenn du die Einrichtung durchführst, musst du Daten eingeben, die in der Datei wp-config.php gespeichert sind
Wenn du die Einrichtung durchführst, musst du Daten eingeben, die in der Datei wp-config.php gespeichert sind

Hier ist eine grundlegende wp-config.php-Datei:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

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

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Normalerweise wird diese Datei automatisch generiert, wenn das Setup ausgeführt wird, aber gelegentlich verfügt WordPress nicht über Schreibrechte im Installationsordner. In dieser Situation sollte eine leere Datei wp-config.php erstellen, den Inhalt aus wp-config-sample.php kopieren und einfügen und die richtigen Werte für alle definierten Konstanten einstellen. Wenn du fertig bist, lade deine Datei in den Stammordner hoch und starte WordPress.

Hinweis: Konstantendefinitionen und PHP-Anweisungen kommen in einer bestimmten Reihenfolge, die man niemals ändern sollte. Und wir sollten niemals Inhalte unter der folgenden Kommentarzeile hinzufügen:

/* That's all, stop editing! Happy blogging. */

Zuerst kommen die Definitionen der Datenbankkonstanten, die man von seinem Host erhalten haben sollte:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • DB_CHARSET
  • DB_COLLATE

Nach Angaben zur Datenbank werden acht Sicherheitsschlüssel die Webseite gegen Hacker sichern. Wenn man die Installation ausführt, generiert WordPress automatisch Sicherheits- und Salt-Schlüssel, aber man kann sie jederzeit ändern und jede beliebige Zeichenfolge hinzufügen. Für eine bessere Sicherheit sollte man es in Betracht ziehen, den Online-Generator zu verwenden.

Die Variable $table_prefix speichert das Präfix aller WordPress-Tabellen. Leider kennt jeder seinen Standardwert, und dies könnte die WordPress-Datenbank für eine Schwachstelle öffnen, die leicht behoben werden kann, indem bei der Ausführung des Setups ein benutzerdefinierter Wert für $table_prefix festgelegt wird.

Um das Tabellen-Präfix in einer funktionierenden Webseite zu ändern, solltest du mehrere Abfragen gegen die Datenbank durchführen und dann die Datei wp-config.php manuell bearbeiten. Wenn du keinen Zugriff auf die Datenbank hast oder du nicht über die erforderlichen Kenntnisse verfügst, um benutzerdefinierte Abfragen zu erstellen, kannst du ein Plugin wie Change Table Prefix installieren, das Datenbanktabellen und Feldnamen umbenannt und die Konfigurationsdatei ohne Risiko aktualisiert.

Hinweis: Es ist eine gute Praxis, WordPress-Dateien und Datenbank zu sichern, auch wenn man das Tabellenpräfix mit einem Plugin ändert.

Bisher beschränkte sich die Analyse auf die Grundkonfiguration. Aber uns stehen viele Konstanten zur Verfügung, die wir definieren können, um Funktionen zu aktivieren, die Installation anzupassen und zu sichern.

Grundkonfiguration: Das Dateisystem bearbeiten

Das WordPress-Dateisystem ist bei Benutzern und Hackern gut bekannt. Aus diesem Grund sollte man erwägen, die eingebaute Dateistruktur zu ändern, indem man bestimmte Ordner an beliebige Orte verschiebt und die entsprechenden URLs und Pfade in der wp-config-Datei festlegt.

Zunächst kannst du den Inhaltsordner verschieben, indem du zwei Konstanten definierst. Die erste Konstante legt den vollständigen Verzeichnispfad fest:

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

Die zweite legt die neue Verzeichnis-URL fest:

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

Man kann nur den Plugin-Ordner verschieben, indem man die folgenden Konstanten definiert:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

Auf die gleiche Weise kannst du den Upload-Ordner verschieben, indem du den neuen Verzeichnispfad festlegst:

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

Hinweis: Alle Pfade sind relativ zu ABSPATH, und sie sollten keinen führenden Schrägstrich enthalten.

Wenn dies erledigt ist, ordne die Ordner an und lade WordPress neu.

Das Bild zeigt die eingebaute Dateistruktur im Vergleich zu einer angepassten Struktur
Das Bild zeigt die eingebaute Dateistruktur im Vergleich zu einer angepassten Struktur

Es ist nicht möglich, den Ordner /wp-content/themes aus der wp-config-Datei zu verschieben, aber man kann ein neues Themeverzeichnis in einem Plugin oder einer Datei mit den Funktionen eines Themes registrieren.

Funktionen für Entwickler: Debug-Modus und Speichern von Abfragen

Wenn du ein Entwickler bist, kannst du WordPress zwingen, Fehler und Warnungen anzuzeigen, die dir beim Theme- und Plugin-Debugging helfen. Um den Debug-Modus zu aktivieren, musst du nur den WP_DEBUG-Wert auf true setzen, wie unten gezeigt:

define( 'WP_DEBUG', true );

WP_DEBUG ist standardmäßig auf false gesetzt. Wenn du den Debug-Modus deaktivieren musst, kannst du einfach die Definition entfernen oder den Wert der Konstante auf false setzen.

Wenn du an einer aktiven Seite arbeitest, solltest du den Debug-Modus deaktivieren. Fehler und Warnungen sollten den Betrachtern der Seite niemals angezeigt werden, da dies für Hacker wertvolle Informationen liefern kann. Was aber, wenn man trotzdem debuggen muss?

In solchen Situationen kannst du WordPress dazu zwingen, sich Fehler und Warnungen in der Datei debug.log im Ordner /wp-content zu merken. Um diese Funktion zu aktivieren, kopiere den folgenden Code und füge ihn in die wp-config.php-Datei ein:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Damit diese Funktion funktioniert, muss zunächst der Debug-Modus aktiviert werden. Wenn man dann WP_DEBUG_LOG auf true setzt, zwingt man WordPress, Nachrichten in der Datei debug.log zu speichern, während man WP_DEBUG_DISPLAY auf false setzt, um sie vor dem Bildschirm zu verbergen. Schließlich setzt du den Wert der PHP-Variablen display_errors auf 0, so dass Fehlermeldungen nicht auf den Bildschirm ausgegeben werden. wp-config wird niemals aus dem Cache geladen. Aus diesem Grund ist es ein guter Ort, um die php.ini-Einstellungen zu überschreiben.

Hinweis: Dies ist eine großartige Funktion, die du nutzen kannst, um Nachrichten zu registrieren, die WordPress auf dem Bildschirm nicht ausdrucken würde. Wenn z.B. die Aktion publish_post ausgelöst wird, lädt WordPress ein Skript, das Daten speichert, und leitet den Benutzer dann auf die Nachbearbeitungsseite um. In dieser Situation kann man Nachrichten registrieren, aber nicht auf dem Bildschirm ausdrucken.

Eine weitere Debugging-Konstante bestimmt die zu ladenden Versionen von Skripten und Stilen. Setze SCRIPT_DEBUG auf true, wenn du unkomprimierte Versionen laden möchtest:

define( 'SCRIPT_DEBUG', true );

Wenn dein Theme oder Plugin Daten anzeigt, die aus der Datenbank abgerufen wurden, solltest du die Anfragedetails für eine spätere Überprüfung speichern. Die Konstante SAVEQUERIES zwingt WordPress, Abfrageinformationen in $wpdb->queries-Array zu speichern. Diese Details würden ausgedruckt werden, indem der folgende Code zur Fußzeilenvorlage hinzugefügt wird:

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '<pre>';
        print_r( $wpdb->queries );
        echo '</pre>';
}

Eine genauere Analyse dieser Funktion findest du unter Wie man effiziente Abfragen in WordPress erstellt.

Inhaltsbezogene Einstellungen

Wenn die Webseite wächst, möchtest du vielleicht die Anzahl der Nachbearbeitungen reduzieren. Standardmäßig speichert WordPress Überarbeitungen automatisch alle 60 Sekunden. Wir können diesen Wert ändern, indem wir ein benutzerdefiniertes Intervall in wp-config wie folgt festlegen:

define( 'AUTOSAVE_INTERVAL', 160 );

Natürlich kannst du auch das Intervall für die automatische Speicherung verringern. Jedes Mal, wenn wir unsere Änderungen speichern, fügt WordPress eine Zeile zur Tabelle der Beiträge hinzu, so dass wir frühere Überarbeitungen von Beiträgen und Seiten wiederherstellen können. Dies ist eine nützliche Funktion, die zu einem Problem werden könnte, wenn unsere Webseite groß wird. Glücklicherweise können wir die maximale Anzahl der zu speichernden Beitragsüberarbeitungen verringern oder die Funktionalität überhaupt deaktivieren.

Wenn du Post-Revisionen deaktivieren möchtest, definiere die folgende Konstante:

define( 'WP_POST_REVISIONS', false );

Wenn du die maximale Anzahl der Revisionen begrenzen möchtest, füge stattdessen die folgende Zeile hinzu:

define( 'WP_POST_REVISIONS', 10 );

Standardmäßig speichert WordPress verworfene Beiträge, Seiten, Anhänge und Kommentare 30 Tage lang und löscht sie dann endgültig. Wir können diesen Wert mit der folgenden Konstante ändern:

define( 'EMPTY_TRASH_DAYS', 10 );

Wir können sogar den Papierkorb deaktivieren, indem wir seinen Wert auf 0 setzen, aber bedenke, dass WordPress es dir nicht mehr erlaubt, Inhalte wiederherzustellen.

Erlaubte Speichergröße

Gelegentlich könnte es sein, dass eine Meldung wie die folgende erscheint:

Schwerwiegender Fehler: Erlaubte Speichergröße von xxx Bytes erschöpft …

Die maximale Speichergröße hängt von der Serverkonfiguration ab. Falls kein Zugriff auf die Datei php.ini möglich war, kann man das Speicherlimit nur für WordPress erhöhen, indem man die Konstante WP_MEMORY_LIMIT in der Datei wp-config setzt. Standardmäßig versucht WordPress, PHP 40 MB für einzelne Seiten und 64 MB für Installationen mit mehreren Seiten zuzuweisen. Wenn der von PHP zugewiesene Speicher größer als 40 MB (oder 64 MB) ist, übernimmt WordPress natürlich den maximalen Wert.

Abgesehen davon kann man mit der folgenden Zeile einen benutzerdefinierten Wert festlegen:

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

Falls erforderlich, kann mit der folgenden Anweisung auch eine maximale Speichergrenze festgelegt werden:

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

Automatische Updates

Ab Version 3.7 unterstützt WordPress automatische Updates für Sicherheitsversionen. Dies ist eine wichtige Funktion, die es Seitenadministratoren ermöglicht, ihre Website ständig sicher zu halten.

Man kann alle automatischen Aktualisierungen deaktivieren, indem man die folgende Konstante definiert:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Vielleicht ist es keine gute Idee, Sicherheitsupdates zu deaktivieren, aber es ist deine Entscheidung.

Standardmäßig funktionieren automatische Updates nicht mit Hauptversionen, aber man kann alle Kern-Updates aktivieren, indem man WP_AUTO_UPDATE_CORE wie folgt definiert:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

Der Standardwert ist minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Eine zusätzliche Konstante deaktiviert Auto-Updates (und jede Aktualisierung oder Änderung an einer Datei). Wenn du DISALLOW_FILE_MODS auf true setzt, werden alle Datei-Bearbeitungen deaktiviert, auch Theme- und Plugin-Installationen und -Updates. Aus diesem Grund wird seine Verwendung nicht empfohlen.

Sicherheitseinstellungen

Wir können die wp-config-Datei verwenden, um die Sicherheit der Webseite zu erhöhen. Zusätzlich zu den Änderungen an der Dateistruktur, die wir oben betrachtet haben, können wir einige Funktionen sperren, die unnötige Schwachstellen öffnen könnten. Zunächst einmal können wir den Datei-Editor deaktivieren, der im Verwaltungsbereich zur Verfügung steht. Die folgende Konstante blendet den Bildschirm des Erscheinungsbild-Editors aus:

define( 'DISALLOW_FILE_EDIT', true );

Hinweis: Bedenke, dass einige Plugins nicht richtig funktionieren könnten, wenn diese Konstante als ture definiert wird.

disallow_file_edit
disallow_file_edit

Ein Sicherheitsmerkmal ist die Administration über SSL. Wenn man ein SSL-Zertifikat erworben hat und es richtig konfiguriert ist, kann man WordPress zwingen, bei jeder Anmeldung und Administrationssitzung Daten über SSL zu übertragen. Verwende die folgende Konstante:

define( 'FORCE_SSL_ADMIN', true );

Schaue im Codex nach, wenn du mehr Informationen über die Administration über SSL benötigst.

Die beiden anderen Konstanten erlauben es, externe Anfragen zu blockieren und zugelassene Hosts aufzulisten.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

In diesem Beispiel haben wir zuerst alle Zugriffe von externen Hosts deaktiviert und dann die erlaubten Hosts, getrennt durch Kommas (Platzhalter sind erlaubt), aufgelistet.

Andere erweiterte Einstellungen

WP_CACHE auf true gesetzt schließt das Skript wp-content/advanced-cache.php ein. Diese Konstante hat nur Wirkung, wenn man ein persistentes Caching-Plugin installiert.

CUSTOM_USER_TABLE und CUSTOM_USER_META_TABLE werden verwendet, um andere benutzerdefinierte Benutzertabellen als die Standardtabellen wp_users und wp_usermeta zu setzen. Diese Konstanten ermöglichen eine nützliche Funktion, die es Webseiten-Betreibern ermöglicht, mit nur einem Konto auf mehrere Webseiten zuzugreifen. Damit diese Funktion funktioniert, sollten alle Installationen die gleiche Datenbank verwenden.

Ab Version 2.9 unterstützt WordPress die automatische Datenbankoptimierung. Dank dieser Funktion, die WP_ALLOW_REPAIR auf true setzt, repariert WordPress eine beschädigte Datenbank automatisch.

WordPress erstellt jedes Mal, wenn man ein Bild bearbeitet, einen neuen Satz von Bildern. Wenn du das Originalbild wiederherstellen würdest, bleiben alle erzeugten Sätze auf dem Server. Man kann dieses Verhalten überschreiben, indem man IMAGE_EDIT_OVERWRITE auf true setzt, so dass, wenn du das Originalbild wiederherstellst, alle Bearbeitungen vom Server gelöscht werden.

Lockdown wp-config.php

Jetzt wissen wir, warum wp-config.php eine der wichtigsten WordPress-Dateien ist. Warum verstecken wir sie also nicht vor Hackern? Zunächst einmal können wir wp-config eine Ebene über den WordPress-Stammordner verschieben (nur eine Ebene). Diese Technik ist jedoch etwas umstritten, so dass ich andere Lösungen zum Schutz der Datei vorschlagen würde. Wenn deine Webseite auf Apache Web Server läuft, kannst du die folgenden Direktiven zur .htaccess-Datei hinzufügen:


order allow,deny
deny from all

Wenn die Webseite auf Nginx läuft, kann man die folgende Direktive zur Konfigurationsdatei hinzufügen:

location ~* wp-config.php { deny all; }

Hinweis: Diese Anweisungen sollten erst hinzugefügt werden, wenn die Einrichtung abgeschlossen ist.

Wenn deine Webseite mehrere Migrationen durchlaufen hat oder du sie von jemand anderem gekauft hast, empfiehlt es sich, einen neuen Satz WordPress-Sicherheitsschlüssel zu erstellen. Diese Schlüssel sind ein Satz von Zufallsvariablen, die die Verschlüsselung der in den Cookies des Benutzers gespeicherten Informationen verbessern. Seit WordPress 2.7 gibt es 4 verschiedene Schlüssel: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY und NONCE_KEY.

Standardmäßig werden sie nach dem Zufallsprinzip für dich generiert. Aber WordPress hat tatsächlich ein kostenloses Tool, mit dem man neue Zufallsschlüssel generieren kann. Du kannst dann einfach deine aktuellen Schlüssel aktualisieren, die in deiner wp-config.php-Datei gespeichert sind.

WordPress-Sicherheitsschlüssel
WordPress-Sicherheitsschlüssel

Lese mehr über WordPress-Sicherheits-Keys.Und schließlich solltest du noch einmal überprüfen und sicherstellen, dass deine Berechtigungen in deiner wp-config.php-Datei gesichert sind. Typischerweise werden Dateien im Stammverzeichnis einer WordPress-Seite auf 644 gesetzt, was bedeutet, dass Dateien für den Eigentümer der Datei lesbar und schreibbar sind und für Benutzer in der Gruppe Eigentümer dieser Datei lesbar und für alle anderen lesbar sind. Gemäß der WordPress-Dokumentation sollten die Berechtigungen für die Datei wp-config.php auf 440 oder 400 gesetzt werden, um zu verhindern, dass andere Benutzer auf dem Server sie lesen können. Du kannst dies leicht mit deinem FTP-Client ändern.

wp-config.php-Berechtigungen
wp-config.php-Berechtigungen

Zusammenfassung

In diesem Beitrag habe ich eine Menge WordPress-Konstanten aufgelistet, die wir in einer wp-config-Datei definieren können. Einige dieser Konstanten sind allgemein gebräuchlich, und ihre Funktionen sind leicht zu verstehen. Andere Konstanten ermöglichen fortgeschrittene Funktionen, die ein tiefes Wissen über WordPress und die Verwaltung der Webseite erfordern.

Ich habe die gebräuchlichsten Funktionen aufgelistet, abgesehen von einigen fortgeschrittenen Funktionen, die wir vielleicht in zukünftigen Beiträgen diskutieren werden. Wenn du Funktionen und Konstanten erforschen möchtest, die hier nicht aufgeführt sind, kannst du in den Kommentaren unten ein Gespräch beginnen, und wir tauchen dann tief ein.

Carlo Daniele Kinsta

Carlo ist ein leidenschaftlicher Liebhaber von Webdesign und Frontend-Entwicklung. Er beschäftigt sich seit über 10 Jahren mit WordPress, auch in Zusammenarbeit mit italienischen und europäischen Universitäten und Bildungseinrichtungen. Er hat Dutzende von Artikeln und Leitfäden über WordPress geschrieben, die sowohl auf italienischen und internationalen Websites als auch in gedruckten Magazinen veröffentlicht wurden. Du kannst Carlo auf X und LinkedIn finden.