Aufbau und Tabellenstruktur der WordPress Datenbank
Jede WordPress Website nutzt eine MySQL Datenbank im Hintergrund. Für ein besseres Verständnis der grundlegenden Funktionsweise von WordPress lohnt sich deshalb ein Blick auf den Aufbau der WordPress Datenbank und die Struktur der WordPress Tabellen.
Wofür braucht WordPress eine Datenbank?
Jede Form von Content wie zum Beispiel Beiträge, statische Seiten, Kategorien, Schlagwörter oder Kommentare werden in der WordPress Datenbank gespeichert. Ebenso natürlich die Nutzerkonten, WordPress Einstellungen sowie Theme und Plugin Optionen. Auch für hochgeladene Medien erfolgen Einträge in den WordPress Datenbank Tabellen.
Als Endanwender kommt man selten mit der Datenbank in Kontakt. Beim Thema Backup und Umzug einer Website müssen die WordPress Tabellen zwar gesichert oder migriert werden, es existieren aber eine Vielzahl an Plugins zur einfachen Handhabung dieser Fälle.
Die Datenbank wird vom Webhoster auf dem Server bereitgestellt. WordPress unterstützt dabei MySQL oder MariaDB als Datenbanksystem. Bei der Installation von WordPress müssen die Zugangsdaten zur Datenbank des Servers angegeben werden. Mit der WordPress Installation werden dann alle benötigten Tabellen in der Datenbank erstellt.
Die Tabellen der WordPress Datenbank im Überblick
Die WordPress Datenbank besteht aus mehreren Tabellen. Jede Tabelle definiert verschiedene Felder zur Speicherung von Daten.
Die Tabelle für Kommentare hat beispielsweise die Felder comment_ID, comment_author und comment_date. Die Felder kann man sich auch als Spalten vorstellen. Jeder neue Kommentar wird in der Tabelle als neue Zeile gespeichert.
Sehen wir uns nun alle WordPress Tabellen genauer an.
WordPress Datenbank Diagramm
Das Diagramm zeigt die initialen Tabellen von WordPress. Unter Umständen findest du weitere Tabellen in deiner Datenbank, die von Plugins angelegt wurden. Standardmäßig verwendet WordPress das Präfix wp_, es sei denn es wurde ein anderes Präfix bei der Installation definiert.
wp_posts
Die Tabelle wp_posts ist das Zentrum der WordPress Datenbank.
Hier werden alle Beiträge und statische Seiten gespeichert. Die Tabelle beinhaltet deshalb die meisten Felder, unter anderem für den Titel, Autor, Erstellungsdatum und Content des Posts. Sehr wichtig ist auch das Feld post_type zur Unterscheidung der Content Arten.
Die Tabelle wird auch für weniger ersichtlichen Content genutzt. So werden Informationen über jede hochgeladene Datei in der Mediathek als Attachment in wp_posts abgelegt. WordPress Menüs nutzen die Tabelle ebenfalls zur Speicherung der Navigationslinks.
Darüber hinaus lassen sich in der Tabelle auch die zwischengespeicherten Revisionen eines Posts sowie die Customizer Changesets finden. Changesets sind das neue Feature in WordPress 4.9, mit dem sich Customizer Optionen planen und später veröffentlichen lassen.
Neben den Standard Post Types wird auch jeder Custom Post Type in wp_posts deponiert.
wp_postmeta
Zusätzliche Informationen für einzelne Posts können in wp_postmeta gespeichert werden. Dort werden zum Beispiel die benutzerdefinierten Felder gespeichert, d.h. so ziemlich jedes Plugin mit eigenen Metaboxen nutzt diese Tabelle im Hintergrund.
WordPress hat mehrere Tabellen für Metadaten, welche ich im Folgenden noch vorstellen werde. Diese sind alle nach dem gleichen Prinzip aufgebaut – eine einzigartige Meta ID, zwei Felder für Meta Key & Value und eine Verknüpfung mit der Tabelle, die ergänzt wird (In diesem Fall wp_posts).
Die Zuweisung eines Page Templates wird beispielsweise als Postmeta gespeichert:
meta_id | post_id | meta_key | meta_value |
---|---|---|---|
13 | 7 | _wp_page_template | template-fullwidth.php |
Mit dieser Struktur können somit beliebig viele Metadaten für Posts angelegt werden.
wp_terms und wp_termmeta
In wp_terms werden die Basisinformationen für alle Kategorien und Schlagwörter abgelegt. Auch durch Plugins hinzugefügte Custom Taxonomies finden hier ihren Platz.
Fügt ihr z.B. ein neue Kategorie hinzu, wird dafür ID, Name und URL gesichert:
term_id | name | slug |
---|---|---|
27 | WordPress Tutorials | wordpress-tutorials |
wp_termmeta funktioniert genau gleich wie wp_postmeta und erlaubt die Speicherung von zusätzlichen Metadaten für die Terms.
wp_term_taxonomy
wp_term_taxonomy speichert weitere Informationen über den Term und dessen Taxonomie (Kategorie, Schlagwort oder Custom). Die Tabelle legt damit erst fest, ob es sich bei einem Term um eine Kategorie oder Schlagwort handelt.
Das Feld term_id verweist dabei auf die Tabelle wp_terms. Zusätzlich wird mit description die Beschreibung des Terms, mit parent die Hierarchie von Terms und mit count die Anzahl der verknüpften Posts festgehalten.
term_taxonomy_id | term_id | taxonomy | description | parent | count |
---|---|---|---|---|---|
34 | 27 | category | Beschreibung der Kategorie | 0 | 2 |
35 | 48 | post_tag | Beschreibung des Schlagworts | 0 | 4 |
wp_term_relationships
Diese Tabelle dient zur Verknüpfung von Posts (Beitrag, Seite) mit den Taxonomien (Kategorie, Schlagwörter). object_id ist die ID des Posts, während term_taxonomy_id auf den Eintrag in wp_term_taxonomy verweist.
object_id | term_taxonomy_id | term_order |
---|---|---|
8 | 34 | 0 |
wp_comments und wp_commentmeta
Hier werden alle Kommentare aufbewahrt, daher recht selbsterklärend. Falls ein eingeloggter Nutzer kommentiert, wird der Kommentar mit der User ID verknüpft. Die Tabelle wp_commentmeta ist nach dem gleichen Schema wie wp_postmeta aufgebaut.
wp_users und wp_usermeta
Wie der Name schon verrät, beinhaltet diese Tabelle alle Nutzer der WordPress Installation. Daher werden Username, E-Mail und Passwort hier gespeichert.
wp_usermeta funktioniert auch hier analog wie die anderen Tabellen für Metadaten. Viele Daten wie Vor- und Nachname, aber auch Berechtigungen des Nutzers, sind hier ausgelagert.
wp_options
In wp_options werden alle Einstellungen festgehalten, die im WordPress Backend konfiguriert werden können, inklusive der Optionen im Customizer und des Transients Caches. Auch Themes und Plugins nutzen die Tabelle, wenn sie Einstellungen mit der Settings API oder Theme_Mods API hinzufügen.
Nice to know: Im Gegensatz zu WordPress Menüs und anderem Content werden Widgets ebenfalls in wp_options gespeichert.
wp_links
Die Tabelle wp_links stammt aus der Zeit, als WordPress noch eine reine Blog Software war. Dort werden die Links der damals sehr beliebten Blogroll gespeichert. Das Links-Feature wurde inzwischen komplett aus dem WordPress Core entfernt, kann aber mit dem Plugin Link Manager wieder hinzugefügt werden.
Fazit
Auch wenn dieser Beitrag keine konkreten Tipps enthält, ist es manchmal recht nützlich, den grundlegenden Aufbau und Tabellenstruktur der WordPress Datenbank im Hinterkopf zu haben. Ich hoffe, dieser Artikel hat zu einem besseren Verständnis beigetragen.
Das war/ist in der Tat ein sehr hilfreicher und interessanter Artikel. Hatte mich schon oft gefragt, wie es „unter der Haube“ von WordPress auf der Datenbankebene aussieht. Ich musste mal auf die Suche nach alten und zum Teil versteckten Datenbankeinträgen gehen, die mir irgendein Plugin verpasst hatte. Es ging um diverse benutzerdefinierte Felder, die ich schlicht nicht mehr brauchte und loswerden wollte. So richtig geklappt hatte es wohl nicht, da mir diese weiterhin in der Auswahlliste angezeigt werden. Obwohl ich mich inzwischen dran gewöhnt habe, würde ich sie trotzdem gerne loswerden. Irgendeine Idee?
Hallo Jens,
Vielen Dank, freut mich 🙂
Die benutzerdefinierten Felder speichert WordPress in wp_postmeta. Solang es aber nur um wenige Felder geht, lassen sich diese auch manuell im WordPress Backend wieder löschen.
Bei vielen Einträgen kann man diese auch direkt in der Datenbank entfernen, beispielsweise mit phpMyAdmin. Siehe dieses Video Tutorial: https://www.youtube.com/watch?v=pXe_tXNemWs
Alternativ kann auch ein Plugin verwendet werden. Nach den Reviews nach funktioniert es trotz des Alters noch immer: https://wordpress.org/plugins/delete-custom-fields/
Bei beiden Methoden bitte vorher ein Backup der Datenbank vornehmen 😉
Viele Grüße,
Thomas
Vielen Dank für Deine Tipps! Werde ich mir heute direkt mal anschauen 😉
Hallo Thomas,
vielen Dank fuer die Bereitstellung der Infos und die Beschreibung der Tabellen. Ich beschäftige mich viel mit Datenbanken, daher ist das für mich sehr interessant.
Ein Foreign Key fehlt m.E. zumindest in der grafischen Übersicht: Die Tabelle wp_comments besitzt eine Spalte comment_post_ID. Ich vermute, diese bezieht sich auf die Spalte ID der Tabelle wp_comments, denn eine Kommentar stammt immer von einem User (dort gibt es einen FK ) , und gehört aber auch zu einem Post/einer Seite.
comment_post_ID sollte zumindest mit einem Index versehen werden – das macht das System bei sehr vielen Posts und Usern schneller. Der FK empfiehlt sich, damit z.B. beim Löschen von Posts/Seiten keine „Kommentarleichen“ übrigbleiben.
Mit freundlichen Grüssen
Michael
Hallo Michael,
Vielen Dank für deine Ergänzungen, sehr gut beobachtet.
comment_post_ID weist in der Tat auf die ID von wp_posts und verknüpft die Kommentare mit den Posts. Das Feld ist auch mit einem Index versehen.
Die Fields aller Tabellen sind auf WordPress.org detailliert beschrieben, unter anderem auch für wp_comments: https://codex.wordpress.org/Database_Description#Table:_wp_comments
Die grafische Übersicht von WordPress.org ist dementsprechend nicht ganz richtig bzw. zeigt nicht alle Verknüpfungen in der Datenbank.
Zum Thema Foreign Keys ist vllt dieses Zitat von WordPress.org interessant für dich:
Wenn Beiträge im WordPress Backend gelöscht werden, kümmert sich natürlich WordPress um die Löschung der Kommentare. Es findet aber keine Kontrolle im Datenbanksystem statt, d.h. durch nicht sauber programmierte Plugins können durchaus Datenbankleichen in WordPress enstehen.
Viele Grüße,
Thomas