WordPress Autoload-Daten: Was sie sind und wie man sie bereinigt

Die Website-Gesundheit meldete seit Monaten ein kritisches Problem auf einer meiner Websites: Autoloaded Optionen können die Leistung beeinträchtigen.

Ich habe es ignoriert. Die Website fühlte sich gut an.

Dann fragte mich jemand, warum das Dashboard fast zehn Sekunden zum Laden brauchte, obwohl die Homepage sofort aufgerufen wurde. Also überprüfte ich endlich die Autoload-Größe und fand Megabytes an Optionen in der Datenbank, die meisten davon von Plugins geschrieben, die ich vor Jahren deinstalliert hatte.

Der frustrierende Teil ist, dass die meisten Ratschläge zu diesem Thema veraltet sind. WordPress 6.6 hat die Funktionsweise von Autoload geändert, und die Abfrage, die fast jeder Leitfaden immer noch veröffentlicht, liefert jetzt die falsche Zahl.

Viele der üblichen Bereinigungsratschläge reduzieren aus Gründen, die im WordPress-Kern vergraben sind, die Autoload-Größe nicht.

In diesem Beitrag zeige ich Ihnen, was WordPress Autoload-Daten sind, wie Sie sie auf einer modernen Installation korrekt messen, was sicher zu entfernen ist und wie Sie sie bereinigen, ohne Ihre Website zu beschädigen.

Hier sind die wichtigsten Erkenntnisse:

• Autoload-Daten werden bei jeder Anfrage geladen, die WordPress erreicht, einschließlich Admin-Seiten, REST-Aufrufen und Cron-Jobs, sodass Seiten-Caching sie niemals vor Ihnen verbirgt.
• WordPress kennzeichnet ein kritisches Website-Gesundheitsproblem bei über 800 KB an Autoloaded-Optionen, was dem offiziellen Grenzwert am nächsten kommt, den Sie finden werden.
• Die SQL-Abfrage in den meisten Leitfäden unterschätzt jetzt. WordPress 6.6 hat die alten Ja/Nein-Autoload-Werte durch fünf mögliche Werte ersetzt, sodass das Filtern nach autoload='yes' neuere Zeilen übersieht.
• Das Löschen abgelaufener Transienten ändert Ihre Autoload-Größe kaum. Transienten, die mit einem Ablaufdatum erstellt wurden, werden von vornherein nicht geladen, weshalb Datenbankbereinigungs-Plugins hier anscheinend nichts bewirken.
• Die eigentliche Aufblähung sind normalerweise verwaiste Plugin-Optionen, die von Plugins hinterlassen wurden, die Sie vor Jahren entfernt haben, da nichts diese automatisch bereinigt.
• Duplicator's DB Optimizer misst die Autoload-Größe als Teil seines Datenbank-Gesundheits-Scores, was es zur einfachsten Methode macht, die Zahl im Laufe der Zeit zu verfolgen. Das Löschen von Autoloaded-Optionen ist immer noch manuelle Arbeit.
• Das Deaktivieren von Autoload ist sicherer als das Löschen. Die Daten bleiben in der Datenbank, falls ein Plugin sie benötigt, und die Änderung ist umkehrbar.
• Bearbeiten Sie wp_options niemals ohne ein aktuelles Backup. Sie arbeiten in der einzigen Tabelle, die Ihre gesamte Website offline nehmen kann.
• Wenn die Größe des Autoloads innerhalb weniger Tage nach einer Bereinigung wieder ansteigt, schreibt ein Plugin es bei jedem Durchlauf neu, und keine Menge an Bereinigung wird von Dauer sein.

Inhaltsverzeichnis

Was sind Autoload-Daten in WordPress?

Jede WordPress-Site speichert ihre Einstellungen in einer Datenbanktabelle namens wp_options. Ihre Website-URL befindet sich dort. Ebenso Ihre Liste der aktiven Plugins, Theme-Einstellungen und die Konfiguration für fast jedes von Ihnen installierte Plugin.

Jede Zeile in dieser Tabelle hat eine Spalte namens Autoload. Diese Spalte beantwortet eine Frage: Soll WordPress diese Zeile bei jeder einzelnen Seite laden oder nur, wenn etwas danach fragt?

Wenn die Antwort Ja lautet, wird die Option automatisch geladen. Das ist alles, was der Begriff bedeutet. Sie wird automatisch geladen, unabhängig davon, ob die aktuelle Seite sie benötigt oder nicht.

