Cartoons, Comics, Illustrationen, Doodles und Auftragsarbeiten

Wie in WordPress die Artikel-Revisionen aufgeräumt werden können

WordPress Revisionen ohne EndeIn diesem Tutorial erkläre ich, was es mit den Revisionen auf sich hat, die WordPress selbstständig anlegt, wie man Einfluss darauf nehmen kann ob und wie oft sie erstellt werden und wie man sie wieder los wird. Das ganze ist gespickt mit einem bisschen SQL Hintergrundwissen.

Revisionen als Datenbank-Verstopfer

Mancher WordPress-Blogger ist sich dessen nicht bewusst, dass standardmäßig nach jedem Speichern eines Postings eine Revision in der Datenbank abgelegt wird. Eine Revision ist nichts anderes als ein Duplikat des gerade geschriebenen Beitrags.

Das klingt im Prinzip nicht so dramatisch, aber wenn man bedenkt, dass selbst die kleinste Änderung an einem ellenlangen Beitrag, meinetwegen ein Vertipper, zur Folge hat, dass der ganze Beitrag 1 zu 1 nochmals in der Datenbank abgelegt wird dann kommt man schon ins Grübeln. Aber es wird noch besser, Mein letztes Tutorial, Backup und Restore einer WordPress-Datenbank, hatte zum Beispiel eine Länge von 1814 Wörtern. Dazu kommt noch der Titel, eventuell Untertitel, Trackbacks und einiges an Kleinvieh, wie Metaangaben. Nicht vergessen darf man auch die ganzen HTML-Formatierungen, Steuercodes und was man sonst noch in der reinen HTML-Ansicht (Im Gegensatz zur visuellen Ansicht).

Summa summarum komme ich so auf runde 26.000 Bytes. Am Ende des Artikels hatte ich, glaube ich, 10 Revisionen. Das macht also 26.000 * 10 / 1024 (Umwandlung in Kilobytes) = 254 KB.

Rechnen wir mal weiter:

Wir haben 20 lange Artikel á 254KB, 50 mittlere à 125KB und 100 kleinere Artikel à 75 KB.

Das macht 5080 KB + 6250 KB + 7500 KB = 18830 KB / 1024 = 18 MB!!!

Die Berechnung ist natürlich nur eine grobe Annahme. Mit insgesamt gut gemischten 170 Artikel komme ich trotzdem schon auf 18 MB an überflüssigen Daten. Nicht mit eingerechnet sind Schlagwörter und Kategorien, oder sonstige Einträge, die ich in der finalen Version übernommen habe. Das kommt noch dazu.

Wie ihr also seht, können so ziemlich schnell einige redundante Datenmengen anfallen. Und das schon bei einem kleinerem Blog.

Revisionen steuern

Was kann man dagegen tun? Aus WordPress heraus, leider nichts. Unverständlicherweise bietet WordPress im Backend keine Möglichkeit die Anzahl der Revisionen einzustellen, geschweige denn ganz auszuschalten. Auch gibt es keinen Befehl, mit dem ich überflüssige Revisionen löschen könnte.

Was tun?

  • Entweder ihr benutzt ein Plugin, Better Delete Revision ist zum Beispiel ein sehr aktuelles und bewährtes Exemplar. Es löscht nicht nur Revisionen von Artikeln, Seiten und sich darauf beziehenden Metadaten, sondern optimiert danach sogar die Datenbank.
  • Eine andere Alternative ist das händische Löschen der Revisionen. Wie das geht hat und wie man die Revisionen generell abschaltet hat Michael Oeser in dem Blog webdemar.de sehr gut erklärt. Auch, wie die Intervallzeit für die automatische Sicherung eingestellt werden kann, findet ihr dort. Sehr hilfreich.

Ans Eingemachte

Eigentlich ist euch mit dem Wissen, das ihr jetzt habt schon gut geholfen. Ich möchte aber trotzdem gerne tiefer auf einzelne Punkte eingehen.

Achtung: Es wird wieder direkt mit der Datenbank gearbeitet, zum Beispiel mit phpMyAdmin. Vergesst also nicht, vorher eine Datensicherung durchzuführen! Eine Möglichkeit habe ich ja bereits in meinem Tutorial Backup und Restore einer WordPress-Datenbank, aufgezeigt. Ein Backup empfiehlt sich aber auch bei dem oben erwähnten Plugin Better Delete revision.


Zur Rekapitulation nochmal kurz die nötigen Schritte um Revisionen zu behandeln:

