Die Anbindung der Datenbank
Im folgenden Screenshot sehen wir die einzelnen Konstanten, die wir setzen müssen, damit WordPress mit der Datenbank kommunizieren kann.
In den meisten Fällen geschieht das automatisch durch die 1-Klick-Lösungen eures Hosters.
In vielen Fällen sind nur die ersten 4 Konstanten zu ändern.
Hier geben wir an, wie die Datenbank heißt, welche Nutzer/Passwort Kombination wir zur Authentifizierung benötigen und auf welchem Server die Datenbank liegt.
Diese Daten findet ihr im Dashboard eures Hosters.
Das „DB_CHARSET“ gibt an, mit welcher Zeichenkodierung die Daten in der Datenbank gespeichert werden. In den meisten Fällen sollte dieser Wert nicht geändert werden! Der Wert utf8 ist immer eine gute Option, weil wir damit so gut wie jede Sprache abbilden können.
Sollte dieser Wert in einer existierenden WordPress-Installation fehlen, setzt ihn sicherheitshalber nicht nachträglich! Es kann sein, dass die Datenbank mit einer anderen Zeichenkodierung erstellt wurde. Wenn dem so ist, führt eine falsche Angabe des „DB_CHARSET„s unweigerlich zu Fehlern.
Kontrolliert am Besten die Werte in eurem phpMyAdmin-Panel. Dort wird euch die verwendete Zeichenkodierung angezeigt. Beim unteren Screenshot handelt es sich um die Standardwerte von WordPress mit utf8 für „DB_CHARSET“ und general_ci für „DB_COLLATE“ (was automatisch erstellt wird, wenn wir den Wert in der wp-config leer lassen.)
Die Sicherheitsschlüssel
Sicherheit ist ein wichtiger Bestandteil einer jeden Website.
WordPress verwendet diese Schlüssel, um z.B. Passwörter noch sicherer zu machen. Jede WordPress-Installation sollte hier unterschiedliche Werte aufweisen. Diese Daten sollten nicht weitergegeben werden!
Im Zuge der Installation von WordPress werden diese Schlüssel automatisch erstellt. Sollten diese Schlüssel fehlen, verwendet einfach den Online-Generator unter https://api.wordpress.org/secret-key/1.1/salt/ um welche zu erzeugen.
Der Table-Prefix
Jede Tabelle in einer Datenbank muss eindeutig sein.
Daher wird jede Datenbank-Tabelle mit einem Prefix versehen. Der Standardwert hierfür ist schlicht „wp_“. Dadurch können sich mehrere WordPress-Installationen die selbe Datenbank teilen, ohne sich in die Quere zu kommen. Es muss nur jede WordPress-Installation einen einzigartigen Table-Prefix besitzen.
Wenn ihr eine bestehende WordPress-Datenbank migriert, achtet auch darauf, dass der Table-Prefix korrekt ist. Die meisten Hoster geben euch Zugang zur Datenbank über phpMyAdmin. Dort seht ihr dann eure Datenbank mit den Tabellen und dem Tabellen-Prefix.
Die Debugging Einstellungen
Frühzeitiges Erkennen von Fehlern oder Problemen ist für jedes Projekt essentiell.
Und auch hier hilft uns WordPress dabei, indem es uns unterschiedliche Möglichkeiten der Anzeige solcher Fehler bietet. Obwohl es Plugins gibt, die uns darüber hinaus noch mit nützlichen Informationen gibt, sollten wir auch in der wp-config.php gewisse Einstellungen anpassen.
Beim Entwickeln eines neuen Themes oder Plugins sollten wir den Wert für „WP_DEBUG“ unbedingt auf true setzen. Dadurch erhalten wir auch die Optionen „WP_DEBUG_DISPLAY“ und „WP_DEBUG_LOG„, die wir ebenfalls auf true zu setzen sollten. Diese 3 Konstanten sorgen dafür, dass wir Fehler im Programmcode nicht nur direkt auf der Website sehen, sondern uns auch in einer Datei im wp-content Ordner mitgeschrieben werden. Diese Datei heißt standardmäßig debug.log. In dieser Datei werden zeilenweise alle Fehler oder Warnungen gespeichert.
Zusammen mit „WP_DISABLE_FATAL_ERROR_HANDLER“ ist diese Kombination auch mit installiertem „Query Monitor„-Plugin unerlässlich für die Entwicklung.
Für diesen Zweck sollte auch PHP so konfiguriert sein, dass es Fehler und Warnungen nicht unterdrückt. Wenn ihr keinen Zugang zu den PHP-Einstellungen selbst habt, könnt ihr diese auch über die wp-config.php setzen. Setzt einfach vor „WP_DEBUG“ ein `@ini_set( ‚display_errors‘, ‚On‘ );` und `@ini_set( ‚log_errors‘, ‚On‘ );`
Achtet darauf, dass im Live-Betrieb wieder alle Debugging-Einstellungen deaktiviert werden!