WordPress tut dies aus gutem Grund. Anstatt jedes Mal, wenn ein Plugin nach einer Einstellung fragt, eine separate Datenbankabfrage auszuführen, holt es alle automatisch geladenen Optionen mit einer einzigen Abfrage zu Beginn der Anfrage ab und hält sie im Speicher. Eine Abfrage ist besser als ein paar hundert kleine.

Hier ist, was typischerweise als automatisch geladene Optionen gespeichert wird:

• Kern-Einstellungen, ohne die Ihre Website nicht laufen kann, wie siteurl, home, active_plugins, template und stylesheet
• Plugin-Konfiguration, oft als ein großes serialisiertes Array pro Plugin gespeichert
• Lizenzschlüssel und Aktivierungsdaten von Premium-Plugins und Themes
• Zwischengespeicherte API-Antworten, die ein Plugin als reguläre Option statt als ordentlichen Transient gespeichert hat
• Überbleibsel von entfernten Plugins, die von selbst nichts bereinigt
• Transients, die ohne Ablaufzeit erstellt wurden, die standardmäßig automatisch geladen werden

Das Design ist in Ordnung. Die Ansammlung verursacht Probleme.

Warum verlangsamen Autoload-Daten Ihre Website?

Jede Anfrage, die WordPress erreicht, bezahlt für Ihre Autoload-Größe. Dies betrifft nicht nur Seitenaufrufe von Besuchern, sondern auch Admin-Bildschirme, REST-API-Aufrufe, WP-Cron-Jobs, AJAX-Anfragen und jede Hintergrundaufgabe, die Ihre Plugins auslösen.

Die Kosten sind nicht nur die Abfrage. Optionswerte werden serialisiert gespeichert, sodass PHP sie bei jedem Laden in den Speicher deserialisieren muss. Eine 3 MB große Autoload-Tabelle bedeutet, dass Ihre Website 3 MB PHP-Arrays neu erstellt, bevor sie ein einziges Wort Inhalt rendert.

Das ist Speicher und CPU, bei jeder Anfrage, für immer.

Seiten-Caching hilft hier nicht. Ein Cache liefert Besuchern eine fertige HTML-Seite, sodass diese Anfragen WordPress vollständig umgehen. Ihre eigenen Anfragen tun dies nicht.

Hier zeigt sich eine aufgeblähte Autoload-Tabelle zuerst:

• wp-admin fühlt sich langsam an, während das Frontend schnell bleibt, da Admin-Seiten nie gecached werden
• Der Block-Editor ruckelt beim Speichern oder Laden, da jede Editor-Anfrage einen vollständigen WordPress-Ladevorgang durchläuft
• WooCommerce-Warenkörbe und Checkout sind langsam, da diese Seiten von Natur aus vom Caching ausgeschlossen sind
• Eingeloggte Benutzer haben eine langsamere Website als alle anderen, was das Problem schwer reproduzierbar macht
• Cron-Jobs stapeln sich, da jeder den gleichen Overhead mit sich trägt

Wenn Ihr Hoster Ihnen jemals gesagt hat, dass die Datenbank in Ordnung aussieht, während Ihr Dashboard langsam ist, liegt es normalerweise daran. Die Autoload-Größe wird in den Metriken, die die meisten Hoster überprüfen, nicht angezeigt.

Ich möchte jedoch ehrlich über den Umfang sein. Autoload-Bloat ist selten das Einzige, was eine Website verlangsamt, und das Bereinigen wird eine Website mit einem langsamen Hoster und nicht optimierten Bildern nicht retten.

Es ist nur der Teil, den fast niemand überprüft, und er wächst leise jeden Monat, in dem Sie Ihre Website betreiben.

Wie viel WordPress Autoload-Daten sind zu viel?

Suchen Sie nach dieser Frage, und Sie erhalten fünf verschiedene Antworten. Einige Anleitungen sagen 300 KB, andere 1 MB.

WordPress 6.6 hat die Grenze für alle gezogen. Die Website-Gesundheit zeigt jetzt ein kritisches Problem an, wenn Ihre gesamten autoloaded Optionen 800 KB überschreiten.

Hier lese ich die Bereiche in der Praxis:

• Unter 800 KB: gesund. Die Website-Gesundheit bleibt ruhig, und Sie müssen nichts weiter verfolgen.
• 800 KB bis 1 MB: einen Blick wert. Sie liegen über dem Kernschwellenwert, und normalerweise sind ein oder zwei Plugins dafür verantwortlich.
• 1 MB bis 3 MB: ein echtes Problem. Erwarten Sie merklich langsamere Admin-Bildschirme, insbesondere auf Shared Hosting.
• Über 3 MB: etwas schreibt aktiv Müll nach einem Zeitplan, und das Aufräumen wird nicht helfen, bis Sie es finden.

