Heute werfen wir einen Blick auf das Verzeichnis wp_options in deiner WordPress-Database. Dieser eine Bereich wird auch oft übersehen, wenn es um die gesamte WordPress- und Databaseleistung geht. Vor allem auf älteren und großen Websites kann dies die Ursache für langsame Abfragezeiten auf deiner Website sein, da automatisch geladene Daten von Plugins und Themes von Drittanbietern zurückgelassen werden. In den folgenden Tipps erfährst du, wie du das Verzeichnis wp_options überprüfst, behebst und bereinigst.
Was ist das wp_options-Verzeichnis?
Das wp_options-Verzeichnis enthält alle Arten von Daten für deine WordPress-Seite, wie zum Beispiel:
- Site – URL, Home – URL, Admin – E – Mail, Standardkategorie, Beiträge pro Seite, Zeitformat usw.
- Einstellungen für Plugins, Themes, Widgets
- Vorübergehend zwischengespeicherte Daten
Das Verzeichnis enthält die folgenden Felder, von denen eines mehr Wert auf Leistung legt:
- option_id
- option_name
- option_value
- autoload
Das Wichtigste, was es über das Verzeichnis wp_options zu verstehen gibt, ist das Feld autoload. Dieses enthält einen Ja- oder Nein-Wert (Flag). Dies steuert im Wesentlichen, ob es von der Funktion wp_load_alloptions () geladen wird oder nicht. Automatisch geladene Daten sind Daten, die auf jeder Seite deiner WordPress-Seite geladen werden. Genauso wie wir dir gezeigt haben, wie du vom Laden der Seite aus bestimmte Skripte deaktivieren kannst, gilt hier dieselbe Idee. Das Autoload-Attribut ist für Entwickler standardmäßig auf „Ja“ gesetzt, aber nicht jedes Plugin sollte theoretisch seine Daten auf jeder Seite laden.
Das Problem, das auf dem WordPress-Seiten auftreten kann, ist, wenn sich in dem Verzeichnis wp_options eine große Menge automatisch geladener Daten befindet. Dies ist normalerweise ein Ergebnis vom folgenden:
- Daten werden von einem Plugin automatisch geladen, wenn sie eigentlich auf „Nein“ gesetzt werden sollten. Ein gutes Beispiel dafür wäre ein Kontaktformular-Plugin. Müssen Daten auf jeder Seite oder nur auf der Kontaktseite geladen werden?
- Plugins oder Themes wurden von der WordPress-Seite entfernt, ihre Optionen bleiben jedoch in dem Verzeichnis wp_options zurück. Dies kann bedeuten, dass bei jeder Anforderung unnötige automatisch geladene Daten abgefragt werden.
- Entwickler von Plugins und Themes laden Daten in das Verzeichnis wp_options, anstatt ihre eigenen Verzeichnisse zu verwenden. Für beide Seiten gibt es Argumente, da einige Entwickler Plugins bevorzugen, die keine zusätzlichen Verzeichnisse erstellen. Das Verzeichnis wp_options sollte jedoch nicht Tausende von Zeilen enthalten.
Wie viel sind zu viele automatisch geladene Daten? Das kann natürlich variieren, aber im Idealfall solltest du zwischen 300 KB und 1 MB liegen. Sobald du dich dem Bereich von 3-5 MB oder mehr näherst, können höchstwahrscheinlich Dinge optimiert oder vom automatischen Laden ausgeschlossen werden. Alles, was über 10 MB liegt, sollte sofort angesprochen werden. Dies bedeutet nicht immer, dass dies ein Problem verursachen wird, aber es ist ein guter Anfang.
Fehlerbehebung für automatisch geladene Daten in dem Verzeichnis wp_options
Wenn auf deiner WordPress-Seite Langsamkeit auftritt, kann dies an einer Abfrage oder automatisch geladenen Daten liegen, die von einem alten WordPress-Plugin zurückgelassen wurden. Nachfolgend zeigen wir dir, wie du die automatisch geladene Größe in deiner Database überprüfst, in die Daten einer Live-Seite eintauchen und mitteilen, was wir zur Bereinigung getan haben.
Überprüfe die Größe der automatisch geladenen Daten
Als erstes musst du die aktuelle automatisch geladene Größe auf deiner WordPress-Seite überprüfen. Dazu meldest du dich bei phpMyAdmin an. Klicke links auf deine Database und dann auf die Registerkarte SQL. Gib dann den folgenden Befehl ein und drücke „Go“.
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Möglicherweise musst du die Abfrage oben optimieren, wenn deine WordPress-Seite ein anderes Präfix als wp_ verwendet.
Die autoload_size wird in Bytes zurückgegeben. Es gibt 1024 Byte in einem KB und 1024 KB in einem MB. In unserem Fall entsprechen also 249.025 Bytes 0,25 MB. Also für diese Seite ist dies eine gute Größe! Wenn du weniger als 1 MB zurückbekommst, solltest du dir keine Sorgen machen. Wenn das Ergebnis jedoch viel größer war, fahre mit diesem Tutorial fort.
Im Folgenden haben wir eine Website getestet, in der 137.724.715 Bytes zurückgegeben wurden bzw. 137 MB. Dies ist ein gutes Beispiel für eine Website, auf der etwas definitiv nicht stimmt oder es gibt Dinge, die optimiert werden müssen.
Du kannst auch eine längere Abfrage wie die folgende verwenden. Daraufhin werden die automatisch geladenen Daten, die Anzahl der Einträge in dem Verzeichnis und die ersten 10 Einträge nach Größe angezeigt.
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Wenn du Zugriff auf New Relic (Lizenz erforderlich) hast, kannst du es auch zur Problembehandlung von Abfragen verwenden, die mit dem Verzeichnis wp_options verbunden sind. Die Registerkarte „Database“ zeigt das Verzeichnis und den Typ der Abfrage an, welche die meiste Zeit in Anspruch nimmt. Wenn du einen der Einträge in der Liste auswählst, werden weitere Details einschließlich einiger Beispielabfragen angezeigt. In diesem Beispiel unten siehst du, dass die Daten mit dem Finger auf die automatisch geladenen Daten im Verzeichnis wp_options zeigen. Eine schnelle Analyse der fraglichen Website bestätigte fast 250 MB automatisch geladenen Daten.
Sortiere obere automatisch geladene Daten
Der nächste Schritt wäre das schnelle Sortieren der Top-Artikel mit automatisch geladenen Daten. Hier ist ein schneller SQL-Befehl, mit dem du die Top 10 auflisten kannst:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Möglicherweise musst du die Abfrage oben optimieren, wenn deine WordPress-Seite ein anderes Präfix als wp_ verwendet.
In einzelne automatisch geladene Daten in wp_options graben
Der nächste Schritt bestand darin, einige der wichtigsten automatisch geladenen Daten zu untersuchen.
301_redirects
Wie wir oben sehen können, ist 301_redirects die oberste automatisch geladene Option. Dies hängt wahrscheinlich direkt mit einem Weiterleitungs-Plugin auf der Seite oder dem WordPress SEO-Plugin zusammen, das auch eine Weiterleitungsfunktion hat. In diesem Fall empfiehlt es sich, die Weiterleitungen auf Serverebene zu implementieren.
Warum? Die Verwendung von kostenlosen WordPress-Plugins zum Implementieren von Umleitungen kann manchmal zu Leistungsproblemen führen, da die meisten von ihnen die Funktion wp_redirect verwenden, für die zusätzliche Code-Ausführung und Ressourcen erforderlich sind. Und natürlich lädt es auch automatisch Daten in das Verzeichnis wp_options.
Wenn du ein Kinsta-Kunde bist, kannst du mit dem Tool für Weiterleitungsregeln in deinem MyKinsta-Dashboard ganz einfach Weiterleitungen auf Serverebene hinzufügen. Das ist nicht nur besser für die Leistung, sondern du musst dich auch um ein Plugin weniger kümmern!
wpurp_custom_template_
Die nächste Option mit den automatisch geladenen Daten war wpurp_custom_template_ #. Wir können sehen, dass es einige verschiedene Reihen dafür gibt. Normalerweise solltest du diesen Optionsnamen finden und die Punkte verbinden können, indem du in deinem Themes- oder Plugin-Ordner nachsiehst. In diesem Fall haben wir einen grep-Befehl vom Server ausgeführt, um zu sehen, ob wir ihn finden könnten. Du kannst es auch per SFTP überprüfen.
grep -Ri "wpurp_custom_template_"Der obige Befehl hat jedoch nichts zurückgegeben. Daher sind wir zu Google gegangen und haben eine Suche durchgeführt. Wir stellten schnell fest, dass es sich um ein WordPress-Plugin handelte, das nicht mehr auf der Seite installiert war und als WP Ultimate Recipe bekannt war. Dies ist ein klassisches Beispiel für nicht benötigte, automatisch geladene Daten. Wir haben ein langwieriges Tutorial über das Deinstallieren von WordPress-Plugins (den richtigen Weg). Und mit richtig meinen wir eigentlich das aufzuräumen, was zurückgelassen wird.
um_cache_userdata_
Die nächste obere Option mit den automatisch geladenen Daten war um_cache_userdata_ #. Wir können sehen, dass es einige verschiedene Reihen dafür gibt. Da dies nach unten gerichtet war, haben wir unseren MySQL-Befehl schnell geändert, um die 40 am häufigsten geladenen Daten anzuzeigen:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;Oder summiere alle Werte mit diesem Präfix:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"Wir konnten sehen, dass um_cache_userdata_ # viel mehr Einträge im Verzeichnis wp_options vorhanden waren. Wir haben erneut einen grep-Befehl ausgeführt, um unsere Plugins und Themes-Ordner zu überprüfen.
grep -Ri "um_cache_userdata_"Wir konnten dann schnell feststellen, dass dies mit dem Ultimate Member-Plugin zusammenhängt. Eine weitere schnelle Google-Suche ergab einige gute Lösungen für dieses Problem (siehe Support-Artikel). Unterschätze niemals die Leistungsfähigkeit einer Google-Suche! Es stellte sich heraus, dass im Plugin verschiedene Optionen zur Verfügung standen, um dieses Problem zu lösen.
- Ultimate Member> Dashboard> User-Cache> Cache löschen.
- Ultimate Member -> Einstellungen -> Erweitert -> Zwischenspeichern von Userprofildaten stoppen (auf ON stellen) und dann Änderungen speichern.
Eine weitere Option zum Anzeigen einer automatisch geladenen Option ist das Klicken auf die Schaltfläche „Edit“ („Bearbeiten“). Hier kann das Verzeichnis des Plugins / Themes oder die Website des Entwicklers aufgelistet werden.
Cron Jobs
Eine weitere häufige Option, die wir mit einer hohen Menge an automatisch geladenen Daten sehen, ist cron. Dafür könnte es alles sein, was mit cron zu tun hat. Du kannst also auf die Schaltfläche „Edit“ („Bearbeiten“) klicken, um zu sehen, was es verursacht. Nachfolgend ein Beispiel, in dem offensichtlich war, dass „do_pings“ das Problem verursacht hat. Wieder ergab eine schnelle Google-Suche eine schnelle Lösung zum Reinigen von Do_pings.
Bereinigung des wp_options-Verzeichnisses
Wenn du viel von dem siehst, was wir oben erwähnt haben, ist es wahrscheinlich Zeit für eine Bereinigung aller automatisch geladenen Daten in deinem Verzeichnis wp_options. Es wird auch empfohlen, dass du versuchst, die Anzahl der Zeilen in deinem Verzeichnis wp_options auf ein Minimum zu beschränken. Bitte mache immer Backups, bevor du Daten in deiner Database löschst. Wenn du dich damit nicht gut fühlst, empfehlen wir immer, einen WordPress-Entwickler zu engagieren. Dies ist auch ein gutes Szenario, in dem eine Staging-Umgebung von Nutzen sein kann.
Wie zuvor musst du dich bei phpMyAdmin anmelden. Klicke links auf deine Database und dann auf die Registerkarte SQL. Gib dann den folgenden Befehl ein und drücke „Go“.
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Möglicherweise musst du die Abfrage oben optimieren, wenn deine WordPress-Seite ein anderes Präfix als wp_ verwendet. Daraufhin werden alle Daten im Verzeichnis wp_options angezeigt, für die das automatische Laden festgelegt ist.
Wenn du durch die Zeilen scrollst, siehst du alle Arten von Plugins, die nicht mehr von der Seite installiert oder verwendet werden. Dies ist nur ein Beispiel, das wir verwenden werden, aber in diesem Fall haben wir eine Reihe von Jetpack-Reihen festgestellt. Jetpack wurde auf der betreffenden Seite nicht mehr verwendet.
Es ist immer gut, die Dokumentation des Plugin-Entwicklers zu überprüfen, da sie manchmal die Option haben, die zurückgelassenen Verzeichnisse aufzuräumen. In diesem Fall ist es manchmal einfacher und sicherer, das Plugin erneut zu installieren, die automatische Bereinigungsoption zu überprüfen und das Plugin anschließend ordnungsgemäß zu entfernen. Wir zeigen dir jedoch, wie du das Verzeichnis manuell bereinigst.
In diesem Fall führen wir die folgende Abfrage aus, um die automatisch geladenen Daten im Verzeichnis wp_options aus dem Jetpack-Plugin zu finden. Um die Abfrage mit deiner eigenen zu ändern, ersetze einfach %jetpack%.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Du kannst dann alle Zeilen auswählen und auf „ Delete“ („Löschen“) klicken.
Oder du kannst den folgenden Befehl ausführen:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Du kannst dann weitere automatisch geladene Daten aus Plugins und Themes in deinem Verzeichnis wp_options spülen und wiederholen.
Temporäres aufräumen
Wenn du keinen Objektcache verwendest, speichert WordPress temporäre Datensätze im Verzeichnis wp_options. Normalerweise erhalten diese eine Ablaufzeit und sollten mit der Zeit verschwinden. Das ist aber nicht immer der Fall. Wir haben einige Databases gesehen, in denen Tausende von alten temporären Datensätzen vorhanden sind. Es ist auch wichtig zu beachten, dass Temporäres standardmäßig nicht automatisch geladen wird. Du kannst eine Abfrage wie die unten stehende verwenden, um zu sehen, ob automatisch geladene temporäre Daten vorhanden sind.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Eine bessere und sicherere Option wäre jedoch die Verwendung eines kostenlosen Plugins wie Transient Cleaner, das nur die abgelaufenen -Temporären aus deinem Verzeichnis wp_options bereinigt.
Bereinigung von WordPress-Sitzungen
Ein weiteres häufiges Problem, das wir gesehen haben, ist, dass Cron-Jobs manchmal nicht mehr synchron laufen oder nicht richtig ausgelöst werden. Daher werden Sitzungen nicht bereinigt. So kannst du Tonnen von _wp_session_-Zeilen in deiner Database erhalten. In diesem Beispiel unterhalb der fraglichen Seite wurden über 3 Millionen Zeilenin ihrem wp_options-Verzeichnis abgelegt. Und das Verzeichnis war auf über 600 MB angewachsen.
Du kannst eine Abfrage wie die unten stehende verwenden, um zu sehen, ob du auf dieses Problem stößt.
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
In den meisten Fällen kannst du diese dann mit dem folgenden Befehl sicher löschen (wie es sich für einen Cron-Job gehört):
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Nach dem Bereinigen aller verbleibenden _wp_session_ rows hatte das Verzeichnis weniger als 1.000 Zeilen und wurde auf 11 MB verkleinert.
Es wurden auch Spitzen behoben, welche die Seite in MySQL bekam.
Füge einen Index für Autoload hinzu
Wenn das Aufräumen des Verzeichnisses wp_options nicht ausreicht, kannst du versuchen, dem Autoload-Feld einen „Index“ hinzuzufügen. Dies kann wesentlich dazu beitragen, dass es effizienter gesucht wird. Das großartige Team bei 10up führte einige Testszenarien für ein Verzeichnis wp_options mit einer typischen Anzahl automatisch geladener Datensätze durch, um zu zeigen, wie das Hinzufügen eines Autoload-Indexes zu den Abfragen wp_options die Leistung steigern kann.
Wir empfehlen auch, diese beiden zusätzlichen Ressourcen von WP Bullet auszulesen:
- So fügst du den MySQL-Index zum Verzeichnis wp_options hinzu
- Bereinigung des Verzeichnisses wp_options mit WP-CLI
Für noch mehr Optimierungstipps schaue dir unsere ausführliche Anleitung an: So beschleunigst du deine WordPress-Seite (Ultimate Guide)