Was trage ich ein, um die Revisionen auszuschalten bzw. die Anzahl der Revisionen pro Beitrag festzulegen?

Die Datei wp-config.php kennt ihr ja bereits. Das ist die, in der ihr angegeben habt wie eure Datenbank heißt, das Passwort für die Datenbank, das Prefix und dergleichen. Im Normalfall befindet sich die Datei im WordPress-Installationsverzeichnis wordpress/wp-config.php. Macht von dieser Datei eine lokale Kopie und fügt folgenden Eintrag hinzu:

Zum Anzeigen der betroffenen Datensätze gibt man folgendes ein:

define(‚WP_POST_REVISIONS‘, false );

Falls ihr aber angeben wollt, wie viele Revisionen ihr haben wollt, dann schreibt:

define(‚WP_POST_REVISIONS‘, 1 );
Statt 1 könnt ihr eine beliebige Zahl schreiben.

Wenn wir schon dabei sind, können wir auch direkt das Speicherintervall für das automatisierte Speichern ändern:

define(‚AUTOSAVE_INTERVAL‘, 300 );
Die 300 sind in Sekunden, das macht also 5 Minuten. Das reicht mir.

Achtung: Es ist wichtig, wo ihr diese Anweisung(en) einbaut. Ich hatte es zuerst ganz am Ende und es ging nicht. Eigentlich logisch, wenn man sich den Inhalt von wp-config.php genauer anschaut. Ich habe diesen Eintrag jetzt direkt nach define (‚WPLANG‘, ‚de_DE‘); aber vor define(‚WP_DEBUG‘, false); eingebaut.

Ich persönlich habe die Anzahl der Revisionen auf 1 eingestellt. Ich finde, dass es nicht schaden kann eine Sicherheitsreserve zu habe. Den Inhalt der Revisonen kann man sich übrigens ganz einfach anzeigen lassen. Einfach den entsprechenden Link mit der gewünschten Revision aus der Revisionsliste im Revisionsbereich aufrufen.


Der Müll muss weg

Soweit so gut, nur dass sich diese Einstellung nicht rückwirkend auswirkt. Also müssen die alten Revisionen gelöscht werden. Wie bereits beschrieben könnt ihr entweder das Plugin better delete revision verwenden, oder ihr gebt die nötigen SQL-Befehle ein. Genau das werde ich jetzt zeigen.


SQL-Basics mit phpMyAdmin

Im Vorfeld aber, es ist ja auch ein Einsteigertutorial, ein kurzer Umweg, damit jeder weiß wo er was tun muss. Aber wirklich nur ganz kurz 😉


SQL-Eingabe in phpMyAdmin

15_phpmyadmin-sql-eingabe






15_phpmyadmin-sql-eingabe by smollisworld

15_phpmyadmin-sql-eingabe


Wer sich auskennt bzw. mein Tutorial, Backup und Restore einer WordPress-Datenbank verfolgt hat, dem wird dieses Bild schon bekannt vorkommen. Richtig, anstatt jetzt Exportieren oder Importieren auszuwählen, klickt ihr einfach auf den Reiter SQL. Und schon könnt ihr nach Lust und Laune SQL eingeben 😉 Auf dem Screenshot habe ich bereits eine Anweisung ausgeführt, nämlich die Suche nach eventuellen Revisions. Da dies meine lokale Demo-WordPress-Installation ist, sind auch keine Revisionen vorhanden.

Ein Tipp noch: Wenn ihr wisst, in welcher Tabelle ihr was tun wollt, dann wählt diese auch vorher aus (linke Leiste), dann erhaltet ihr, wie auf dem Screenshot auch, auf der rechten Seite einen Bereich namens Felder. Das sind alle Felder, die zu dieser Tabelle gehören. Es wird sogar noch besser, durch ein Doppelklick auf eins dieser Felder, wird die Feldbezeichnung auch direkt in das Befehlsfenster eingesetzt und zwar da wo der Cursor stand. Na ist das nicht cool :)

Ich gehe mal eben die Anweisung durch:

SELECT * FROM wp_posts WHERE post_type = ‚revision‘;

Das bedeutet übersetzt:

Wähle aus (SELECT) zeige an aus allen Feldern (*) von der Tabelle (FROM) mit dem Namen (wp_posts) bei dem gilt (WHERE) Feldname enthält den Inhalt ‚revisions‘ (post_type = ‚revision‘;

Das Semikolon am Ende ist bei eindeutigem Anweisungsende nicht erforderlich, kann aber nie schaden. Das *-Zeichen bedeutet, dass alle Felder der Tabelle angezeigt werden.

Die Anweisung

SELECT ID, post_type FROM wp_posts WHERE post_type = ‚revision‘;

würde nur die Inhalte der Felder ID und post_type auswerfen. Probiert es ruhig aus. Es kann noch! nichts passieren 😉

Alternativ kann man auch sagen post_type = ‚%rev%‘. Das bedeutet dann, suche nach Inhalten im Feld post_type in dem irgendwo eine Zeichenkette ‚rev‘ steht.

Stellt euch vor, die Felder wären die Spalten und die Datensätze stünden in den Zeilen.

ID Name Alter
1 Gates 55
2 Jobs 54


Löschen der Revisionen Methode 1

Jetzt wollen wir aber endlich löschen. Der übliche Weg ist die Eingabe folgender SQL-Anweisung:

DELETE FROM `wp_posts` WHERE `post_type` = 'revision'

Wie ihr seht, ist das fast nichts anderes als oben schon steht. Außer, dass diesmal keine Auswahl (SELECT) sondern eine Löschung (DELETE) gewollt ist.

DELETE geht logischerweise ohne Auswahl der Felder, denn wir wollen die betroffenen Einträge/Zeilen ja komplett Löschen.


Löschen der Revisionen Methode 2

Aber aufgepasst, es geht noch weiter, denn die an dem Beitrag angeschlossenen Metadaten, beispielsweise die Schlagwörter, werden so nicht entfernt.

Andrei Neculau (englischer Blog) hat herausgefunden, dass es dann doch nicht immer so einfach ist, wenn man wirklich alle verknüpften Revisions-Daten löschen möchte.

Sein Lösung ist folgende:

DELETE a,b,c

FROM wp_posts a

LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)

LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)

WHERE a.post_type = ‚revision‘

Das sieht schon was komplexer aus 😉 Ist es aber nicht wirklich. Alles keine Hexerei.

Lasst uns mal kurz da durchsteigen, wenigstens in Ansätzen.

Erst einmal, was soll das a, b, c da? Nun, da Mensch meistens faul ist und dazu neigt sich bei zunehmender Komplexität zu vertun, ist es immer ratsam alles einfach zu halten. Schauen wir mal genauer hin, da steht folgendes:

wp_posts a

wp_term_relationships b

wp_postmeta c

Das bedeutet nichts anders, als: Wenn ich irgendwo ein a sehe dann meine ich eigentlich wp_posts und wenn ich ein b sehe, dann meine ich wp_term_relationships und wenn ich c sehe, dann meine ich wp_postmeta. Nichts anderes. Ich bräuchte es nicht, aber es macht die ganze Angelegenheit deutlich übersichtlicher.

Wir könnten das ganze auch so schreiben:

DELETE wp_posts,wp_term_relationships,wp_postmeta

FROM wp_posts

LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)

LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)

WHERE wp_posts.post_type = ‚revision‘


Also ich weiß nicht wie ihr das seht, aber ich persönlich ziehe die erste Variante vor 😉


Heute schon gejoint?

Jetzt wird es vielleicht ein wenig komplexer, aber so schwierig ist das auch nicht. Man kann ziemlich gut herum experimentieren, ohne der Datenbank zu schaden.

Auf den ersten Blick sieht der obige SQL-Code auch etwas dubios aus. Was aber eigentlich passiert ist folgendes:

  • Verknüpfe mir die drei Tabellen wp_posts, wp_term_relationships, und wp_postmeta, benutze aber jeweils die IDs der Tabellen zur Verknüpfung (respektive die IDs der Tabelle wp_posts, da wir ein LEFT JOIN haben) und suche mir dann aus der Tabelle namens wp_posts und dem Feld post_type alle Datensätze aus, in denen ‚revision‚ steht. Lösche diese.

Die IDs sind deswegen so wichtig, da so der Bezug zwischen den Tabellen hergestellt wird. Also die IDs aus der Tabelle a stehen im direkten Bezug zu den IDs in den Tabelle b und der Tabelle c.


Normaler JOIN

In diesem Beispiel wurde der LEFT JOIN gewählt. Was macht dieser eigentlich? Schauen wir uns zum besseren Verständnis an, was ein normaler JOIN, also ohne LEFT, RIGHT, INNER oder OUTER tun würde.