Sie können den Schwellenwert mit dem Filter site_status_autoloaded_options_size_limit erhöhen, aber das verbirgt nur die Warnung. Die Abfragen laufen immer noch mit der gleichen Größe.

Allein die Größe sagt Ihnen auch nicht alles. Hundert kleine verwaiste Zeilen sind weniger aufmerksamkeitswürdig als ein 2 MB großes serialisiertes Array von einem Slider-Plugin, das Sie 2022 nicht mehr verwendet haben.

Verfolgen Sie die größten Übeltäter, nicht die Anzahl.

Ein weiteres gutes Verhalten, das es wert ist, darüber Bescheid zu wissen: Seit WordPress 6.6 wird jede neue Option, die größer als 150 KB ist, standardmäßig nicht geladen.

Der Kern hat diese Entscheidung getroffen, weil übergroße autoloaded Optionen ein so häufiges Leistungsproblem waren. Es ist zwar durch wp_max_autoloaded_option_size filterbar, aber eine Erhöhung ist keine gute Idee.

Dieser Schutz gilt nur für die Zukunft. Alles, was sich bereits vor der Änderung in Ihrer Datenbank befindet, wird weiterhin genau wie immer geladen.

Warum die meisten Autoload-Anleitungen Ihnen jetzt die falsche Zahl geben

Für den größten Teil der WordPress-Geschichte enthielt die Autoload-Spalte einen von zwei Werten: yes oder no. Einfach. Jedes Tutorial, das jemals über Autoload-Daten geschrieben wurde, basierte auf dieser Annahme.

WordPress 6.6 hat ihn durch fünf mögliche Werte ersetzt:

• on: explizit zum Laden eingestellt und wird es immer sein
• off: explizit nicht zum Laden eingestellt und wird es niemals sein
• auto: keine explizite Präferenz wurde gegeben, also entscheidet WordPress (und lädt es derzeit)
• auto-on: WordPress hat dynamisch entschieden, dass es geladen werden sollte
• auto-off: WordPress hat dynamisch entschieden, dass es nicht geladen werden sollte, normalerweise weil der Wert über 150 KB liegt

Bestehende Zeilen wurden nicht migriert. Optionen, die vor der Änderung erstellt wurden, behalten ihre ursprünglichen Werte yes und no, die der Kern als äquivalent zu on und off behandelt.

Jede Website, die nach dem 6.6-Upgrade läuft, enthält nun eine Mischung aus alten und neuen Werten in derselben Spalte.

Viele Leute werden Ihnen sagen, Sie sollen eine Abfrage mit autoload='yes' ausführen. Auf einer modernen Website überspringt diese Abfrage stillschweigend jede Option, die seit 6.6 geschrieben wurde, sowie alles, was vom Core als automatisch oder automatisch aktiviert markiert ist.

Sie erhalten eine Zahl. Es ist nur nicht Ihre Zahl und sie ist immer zu niedrig.

Die Lösung besteht darin, jeden Wert zu überprüfen, den WordPress als autoloading behandelt. Der Core stellt genau diese Liste über wp_autoload_values_to_autoload() bereit, die standardmäßig yes, on, auto-on und auto zurückgibt.

Welche SQL-Abfrage sollten Sie stattdessen ausführen?

Wenn Sie Zugriff auf phpMyAdmin oder das Datenbanktool Ihres Hosters haben, sagen Ihnen diese beiden Abfragen fast alles, was Sie wissen müssen. Führen Sie sie im SQL-Tab Ihrer Website-Datenbank aus.

Bevor Sie etwas gegen wp_options ausführen, erstellen Sie ein Backup. Diese beiden Abfragen lesen nur Daten und ändern nichts, aber der nächste Abschnitt bearbeitet Zeilen, und es ist besser, auf Nummer sicher zu gehen.

Beginnen Sie mit Ihrer gesamten Autoload-Größe:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Dies gibt Ihre Gesamtgröße in Kilobytes zusammen mit der Anzahl der beteiligten Optionen zurück. Vergleichen Sie sie mit dem Schwellenwert von 800 KB aus dem letzten Abschnitt.

Finden Sie dann heraus, was dafür verantwortlich ist:

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

