Eine redaktionelle Website hat über Jahre Tausende Beitragsrevisionen angesammelt. Die Datenbank wächst, zugleich benötigt die Redaktion jüngere Bearbeitungsstände für Korrekturen und Nachweise. Alle Revisionen pauschal zu löschen würde nützliche Bearbeitungsstände entfernen, ohne zu klären, ob sie das eigentliche Größenproblem sind.
Der sichere Weg beginnt deshalb mit einer Bestandsaufnahme und einer fachlich abgestimmten Aufbewahrungsregel. Erst danach wird eine begrenzte Menge bereinigt und die Wiederherstellung einer erhaltenen Revision geprüft.
Inhaltsverzeichnis
Was Beitragsrevisionen sind
WordPress speichert frühere Fassungen unterstützter Beiträge und Seiten als Revisionen. Autosaves sind verwandte Arbeitskopien, erfüllen aber einen eigenen Schutzmechanismus. Der aktuelle veröffentlichte Beitrag bleibt beim Löschen alter Revisionen bestehen.
Plugins und Page Builder können zusätzliche Metadaten an eine Revisions-ID binden. Deshalb darf eine Revision nicht als isolierte Zeile betrachtet werden; entscheidend ist, ob die verwendeten Erweiterungen ihre zugehörigen Daten korrekt behandeln.
Ein realistisches Beispiel
Ein Magazin bewahrt aus rechtlichen Gründen die Änderungen der vergangenen sechs Monate auf. Ältere Fassungen werden kaum genutzt. Eine Auswertung zeigt, dass vor allem wenige sehr häufig bearbeitete Langform-Beiträge Hunderte Revisionen besitzen.
Das Team erhält die jüngere Historie und bereinigt zunächst nur einen kleinen Teil der älteren Revisionen. Anschließend stellt es bei einem Testbeitrag eine erhaltene Fassung wieder her und kontrolliert Inhalt, Autor, Vorschau sowie Page-Builder-Layout.
Wann eine Bereinigung sinnvoll ist
Eine Bereinigung lohnt sich, wenn Revisionen einen messbaren Anteil an Datenmenge und Wartungsaufwand ausmachen und eine klare Aufbewahrung feststeht. Eine geringe Anzahl Revisionen rechtfertigt keinen Löschvorgang allein der Ordnung halber.
Während einer Migration, einer laufenden redaktionellen Prüfung oder ohne abgestimmte Historienanforderung sollte nicht bereinigt werden. Datenbankgröße ist nur ein Indikator; die redaktionelle Wiederherstellbarkeit hat Vorrang.
Der einfache Weg
- Erstellen und prüfen Sie eine aktuelle Datenbanksicherung.
- Zählen Sie Revisionen nach Beitragstyp, Alter und besonders stark betroffenen Inhalten.
- Legen Sie fest, welche Historie Redaktion und Fachbereiche benötigen.
- Bereinigen Sie zunächst eine kleine, eindeutig entbehrliche Menge.
- Prüfen Sie danach Vergleich, Vorschau, Autosave, Veröffentlichung und Wiederherstellung.
Dokumentieren Sie die Anzahl vor und nach dem Lauf. Bewahren Sie mindestens einen Testbeitrag mit mehreren erhaltenen Revisionen auf, damit die Funktionsprüfung nicht nur aus einer kleineren Zeilenzahl besteht.
Die technische Prüfung
Revisionen liegen in der Beitragstabelle und verwenden den Beitragstyp revision. Zugehörige Metadaten können in postmetastehen. Prüfen Sie beide Bereiche gemeinsam und berücksichtigen Sie benutzerdefinierte Beitragstypen.
Der Filter wp_revisions_to_keepkann die künftige Anzahl je Beitrag begrenzen. Testen Sie seine Wirkung auf Produkte, Page-Builder-Inhalte und eigene Beitragstypen, bevor er produktiv eingesetzt wird. Eine künftige Begrenzung ersetzt die kontrollierte Entscheidung über bereits vorhandene Altbestände nicht.
Vergleichen Sie nach der Bereinigung nicht nur Tabellenzahlen. Öffnen und aktualisieren Sie einen normalen Beitrag, lösen Sie einen Autosave aus und stellen Sie eine erhaltene Revision wieder her. Bei Page Buildern muss auch die strukturierte Darstellung vollständig zurückkehren.
Risiken, Backup und Rollback
Ein zu großer Löschumfang vernichtet benötigte Bearbeitungsstände. Direkte SQL-Anweisungen können zugehörige Metadaten übersehen oder benutzerdefinierte Datenmodelle beschädigen. Auch ein erfolgreich abgeschlossener Löschbefehl ist kein Nachweis für intakte Redaktionsabläufe.
Bei fehlenden Inhalten oder beschädigten Funktionen stoppen Sie jede weitere Bereinigung und stellen die geprüfte Datenbanksicherung wieder her. Der Rollback muss auch dann möglich sein, wenn das WordPress-Backend nicht zuverlässig arbeitet.
Wie AIOWS unterstützt:
AIOWS Datenbank-Bereinigung
AIOWS Datenbank-Bereinigung bündelt unterstützte Wartungsfunktionen für WordPress-Daten. Bei alten Revisionen hilft die zentrale Oberfläche, den Bereinigungsschritt klar von anderen Datenkategorien zu trennen und bewusst auszuführen.
Erstellen Sie vorher eine Datenbanksicherung und legen Sie den freigegebenen Umfang fest. Führen Sie nicht mehrere Löscharten im selben Versuch zusammen. Nach dem Lauf vergleichen Sie die Revisionszahlen und testen einen erhaltenen Bearbeitungsstand, den normalen Editor, Autosave und die öffentliche Ausgabe.
Das Modul kann nicht wissen, welche Historie Ihre Redaktion oder Rechtsabteilung benötigt, und bewertet unbekannte Plugin-Daten nicht automatisch als entbehrlich. Die fachliche Aufbewahrungsregel, die Sicherungsprüfung und ein echter Wiederherstellungstest bleiben daher Teil des Arbeitsablaufs.
Passende AIOWS-Artikel
- Abgelaufene Transients in WordPress löschen
- Spam- und Papierkorb-Kommentare in WordPress löschen
- WordPress-Datenbanktabellen sicher optimieren
Fazit
Behalten Sie eine nützliche jüngere Bearbeitungshistorie und entfernen Sie nur Revisionen außerhalb der vereinbarten Aufbewahrung. Eine kleine Testbereinigung mit anschließender Wiederherstellung ist aussagekräftiger als das Ziel, die Datenbank möglichst schnell zu verkleinern.