Ein normaler JOIN würde alle Datensätze anzeigen, bei denen die IDs in allen verknüpften Tabellen vom Wert her ebenfalls vorkommen.

Ein kleines Beispiel:

In Tabelle a gibt es eine ID 1 und eine ID 2.

In Tabelle b gibt es eine ID 1 und eine ID 3.

Ein normaler JOIN würde nur die Datensätze mit der ID 1 ausgeben.


LEFT JOIN

Ein LEFT JOIN, wie der Name schon sagt (left=links) zeigt dann im Gegenzug alle Datensätze an, bei denen die IDs links vorkommen und fügt dann die Daten aus Tabelle b hinzu, welche die gleichen IDs wie Tabelle a haben.

Ein kleines Beispiel:

In Tabelle a gibt es eine ID 1 und eine ID 2.

In Tabelle b gibt es eine ID 1 und eine ID 3.

Ein LEFT JOIN würde die Datensätze mit der ID 1 und der ID 2ausgeben, nicht aber die ID 3. Wohl würden aber die Daten, meinetwegen die Anschrift aus Tabelle b mit der ID 1 heraus gefischt werden.


RIGHT JOIN und die anderen

Ich glaube es würde zu weit führen in diesem Tutorial, in dem es eigentlich um Revisionen geht 😉 auch noch die anderen Joins zu erklären. Nur so viel noch, ein RIGHT JOIN verhält sich wie wie ein LEFT JOIN, nur dass eben die rechte Tabelle maßgebend ist. Nichts weiter.


Jetzt wird gespielt

Ihr könnt aber spaßeshalber folgendes probieren und mal schauen, welche Daten ausgegeben werden. Es kann nichts passieren!

SELECT *

FROM wp_posts a

LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)

LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)

WHERE a.post_type = ‚revision‘

Das ergibt eine ganz schön breite Ausgabe, oder? Aber schaut mal kurz nach der ID in der ersten Spalte. Obwohl jede Tabelle seine eigene ID hat und wir doch alle Verknüpft haben, steht da nur in der ersten Spalte die ID.

Wenn ihr weiter experimentieren wollt, dann ersetzt doch mal das LEFT durch ein RIGHT oder lasst das LEFT ganz weg. Oder macht daraus ein INNER oder OUTER. Lasst mal die WHERE-Zeile weg. Na 😉 ?


Fazit

Wie ich hoffentlich zeigen konnte, ist SQL keine Hexerei. SQL kann sehr sehr komplex werden, aber selbst mit einfachen Mitteln kann man schon eine Menge erreichen. Es kann letztendlich nie schaden, auch mal hinter den Kulissen zu blicken, denn so versteht man besser, warum etwas vielleicht nicht so funktioniert. Man verliert auch die Scheu, sich im Notfall einfach mal die SQL-Datei als Backup herunter zu laden und mit Hilfe eines Texteditors zu editieren. Nach einem Provider-Umzug kann es beispielsweise ganz hilfreich sein Änderungen durchzuführen. Das Prefix ändern?

Egal, das Thema war ja eigentlich ein bisschen tiefer in die Materie der WordPress eigenen Verwaltung der Revisions einzusteigen. Ich hoffe, das geschafft zu haben.

Wie immer gilt, bei Fragen, Anregungen, Wünschen, Kritik oder was immer euer Herz begehrt (zu diesem Thema ;)), ich bin ganz Ohr.

4 Kommentare

  1. Hallo Phillip,

    super Anleitung, sehr ausführlich! Ich denke, jetzt sollte jeder einen Weg finden, wie er sein WordPress etwas entschlacken kann! :-)

    Mit SQL habe ich aber dennoch immer wieder zu kämpfen, gerade wenn ich längere Zeit nicht damit gearbeitet habe. Umso schöner, wenn es dann schnell wieder ins Hirn zurückkommt! :-)

    Viele Grüße
    Stefan

  2. Ich hoffe, es war nicht zu ausführlich. SQL war bein uns in der Fortbildung ein dickes Thema :) Und es lässt einen auch nicht los.

  3. Vor allem kann man es als Webseitenbetreiber immer gut gebrauchen! :-)

  4. Stimmt wohl, ein bisschen wat SQL hat noch nie geschadet. Ich müsste jetzt mal an Php ran, aber das brauche ich erst im dritten Jahr :) Ich hatte da was einfaches in Drupal gemacht. Mal gucken, ob ich das in WordPress wieder einbauen kann. Herr, gib mir Zeit :)