Dies gibt Ihnen die zwanzig größten autoloaded Optionen nach Namen, mit ihren individuellen Größen und ihrem aktuellen Autoload-Wert. Auf den meisten Websites sind die oberen drei oder vier Zeilen für den Großteil des Problems verantwortlich.

Zwei Dinge, auf die Sie achten sollten, bevor Sie diese kopieren:

• Ihr Tabellenpräfix ist möglicherweise nicht wp_. Viele Installationen verwenden aus Sicherheitsgründen etwas Benutzerdefiniertes. Überprüfen Sie wp-config.php auf den Wert $table_prefix und fügen Sie ihn in die Abfrage ein.
• Multisite funktioniert anders. Jede Unterseite hat ihre eigene Options-Tabelle (wp_2_options, wp_3_options usw.) plus eine netzwerkweite wp_sitemeta-Tabelle. Sie müssen diese separat überprüfen.

Wenn Sie lieber die Kommandozeile verwenden möchten, erledigt WP-CLI beide Aufgaben in jeweils einer Zeile. Dies gibt Ihre Gesamtsumme in Bytes zurück:

wp option list --autoload=on --format=total_bytes

Und dies listet autoloaded Optionen mit ihren gespeicherten Größen auf:

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

Nicht jeder möchte eine Datenbankkonsole anfassen, und das müssen Sie auch nicht. Der nächste Abschnitt behandelt zwei Wege, die innerhalb des WordPress-Dashboards bleiben.

Wie überprüfen Sie Ihre WordPress Autoload-Größe?

Sie können nicht beheben, was Sie nicht gemessen haben, und Sie werden nach jeder Änderung erneut messen wollen.

Es gibt drei Möglichkeiten, die Zahl zu ermitteln, je nachdem, wie nah Sie an die Datenbank herankommen möchten.

Option 1: Website-Zustand (Der schnellste Weg)

WordPress überprüft dies bereits für Sie. Gehen Sie zu Werkzeuge » Website-Zustand und öffnen Sie den Tab Status. Suchen Sie dann in der Liste nach Autoloaded options could affect performance.

Erweitern Sie ihn und Sie erhalten Ihre Gesamtgröße.

Der Haken ist, dass diese Prüfung erst erscheint, wenn Sie über 800 KB liegen. Stille bedeutet nicht, dass Sie bei Null sind; es bedeutet, dass Sie unter dem Limit liegen. Sie erhalten auch nur eine Momentaufnahme ohne Verlauf und ohne Möglichkeit, auf das Gesehene zu reagieren.

Option 2: DB Optimizer's Health Score (am einfachsten zu verfolgen)

Wenn Sie die Autoload-Größe im Laufe der Zeit verfolgen möchten, anstatt sie einmal zu überprüfen, zeigt DB Optimizer sie in einem Dashboard an.

Öffnen Sie DB Optimizer, und Sie erhalten einen Datenbank-Gesundheits-Score von 0 bis 100. Fünf farbcodierte Balken unterteilen den Score: Tabellen-Overhead, Transients, Revisionen, Autoload-Größe und Papierkorb-Elemente.

Lassen Sie mich klarstellen, was dies tut und was nicht. DB Optimizer misst Ihre Autoload-Größe und meldet sie. Es löscht keine autoloaded Optionen.

Das Entfernen von autoloaded Daten ist immer noch manuelle Arbeit, und ich werde sie unten durchgehen.

Was es bereinigt, sind Beitragsrevisionen, automatische Entwürfe, gelöschte Inhalte, Spam-Kommentare, abgelaufene Transients, Pingbacks, Trackbacks und der oEmbed-Cache. Diese sind es wirklich wert, bereinigt zu werden. Sie sind nur ein anderes Problem als Autoload.

Bevor Sie mit einer manuellen Bereinigung beginnen, schadet es nicht, eine schnelle Datenbankbereinigung durchzuführen. Öffnen Sie den Tab Bereinigung und führen Sie alle verfügbaren Optimierungen durch.

Gehen Sie dann zum Tab Tabellen. Optimieren Sie alle Tabellen mit Overhead.

Klicken Sie im Dashboard auf Score aktualisieren und beobachten Sie, was mit der Autoload-Größe passiert:

• Der Score steigt merklich an: Nicht ablaufende Transients waren Teil Ihres Problems, und Sie haben einige davon bereinigt.
• Der Score bewegt sich kaum: Ihr Datenmüll sind verwaiste Plugin-Optionen, und kein Bereinigungstool wird sich darum kümmern. Gehen Sie direkt zu den manuellen Methoden.
• Der Score steigt an und fällt innerhalb weniger Tage zurück: Ein aktives Plugin überschreibt bei jedem Durchlauf autoloaded Optionen.

Dieser letzte Fall ist es wert, frühzeitig erkannt zu werden. Er erspart Ihnen, jeden Monat dieselben Zeilen zu bereinigen und sich zu fragen, warum nichts bleibt.

DB Optimizer warnt Sie auch, wenn Sie kein aktuelles Backup haben, und verlinkt direkt zur Erstellung eines solchen. Es ist kostenlos in den Duplicator Pro und Elite Plänen enthalten, damit Sie Ihre Website sicher und reibungslos am Laufen halten können.

Option 3: Führen Sie die Abfrage selbst aus (Die präziseste)

Die SQL- und WP-CLI-Befehle im vorherigen Abschnitt geben Ihnen die genaue Anzahl und die vollständige Rangliste, ohne dass ein Schwellenwert Ihnen etwas vorenthält.

Dies ist der Weg, den ich benutze, wenn ich etwas ändern möchte, da er der einzige ist, der Ihnen den aktuellen Autoload-Wert jeder Zeile anzeigt. Diesen benötigen Sie, bevor Sie mit der Bearbeitung beginnen.

Warum hat eine Datenbankbereinigung Ihre Autoload-Größe nicht behoben?

Hier ist der Ratschlag, den Sie in fast jedem Artikel zu diesem Thema finden werden: Bereinigen Sie Ihre Transients, und Ihre Autoload-Größe wird sinken.

Das ist größtenteils falsch, und im WordPress-Kern können Sie es beweisen.

Sehen Sie sich an, was set_transient() tut, wenn es einen Transient erstellt. Wenn Sie eine Ablaufzeit angeben, speichert WordPress diesen Transient mit Autoload auf false gesetzt. Nur Transients, die ohne Ablaufdatum erstellt wurden, werden autoloaded, und das ist die Minderheit.

Abgelaufene Transients sind per Definition Transients, die ein Ablaufdatum hatten. Das bedeutet, dass sie nie autoloaded wurden. Sie können fünftausend davon löschen, Ihre wp_options-Tabelle um hundert Megabyte verkleinern und Ihre Autoload-Zahl um fast nichts verändern.

Beide Bereinigungen sind lohnenswert. Eine riesige wp_options-Tabelle verlangsamt Abfragen, bläht Ihre Backups auf und führt dazu, dass Migrationen fehlschlagen. Es ist einfach ein anderes Problem mit einer anderen Lösung, und die Vermischung der beiden ist der Grund, warum so viele Leute denken, ihr Bereinigungsprogramm sei kaputt.

Was bleibt also übrig, wenn die Transients weg sind? Meiner Erfahrung nach ist es fast immer eines davon:

• Serialisierte Einstellungsarrays von Plugins, die Sie deinstalliert haben. Die meisten Plugins bereinigen sich bei der Deinstallation nie selbst, und diese Einstellungen werden für immer weiter geladen.
• Lizenz- und Aktivierungsdaten von Premium-Plugins, einschließlich solcher, deren Lizenzen vor Jahren abgelaufen sind.
• Zwischengespeicherte API-Antworten, die als normale Optionen gespeichert sind und nicht als richtige Transients, normalerweise von Social-Feed-, Analyse- oder SEO-Plugins.
• Protokollähnliche Optionen, die unbegrenzt wachsen, bei denen ein Plugin bei jedem Ereignis eine einzelne Optionszeile anhängt, anstatt eine eigene Tabelle zu verwenden.
• Nicht ablaufende Transients, die hier die wirkliche Ausnahme darstellen und die einzigen, bei denen eine Transientenbereinigung hilft.

Keines davon lässt sich mit einem Ein-Klick-Tool beheben. Das ist die ehrliche Antwort, und deshalb ist der nächste Abschnitt praxisorientiert.

Wie bereinigen Sie WordPress Autoload-Daten?

Es gibt kein Plugin, das dies mit einem Klick behebt. Das Leeren von Autoload-Optionen bedeutet, bestimmte Zeilen zu identifizieren und zu entscheiden, was mit jeder einzelnen zu tun ist.

Das klingt schlimmer, als es ist. Auf den meisten Websites sind drei oder vier Zeilen für den Großteil des Problems verantwortlich, sodass Sie drei oder vier Entscheidungen statt Hunderte treffen.

Hier sind die drei Methoden, geordnet von der sichersten zur aufwendigsten:

• Autoload für große Optionen deaktivieren: ändert den Wert einer einzelnen Spalte, ohne etwas zu löschen, und ist vollständig rückgängig machbar.
• Verwaiste Optionen von entfernten Plugins löschen: löscht dauerhaft Zeilen, die von Plugins hinterlassen wurden, die endgültig entfernt wurden.
• Ersetzen Sie das Plugin, das sie weiterhin schreibt: die einzige Lösung, die Bestand hat, wenn etwas bei jedem Durchlauf weiterhin Bloat generiert.

Erstellen Sie ein vollständiges Backup, bevor Sie eine davon beginnen. Duplicator Pro erstellt in wenigen Minuten eine vollständige Kopie Ihrer Datenbank und Dateien, und die Ein-Klick-Wiederherstellung bedeutet, dass eine fehlerhafte UPDATE-Anweisung Sie zehn Minuten statt Ihres Wochenendes kostet.

Methode 1: Autoload für umfangreiche Optionen deaktivieren

Beginnen Sie hier, denn nichts wird gelöscht. Sie ändern den Wert einer Spalte, und Sie können ihn wieder ändern.

Nehmen Sie die Liste der Top-Übeltäter aus Ihrer Abfrage und arbeiten Sie sie durch. Bei jeder großen Option stellt sich die Frage, ob die Website diese Daten bei jedem Seitenaufruf benötigt.

Verifizieren Sie vor dem Deaktivieren des Autoloads, wie und wo das Plugin die Option liest. Einige Konfigurationsarrays werden für Frontend-Anfragen legitim benötigt; andere sind nur für den Admin-Bereich oder selten aufgerufen und werden besser bei Bedarf geladen.

Um zu verhindern, dass eine Option automatisch geladen wird, aktualisieren Sie ihren Autoload-Wert:

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

Verwenden Sie unter WordPress 6.6+ off. WordPress erkennt auch den älteren Wert no als nicht automatisch geladen, sodass es mit älteren Installationen kompatibel bleibt.

WP-CLI erledigt dies mit einem Befehl und akzeptiert on, off, yes oder no:

wp option set-autoload your_option_name_here off

Die Daten bleiben genau dort, wo sie sind. WordPress hört einfach auf, sie bei jeder Anfrage zu laden, und ruft sie stattdessen bei Bedarf ab, wenn etwas get_option() aufruft.

Führen Sie nach jeder Änderung zwei Dinge durch: Führen Sie Ihre Größenabfrage erneut aus, um zu bestätigen, dass die Zahl gesunken ist, und laden Sie sowohl Ihr Frontend als auch wp-admin, um zu bestätigen, dass nichts kaputt gegangen ist.

Führen Sie nicht zwanzig Änderungen auf einmal durch und testen Sie dann. Wenn etwas schief geht, möchten Sie wissen, welche Zeile es verursacht hat.

Eine Sache, auf die Sie achten sollten: Wenn eine Option nach einem Plugin-Update wieder auf Autoload gesetzt wird, überschreibt dieses Plugin den Wert bei der Aktivierung oder Aktualisierung. Ihre Änderung ist nicht fehlgeschlagen; sie wurde überschrieben.

Das ist ein Support-Ticket für die Entwickler des Plugins wert und ein starkes Signal, dass Sie auf Methode 3 zusteuern.

Methode 2: Verwaiste Optionen von entfernten Plugins löschen

Löschen ist permanent, daher erfordert diese Methode mehr Sorgfalt als die letzte.

Arbeiten Sie Ihre Liste der Top-Übeltäter durch und ordnen Sie jeden Optionsnamen dem Plugin zu, das ihn erstellt hat. Die meisten verwenden ein erkennbares Präfix, obwohl nicht alle offensichtlich sind.

Suchen Sie nach dem Optionsnamen, bevor Sie ihn anfassen, da ein Name, der verlassen aussieht, manchmal zu etwas gehört, das noch läuft.

Bestätigen Sie dann, dass das Plugin wirklich weg ist.

Deaktiviert ist nicht weg. Ein deaktiviertes Plugin hat immer noch seine Dateien auf der Festplatte und nimmt seine Einstellungen sofort wieder auf, wenn Sie es reaktivieren. Das Löschen seiner Optionen während der Deaktivierung verliert also nur Ihre Konfiguration.

Bevor Sie eine Option löschen, überprüfen Sie, ob Sie die exakte Zeile anvisiert haben, die Sie entfernen möchten. Diese schreibgeschützte Abfrage zeigt die ID, den Namen, den aktuellen Autoload-Status und die gespeicherte Größe der Option an, ohne etwas zu ändern:

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Sobald Sie sicher sind, entfernen Sie die Zeile:

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Führen Sie niemals einen DELETE mit einem LIKE-Wildcard in dieser Tabelle aus, es sei denn, Sie haben zuerst jede übereinstimmende Zeile gelesen. Ein Muster, das spezifisch aussieht, kann weitaus mehr als erwartet übereinstimmen, und wp_options ist die einzige Tabelle, in der ein Fehler die gesamte Website lahmlegt, anstatt eine Funktion zu beeinträchtigen.

Wenn Sie eine Zeile überhaupt nicht identifizieren können, löschen Sie sie nicht. Schalten Sie ihren Autoload mit Methode 1 aus und lassen Sie sie dort.

Sie erhalten den vollen Leistungsvorteil, die Daten bleiben erhalten, und Sie können sie in Sekundenschnelle rückgängig machen, wenn sich herausstellt, dass etwas sie benötigt.

Dies ist der Punkt, an dem das Backup aufhört, eine Formalität zu sein. Sie löschen Zeilen aus der wichtigsten Tabelle Ihrer WordPress-Datenbank, und die Notfallwiederherstellungs-URL von Duplicator Pro stellt die Website wieder her, selbst wenn eine fehlerhafte Abfrage Sie aus wp-admin aussperrt.

Methode 3: Ersetzen Sie das Plugin, das es immer wieder schreibt

Wenn Ihre Autoload-Größe innerhalb weniger Tage nach einer Bereinigung wieder über 1 MB steigt, hören Sie auf aufzuräumen. Etwas schreibt aktiv bei jedem Lauf, und Sie werden das für immer tun.

Die üblichen Verdächtigen, basierend auf dem, was ich immer wieder finde:

• Slider- und Page-Builder-Plugins, die riesige serialisierte Konfigurationsarrays speichern
• Analyse- und Statistik-Plugins, die in eine Optionszeile statt in ihre eigene Tabelle protokollieren
• Sicherheits-Plugins, die Ereignisprotokolle als Optionen führen
• Verlassene Weiterleitungsmanager, bei denen jede Weiterleitungsregel in einer wachsenden Option lebt
• Social-Feed-Plugins, die API-Antworten als einfache Autoload-Optionen zwischenspeichern

Den Schuldigen zu finden ist einfacher als es klingt. Notieren Sie Ihre Top-Übeltäter, warten Sie ein paar Tage und führen Sie die Abfrage dann erneut aus. Was auch immer gewachsen ist, ist Ihre Antwort.

Das Austauschen eines Plugins auf einer Live-Site birgt Risiken, und dies ist der einzige Teil dieses Prozesses, den ich niemals zuerst in der Produktion durchführen würde.

Duplicator Pro ermöglicht es Ihnen, jedes vollständige Website-Backup mit wenigen Klicks in eine Staging-Site zu verwandeln, ohne ein separates Hosting-Konto oder manuelle Dateiübertragungen.

Testen Sie den Ersatz dort, bestätigen Sie, dass die Website weiterhin funktioniert und die Autoload-Größe gleich bleibt, und nehmen Sie dann die Änderung in der Produktion vor.

Wie verhindern Sie, dass WordPress Autoload-Daten zurückkehren?

Bereinigung ist keine einmalige Aufgabe, da die Autoload-Daten von WordPress als Nebeneffekt der normalen Website-Wartung wachsen. Jedes Plugin, das Sie ausprobieren, hinterlässt etwas.

Ein paar Gewohnheiten verhindern, dass es Ihnen wieder entgleitet:

• Überprüfen Sie Ihre Punktzahl monatlich oder nach jeder Stapel von Plugin-Änderungen. Das Dashboard von DB Optimizer macht dies zu einer zehn Sekunden dauernden Aufgabe, aber Site Health funktioniert gut, wenn Sie lieber kein Plugin hinzufügen möchten.
• Löschen Sie Plugins ordnungsgemäß, anstatt sie zu deaktivieren. Deaktivieren lässt jede Option an Ort und Stelle. Das Löschen gibt zumindest einem gut gebauten Plugin die Chance, aufzuräumen, obwohl viele es immer noch nicht tun.
• Überprüfen Sie die Option, bevor Sie deinstallieren. Wenn Sie wissen, dass ein Plugin Daten hinterlässt, notieren Sie sich seine Optionsnamen, während es noch installiert und leicht zu identifizieren ist.
• Installieren Sie weniger Plugins. Es ist der am wenigsten befriedigende Ratschlag auf dieser Liste und der effektivste. Jedes Plugin, das Sie nicht ausprobieren, sind Autoload-Daten, die Sie nie bereinigen müssen.
• Halten Sie ein aktuelles Backup nach einem Zeitplan, damit die Datenbankbereinigung eine risikoarme Entscheidung und keine nervöse ist.
• Beobachten Sie die Website-Gesundheit, anstatt darauf zu warten, dass die Website langsam wird. Bis Sie die Verzögerung bemerken, sind Sie normalerweise weit über 2 MB.

Häufig gestellte Fragen (FAQs)

WordPress Autoload-Daten sind eine Wartungsgewohnheit, keine einmalige Lösung

Autoload-Bloat ist die angesammelte Kostenbelastung jedes Plugins, das Ihre Website jemals ausprobiert hat. Das ist es wert, darüber nachzudenken, denn es formuliert das Problem neu.

Es ist kein Fehler oder ein Zeichen dafür, dass Sie etwas falsch gemacht haben. Es ist der gewöhnliche Rückstand des Betriebs einer WordPress-Website über einige Jahre, und nichts in WordPress bereinigt es für Sie.

Ich möchte lieber ehrlich über die damit verbundene Arbeit sein. Die Bearbeitung von wp_options von Hand birgt echte Risiken, die verfügbaren Tools messen das Problem eher, als dass sie es beheben, und Sie werden in sechs Monaten wieder hier sein, wenn Sie weiterhin Plugins installieren (was Sie tun werden).

Stellen Sie eine Erinnerung ein, überprüfen Sie die Zahl vierteljährlich und behandeln Sie sie wie jede andere Wartungsaufgabe.

Hier ist noch eine Sache, die es wert ist zu tun und die ich noch nicht erwähnt habe: Überprüfen Sie Ihre Autoload-Größe direkt vor einer Migration. Es ist der billigste Weg, ein Backup-Archiv zu schrumpfen und die Importzeit auf der anderen Seite zu verkürzen.

Eine aufgeblähte wp_options-Tabelle ist einer der häufigsten Gründe, warum ein Datenbankimport auf einem neuen Host ins Stocken gerät oder Zeitüberschreitungen aufweist, und es ist wirklich frustrierend, eine fehlgeschlagene Migration zu debuggen. Zehn Minuten Bereinigung vor dem Export ersparen das vollständig.

Bevor Sie wp_options anfassen, stellen Sie sicher, dass Ihre Website geschützt ist

Das Bereinigen von Autoload-Daten bedeutet, UPDATE- und DELETE-Anweisungen gegen die eine Tabelle auszuführen, die Ihre gesamte Website offline nehmen kann. Ein fehlplatzierter Wildcard in einer Abfrage und Sie sehen einen weißen Bildschirm, ohne Möglichkeit, auf wp-admin zuzugreifen, um ihn zu beheben.

Duplicator Pro macht aus einem solchen Fehler eine wiederherstellbare Situation statt einer Katastrophe. Erstellen Sie ein vollständiges Backup, bevor Sie beginnen, und stellen Sie es mit einem Klick in wenigen Minuten wieder her, falls etwas schiefgeht.

Seine Disaster-Recovery-URL bringt eine Website wieder zum Laufen, selbst wenn WordPress vollständig gesperrt ist, was genau das Szenario ist, das eine fehlerhafte Datenbankabfrage erzeugt. Probieren Sie es noch heute aus!

Wenn dieser Beitrag Sie dazu gebracht hat, darüber nachzudenken, was sich noch in Ihrer Datenbank befindet, sind diese Anleitungen eine Lektüre wert.

• So löschen Sie alle Transienten in WordPress (4 Methoden)
• So optimieren Sie Ihre WordPress-Datenbank: In 10 Schritten zu einer schnellen Website
• WordPress-Datenbankbereinigung: Ein Leitfaden für Anfänger zur Entfernung von Junk
• 7 WordPress-Datenbank-Warnzeichen, die die meisten Website-Besitzer übersehen
• So beheben Sie eine langsame WordPress-Datenbank: Eine Checkliste in 4 Schritten
• WordPress-Datenbankwartung: Was Sie wöchentlich, monatlich und vierteljährlich tun sollten