Sirmark bloggt

Im Artikel „WordPress mit Cache beschleunigen: Plugin Quick Cache“ haben wir einen Cache mit Hilfe des Plugin „Quick Cache“ eingerichtet. Nun möchten wir wissen, ob der Cache arbeitet und vor allem, welchen Geschwindigkeitsvorteil er liefert.

Arbeitet der Cache?
Diese Frage ist schnell durch den Blick in den HTML-Code beantwortet. Allerdings sollte man es nicht versäumen, sich aus dem Dashboard auszuloggen, da das Plugin nur unangemeldete Benutzer mit Cache-Daten versorgt (was durchdacht und sinnvoll ist).

Ein Blick in den Quellcode sollte am Ende ungefähr folgende Zeilen zeigen:

</body>
</html>
<!-- This Quick Cache file was built for (  www.sirmark.de/ ) in 0.50232 seconds, on Jul 30th, 2011 at 10:27 am UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Jul 31st, 2011 at 10:27 am UTC -->

Diese Zeilen hängt das Cache-Plugin automatisch an den Code und zeigt neben einiger Werbung für sich selbst auch einige Parameter an.

Weiter kann man den Cache in Aktion sehen, indem man sich das Verzeichnis „cache“ unter „htdocs/wp-content/“ anschaut. Hier speichert das Plugin die Daten, die es ausliefert. Dieses Verzeichnis sollte sich nun stetig füllen. Wer will, kann gerne eine dieser Dateien einmal lokal kopieren und den Dateinamen um „.html“ erweitern. Im Browser geöffnet zeigt der Browser nun eine Seite unseres WordPress-Blogs.

Nachteile des Quick Cache: WP-PDA
Größtes Manko für mich ist, dass es zu Problemen im Zusammenspiel mit dem WordPress Plugin WP-PDA kommt. Je nach dem, welcher Browser eine bestimmte Seite aufruft, sorgt dieser Browser auch für den Cache. Die Browserweiche greift hier nicht mehr. Somit ist abzuwägen: Geschwindigkeitsvorteile durch einen Cache oder Code-Optimierung für mobile Benutzer? Ich habe mich aktuell für den Cache entschieden und das Plugin WP-PDA deaktiviert.

Was bringt der Cache? Ist der Performance-Gewinn zu spüren?
Ohne Stoppuhr fällt bereits auf, dass die Seiten schneller aufgebaut sind. Alle Seiten, die aus dem Cache ausgeliefert werden, müssen nicht mehr mühsam generiert werden. Auch der Datenbankserver wird davon begeistert sein. Und wir? Es ist Zeit für einen weiteren Geschwindigkeitstest. Wir starten den Test unter „ismyblogworking.org“ erneut. Sofort fällt ins Auge, dass die Einschätzung „slow“ fehlt. Der Seitenaufbau von 1,82 Sekunden ist auf „1,14 Sekunden“ gefallen. Auch wenn dies ein sehr akzeptabler Wert ist, findet er vielleicht nicht die Wertschätzung, die ihm gebührt. Wenn man allerdings bedenkt, dass in dieser Zeitangabe  auch die unveränderte Übertragung inbegriffen ist, zeigt dies, wie gut der Wert sich verbessert hat.
Noch deutlicher wird es, wenn man die „page generation time“ vergleicht, also die Zeit, die zum Erstellen der Seite benötigt wurde. Wir starteten mit 523 Millisekunden ohne Cache. Neuer Wert: 149 Millisekunden.

Sind die Werte noch zu verbessern?
Mit den oben genannten Einstellungen wurde lediglich die Erstellzeit der Seite sowie die CPU-Belastung und Auslastung des Webservers minimiert. Eine schon sehr beachtliche Leistung. Nun können noch die Daten, die übertragen werden, minimiert werden.
Über die Möglichkeit, die Datenmenge per Gzip zu verringen, berichte ich später.

Nicht nur Google legt großen Wert auf die Geschwindigkeiten von Websites. Auch der Leser selbst bricht schnell einen Besuch einer Seite ab, wenn diese sich nicht oder nur zögerlich aufbaut. Der neue Online-Dienst Web Speed Service oder das Engagement von Google in Form eines eigenen Apache-Modul „mod_pagespeed“ zeigt deutlich, welchen Wert der Suchmaschinenriese dem Parameter Geschwindigkeit zumisst.
Lange Zeit war es unabdingbar, eine Website so schlank als möglich zu halten, denn zu Modem- oder ISDN-Zeiten zählte jedes Bit, das sich über die Telefonleitung quetschte. Dank Breitband galt plötzlich „Big is beautyful“. Als gäbe es kein GPRS/UMTS oder Besucher ohne Breitbandanschluss verteilten die Webserver megabyteweise ihre Daten unter die Besucher. Und erst langsam machen sich – nicht ohne den Zwang von Google – die Webmaster wieder Gedanken, wie man eine funktionale Seite und Geschwindigkeit in ein akzeptables Verhältnis bekommt.

So gilt es

• den zu übertragenden Code zu minimieren
• die Datenbankabfragen zu minimieren und optimieren
• Elemente nutzerspezifisch asynchron nachzuladen

Eine Möglichkeit, eine Seite schneller aufzubauen, ist diese schon Vorgefertigt dem Benutzer zu präsentieren. Wenn eine Seite einmal generiert, also viel Codeteile zusammengefügt und mit mehreren Datenbankabfragen angereichert wurde, stellt sich die Frage, warum dieser Code nicht auch anderen Benutzern zugänglich gemacht werden sollte. Das Caching, also das Speichern fertiger Seiten und Ausliefern des fertigen Codes an andere Benutzer, ist eine einfache und effektive Methode, den eigenen Server zu entlasten und spürbare Effekte im Seitenaufbau zu generieren.

Wann macht Caching Sinn?
Sinn macht ein Cache nahezu immer. Selbst bei schnelllebigen Seiten wie beispielsweise bei ebay.de macht ein Cache Sinn. Dort ändert sich eine Seite zwar sekündlich (in sofern macht das Speichern der Seite keinen Sinn), doch komplexe Datenbankabfragen werden mit Sicherheit auch von den Ebay-Servern gecached. Wenn wir nun ein Content-Management-System (CMS) oder einen Blog auf WordPress-Basis nehmen: Wie oft ändert sich dort der Seitenaufbau?

Analysieren wir den sirmark.de-Blog
Über die Seite ismylogworking.org können wir schnell einige Informationen über unseren Blog erfahren. So erfahren wir beispielsweise, dass ein Testaufruf (siehe Bild) 1,82 Sekunden dauerte, was die Seite als „slow“, also langsam, wertete.
Dass ein Blog eine Webseite ist, die sich optimal zum Cachen eignet, liegt auf der Hand. Pro Tag kommt vielleicht ein Artikel hinzu, oftmals tagelang kein einziger. Plugins, die unter einem Cache leiden, sind nur wenige vorhanden. So können die Anzeigewerte der Plugins „Ähnliche Artikel“ und „Meistgelesene Artikel“ eventuell leicht falsche Werte durch eine gecachte, als letztlich veraltete Seite, anzeigen, doch dieser Nachteil ist zu verschmerzen. Wer seine Leser per Onlineumfrage abstimmen lässt (Voting WP Polls), kann hier schon eher auf Probleme stoßen. Doch auch hier kann durch eine kürzere „Cache-Lifetime“, also die Zeit, in der eine gespeicherte Seite gültig ist, entgegengewirkt werden.

Anforderungen an einen WordPress-Cache
Nach langem Suchen, experimentieren und auch nach ausgiebiger Recherche habe ich mich für Quick Cache (“A WP Super Cache Alternative”) entschieden. Neben vielen Einstellmöglichkeiten hat mich begeistert, dass man zwar viel Einstellen kann, es aber nicht muss. Die Installation ist einfach und man kommt schnell zum gewünschten Ergebnis.

Installation von Quick Cache (“A WP Super Cache Alternative”)
Die Installation ist einfach. Über das Dashboard kann das Plugin “Quick Cache” einfach installiert werden. Leider ist dann noch ein wenig Handarbeit angesagt. So führt einem das Plugin zu den Stellen, an denen noch Handarbeit notwendig ist.
Zuerst muss ein Verzeichnis „cache“ im Verzeichnis „htdocs/wp-content/“ erstellt und mit den Rechten „chmod 777“ versehen werden. Auch muss die Datei „config.php“ mindestens die Rechte „755“ aufweisen.

Optimale Einstellungen des WordPress-Plugin „Quick Cache“
Beim ersten Start des Dashboards nach der Plugin-Installation von Quick Cache fällt die Möglichkeit rechts oben auf, den Cache zu leeren. Im Moment müssen wir hiervon noch keinen Gebrauch machen. Es gilt ja eher, den Cache zu füllen. Auch im laufenden Betrieb muss man in den seltensten fällen den Cache manuell leeren.

Quick Cache On/Off
In den Einstellungen des Plugin „Quick Cache“ ist ein Augenmerk auf den Schalter „Quick Cache On/Off“ zu richten. Ohne manuelles Einschalten bleibt der Cache außer Betrieb. Doch zuerst sollte man sich mit den weiteren Einstellmöglichkeiten ein wenig vertraut machen.

Cache Expiration Time
Unter der Option „Cache Expiration Time“ ist die Zeit einzugeben, wie lange eine Seite im Cache gespeichert sein darf (Cache-Lifetime), bis die Seite neu generiert wird. Per Standard ist hier eine Stunde vorgesehen. Welcher Wert hier der richtige ist, muss jeder Webmaster für sich selbst entscheiden. Unter Anbetracht der Tatsache, dass der Cache beim Neueinstellen eines Dokumentes sowieso verworfen wird, könnten hier auch Tage oder Wochen eingestellt werden (es sei denn, man hat auf seiner Tage einen Newsticker oder ähnliches). Eine Stunde (3600 Sekunden) ist ok. Ein Tag je nach Webseite auch.

Sitemap Auto-Caching
Das Cache-Plugin optimiert die XML-Sitemap-Abfrage. Da ich trotz der Frage nach Sinn und Unsinn einer Sitemap das Plugin installiert habe, genügt hier die Eingabe der URL zur Sitemap. Hier zeigt sich, dass es sinnvoller ist, eine Sitemap zu gegebenen Anlass zu generieren und speichern (also auch eine Art Cache), als sie per Plugin jedes Mal neu generieren lassen, wenn die Sitemap von einem Suchmaschinen-Spider angefordert wird.

Cache-Daten speichern
Dies war es schon. Wenn alle Einstellungen getätigt wurden, sollten die Änderungen gespeichert und der Cache aktiviert werden.

Wie der Cache arbeitet und wie groß die Geschwindigkeitsvorteile des Caches sind, darüber berichte ich im Artikel „Quick Cache – Page Speed nachgemessen„.

Was ist überhaupt eine Sitemap?
Eine Sitemap ist ein XML, in dem eine Liste alle Seiten eines Webangebotes zu finden sind. Diese XML-Datei liegt im Root (Basisverzeichnis) eines Webangebotes und heißt in der Regel „sitemap.xml“. Suchmaschinen lesen diese Datei und haben anhand der Sitemap einen Aufstellung von Seiten innerhalb des Webangebotes, um diese Seiten zu besuchen und zu indexieren. Ziel einer solchen Sitemap ist die Sicherstellung, dass keine vielleicht wichtige Seite von den Suchmaschinen „vergessen“ wird.

Aufbau der Sitemap
Der Aufbau einer Sitemap ist standardisiert und auf sitemap.org nachzulesen. Es handelt sich um einfaches XML und stellt keine großen Anforderungen.

Benötige ich eine Sitemap?
Eigentlich nein. Ziel eines jeden Webmasters muss es sein, dass alle Seiten eines Webangebotes durch interne Verlinkung gut und schnell erreichbar sind. Wenn dies sichergestellt ist, „übersieht“ auch ein Suchmaschinen-Crawler keine Seite. Im Webmasterbereich von Google ist eine fehlende Sitemap ein Punkt, den Google zwar bemängelt, doch ich kann aus eigener Erfahrung berichten, dass das Ranking sowie die Indexierungsgeschwindigkeit (und Menge) sich auch durch eine Sitemap nicht verbessert. Wer der Meinung ist, dass die Sitemap Vorraussetzung für optimale Suchmaschinenergebnisse ist, sucht wahrscheinlich auch den Link „Seite Anmelden“ in Suchmaschinen …

Warum Sitemaps dennoch wichtig sein können
Es ist noch (!) möglich Suchmaschinen mitzuteilen, dass sich eine Sitemap geändert hat. Insofern kann eine Seite, die sich nur selten ändern, von einer Sitmap profitieren. Denn durch die Meldung fühlt sich vielleicht der Suchmaschinen-Crawler „genötigt“, die Seite neu zu indexieren. Doch auf das Ranking hat dies keinen Einfluss. Im WordPress-Umfeld existieren einige Plugins, die nur funktionieren, wenn eine Sitemap existiert. Die Plugins nutzen also das erstellte XML selbst als eine Art „Inhaltverzeichnis“ der Webseite. Warum dies so ist, verstehe ich allerdings nicht. Ich gehe davon aus, dass die Plugins das XML als eine Art Cache nutzen und davon ausgehen, damit „Performance“ zu sparen (möglich wäre ja die eigene Datenbank-Abfrage). Ob dies wirklich wegweisend ist, wage ich zu bezweifeln.

WordPress Plugin XML Sitemap Generator für WordPress installieren
Ich habe mir einige der Sitemap-Generatoren angesehen. Wer ein solches WordPress Plugin installieren möchten, lege ich „Google XML Sitemaps with qTranslate Support“ ans Herz. Die Installation ist einfach und geht schnell von der Hand. Das Plugin selbst ist meines Wissens nicht in deutscher Sprache erhältlich. Da aber nur kurz eine Administration erledigt werden muss, kann meines Erachtens auf eine Installation in Deutsch verzichtet werden.

Sitemap-Fehler “There was a problem writing your sitemap file”
There was a problem writing your sitemap file. Make sure the file exists and is writable. There was a problem writing your zipped sitemap file. Make sure the file exists and is writable.
Wenn in der Administration von „XML Sitemap Generator“ der oben genannte Fehler auftaucht, hat der XML Sitemap Generator keine Rechte um die Sitemap zu schreiben. Möglichkeiten, der Sitemap Rechte zu gewähren Eine Sitemap ist letztlich eine Datei, die um Root-Verzeichnis liegt. Wenn man dem Root-Verzeichnis das Recht „777“ (chmod 777)  gibt, wird das Schreiben der Sitemap funktionieren. Doch kein verantwortungsvoller Admin wird dies so einrichten.

Möglichkeit 1: Sitmap-Rechte per chmod 777 (Nur bedingt empfehlenswert)
Sie gewähren dem Root-Verzeichnis per „chmod 777“ alle (!) Rechte. Erstellen Sie nun über das Plugin die Sitemap einmalig. Wenn die Sitemap geschrieben wurde, setzen Sie die Rechte des Root-Verzeichnis wieder zurück (beispielsweise „chmod 755“).

Möglichkeit 2: Sitemap-Rechte per chmod 666 (bessere Lösung)
Sie kopieren irgendeine Datei (leere Textdatei etc.) in das Rootverzeichnis per FTP-Upload. Benennen Sie die Datei in „sitemap.xml“ um. Geben Sie dann der Datei das Recht „chmod 666“. Wiederholen Sie diesen Vorgang für die Datei „sitemap.xml.gz“. Durch diesen Vorgang und das einmalige Erstellen der Basis-Datei wird das Erstellen der Sitemap keine Probleme mehr bereiten.

Für etwas Interaktivität auf einer Webseite zu sorgen, ist der vielfache Wunsch eines Webmasters. Kommentare sind die Möglichkeiten des „Mitmach-Internet“ der ersten Stunde. Doch aufgrund von Kommentar-Spam neigen viele Webmaster dazu, sich erst gar nicht mit der zeitaufwändigen Kommentar-Prüfung zu beschäftigen.
Weniger zeitaufwändig für den Webmaster sowie für den Leser sind Umfragen. Ein einfacher Klick auf eine Umfrage und schon hat man seine Meinung kundgetan. Für den WordPress-Leser eine feine Sache, sofern die Umfrage vom Ablauf einfach gehalten und die Umfrage an sich stimmig und treffend ist.
So signalisiert der Autor eines Blogs oder der Webmaster mit einer zielgerichteten Umfrage auf einem Artikel oder Seite, dass ihm die Meinung der Leser durchaus wichtig ist. Oftmals ist es sehr interessant, zu welcher Überzeugung die Leserschaft kommt.

Voraussetzung für eine erfolgreiche Umfrage ist in jedem Fall, dass die Frage passend und treffend zum Thema gestellt und die Antworten möglichst das gesamte Feld der Antworten abdeckt. Wenn dies beherzigt wird, steht einer erfolgreichen Umfrage nichts mehr im Wege.

Welches Plugin für die Umfrage unter WordPress?
Plugins für Umfragen gibt es unter WordPress zuhauf. Ich habe mich für „WP-Polls“ entschieden, da das Plugin ausgereift und in ständiger Weiterentwicklung ist. Ferner gibt es bereits eine fertige deutsche Sprachdatei.

Installation von WP-Polls
Die Installation des Plugins ist simpel. Das Plugin wird herunterladen, entpackt, und alle Daten mitsamt des Ordners „wp-polls“ im Ordner „wp-content/plugins/“ via FTP kopiert. Im Dashboard muss das Plugin nun aktiviert werden. Vor dieser Aktivierung auf Wunsch erst noch die deutsche Sprachdatei installieren.

WP-Polls auf Deutsch installieren
Über den Link „Deutsche Sprachdatei für WP-Polls“ die beiden Sprachdateien „wp-polls-de_DE.mo“ und „wp-polls-de_DE.po“ herunterladen. Beide Dateien müssen im Hauptverzeichnis von „wp-polls“, also unter „/wp-content/plugins/wp-polls“ abgelegt werden. Erst dann sollte man WP-Polls aktivieren.
Hinweis: Leider beeinflusst die deutsche Sprachdatei nur die Administration. Dies ist schon mal für den Webmaster eine große Erleichterung, denn die hauptsächliche Arbeit mit wp-polls erfolgt über dieses Menü. Leider ist die Anzeige des Plugins für den Benutzer noch in englischer Sprache. Die deutsche Sprachdatei behebt diese Sprachbarriere nicht. Allerdings sind es nur wenige Stellen, wo dies einen nur deutschsprachigen Leser vom Abstimmen abhalten kann.


Eine Umfrage erstellen
Wenn WP-Polls erfolgreich installiert und aktiviert wurde, taucht in linken Rand des Dashboards der Punkt „Polls“. Über den Punkt „Add Poll“ kann eine neue Umfrage erstellt werden. Die Definition ist simpel und bedarf eigentlich keiner Erklärung. Sie können neben einer Mehrfachauswahl von Antworten auch einstellen, dass nur eine Antwort abgegeben werden soll.

Umfragen verwalten
Über den Punkt „Umfrage verwalten“ kann der Webmaster sich einen schnellen Überblick über seine Umfragen verschaffen. Alle wichtigen Daten sind hier übersichtlich aufgelistet. Auch wichtige Links wie „Logs“ (Detaillierte Informationen über die Abstimmung), „bearbeiten“ in „löschen“ finden sich hier.

Umfrage in der Sidebar anzeigen
Sie können eine Umfrag ein der Sidebar anzeigen. Dies hat den Vorteil, dass die Umfrage über alle Seiten und Artikel hinweg sichtbar ist. Hierfür wählen Sie im Dashboar den Punkt „Design“ an und wählen „Widgets“. Je nach gewähltem Template Ihrer WordPress-Installation können Sie nun das Widget „Polls“ in die Sidebar ziehen und kleinere administrative Dinge angeben.

HINWEIS: In den folgenden Beispielen verwende ich die Tilde „~“, um den Code für das installierte WP-Polls-Plugin unkenntlich zu machen (da sonst die Anzeige hier gleich übersetzt werden würde). Bitte einfach bei Übernahme des Codes in eine WordPress-Installation entfernen, also ein „[~poll_ …“ in „[poll_ …“ ersetzen.

Umfrage in einem Artikel (Seite) anzeigen
Oftmals ist es sinnvoller, eine Umfrage direkt in einen Blog-Artikel zu integrieren. Wenn die Umfrage bereits erstellt wurde (siehe „Eine Umfrage erstellen“), können Sie im Artikel-Generator einfach die Zeilenfolge
[~poll id=”1”~]
Eingeben, wobei die „1“ mit der richtigen ID der Umfrage ersetzt wird. Wenn WordPress die Seite anzeigt, erscheint anstelle dieses Platzhalters die Umfrage. Für viele Benutzer ist es jedoch einfacher, auf das neu hinzugefügte Icon (siehe Bild) zu klicken, das sich nun in der Artikel-Erfassungsmaske befindet.
Nach einem Klick müssen Sie die ID Ihrer Umfrage eingeben. Danach generiert ein Skript genau den oben beschriebenen Code an der Stelle im Text, an der sich Ihr Cursor befindet.

Zufällige Umfrage anzeigen
Zufällige Umfragen werden wie eine spezielle Umfrage in der Sidebar oder im/unter einem Artikel definiert. Als ID wird jedoch „-1“ angegeben. Der Code für die Einbindung lautet dann wie folgt:
[~poll_id=“-1“~]

Nur die Ergebnisse einer Umfrage anzeigen
Ist eine Umfrage beendet und man möchte nur noch die Ergebnisse der Umfrage anzeigen, muss der aufrufende Code nur leicht verändert werden. Es genügt, den Tag  type=“result“ hinzuzufügen. Der komplette Code lautet dann wie folgt:
[~poll_id=“1“ type=“result“~]

Spam in der Umfrage (Umfragespam)
Auch dieses Plugin ist vor Spam nicht geschützt. Allerdings hält sich das Spam-Problem durchaus in Grenzen, denn es kann über dieses Plugin kein sinnfreier Pillen-Kommentar oder Links auf Casino-Seiten generiert werden. Jedoch kann eine Umfrage durchaus durch mehrmalige Abstimmung manipuliert werden. WP-Polls versucht dies durch die Speicherung der IP-Adresse in soweit verhindern, dass dann für den Leser keine weitere Abstimmung mehr möglich ist. Doch dies ist für einen gewieften Mogler (Cheater) natürlich keine wirkliche Hürde.

Archiv für Umfragen: Umfrage-Archivseite erstellen
Es kann sinnvoll sein, eine Archivseite über alle Umfragen zu erstellen. So kann sich der Webmaster und die Leser schnell einen Überblick über die Antworten verschaffen. Hierfür legen wir unter WordPress eine neue Seite an und tragen als Inhalt (Content) ein einzige Zeile ein:
[~page_polls~]

Abschließende Bewertung des WordPress-Plugin wp-polls
Wer eine Umfrage in seinem Blog integrieren möchte, ist mit diesem Plugin sehr gut bedient. Aktuell kenne ich kein besseres Abstimmungs-Plugin für WordPress. Da ich fremde Plugins allerdings auch immer im Hinsicht auf die Performance prüfe und einen kritischen Blick auf Code und Datenbank werfe, habe ich bei diesem Plugin meine Zweifel. Der Code ist relativ fehlerfrei, auch wenn ich einiges so nicht gelöst habe. Handwerkliche Fehler sind auf jeden Fall im Datenbankdesign vorhanden. So legt der Autor beispielsweise das Feld zur Speicherung der IP-Adresse als ein varchar(100)-Feld an. Vom unnötigen Speicherplatz einmal angesehen, muss das Skript bei dem Seitenaufruf eines Benutzers auch diese Tabelle dahingehend prüfen, ob bereits eine Abstimmung über die IP des Lesers vorliegt. Hier bremst das Varchar-Feld, eine Wandlung in ein Integer-Feld würde hier erhebliche Vorteile bringen.
Es sind viele kleine Dinge, die mich davon abhalten, das Plugin „nur mal so“ einzusetzen. Wenn der Wunsch und Bedarf nach einer Abstimmung vorliegt, dann ist dieses Plugin die erste Wahl.

Nicht jeder Nutzer ist SQL mächtig. Und selbst wenn, vermisse auch ich eine Möglichkeit, mich alten Revisionen per Oberfläche zu entledigen. So kann ich per SQL manuell Revisionen löschen, wie im Artikel „WordPress beschleunigen – Artikel manuell löschen“ beschrieben, oder per Plugin. Diese Möglichkeit schafft das WordPress- Plugin “Delete Revision“. Die Installation des Plugins ist simpel, die Anwendung ebenfalls.
Unter „Einstellungen/Delete-Revision“ empfängt uns das Plugin mit dem Hinweis auf die Anzahl der möglichen Lösch-Kandidaten. Ein Klick auf „Check Redundant Revision“ gibt uns nähere Auskunft über die Revisionen unserer Artikel.

Mit einem Klick auf den Button „Yes, I would like to delete them!“ löscht das Plugin die Revisionen. Ich konnte bisher noch nicht erkennen, dass dabei etwas „schiefgelaufen“ ist. Ich empfehle trotzdem, dass sich vor dem Klick eine WordPress-Datenbank Sicherheitskopie in greifbarer Nähe befindet!

Was bringt uns die Löschung?
Im vorliegenden Beispiel einer WordPress-Installation sind rund 150 Artikel vorhanden, aber 930 Datensätze in der Tabelle „wp_posts“ (allerdings mit Attachments) vorhanden.
Nach einem Lauf des Plugin „Delete-Revisionen“ hat die Tabelle nur noch 297 Einträge (über 600 Datensätze wurden gelöscht!). Der Plattenplatz, den die Datenbank belegt hat sich von 2,547 KiB auf läppische 663,896 Bytes, der automatische Index von 95,232 Bytes auf 41,984 Bytes, also fast die Hälfte, verringert. Gerade ein kleinerer Index kann enorme Leistungssteigerungen mit sich bringen.

Wann macht das Löschen von WordPress-Revisionen Sinn?
Wer in seiner WordPress-Umgebung weniger als 100 Beträge hat und diese auch nicht alle paar Tage ändert, kann dieses Thema ignorieren. Die Leistungssteigerung dürfte sich nicht merklich verbessern. Wer seine Artikel jedoch häufig überarbeitet, viele Artikel hostet und auch massive Besucherströme zu verzeichnen hat, der tut gut daran, seine Revisionen im Blick zu halten. Man kann schon von vorneherein die Anzahl der Revisionen begrenzen (siehe Artikel „WordPress beschleunigen – Revisionen einschränken“), gelegentlich manuell einige Revisionen aus der Datenbank entfernen, oder eben auf dieses Plugin zurückgreifen. Dem Thema aber tägliche Aufmerksamkeit zu schenken, halte ich für übertrieben.

Seit der Version 2.6 von WordPress beinhaltet das CMS eine automatische Versionskontrolle. Somit kann über den Punkt „Revisionen“ auf alle Versionen eines Artikels zugegriffen werden. Somit kann im Nachhinein jederzeit nachgewiesen werden, welchen Stand ein Artikel zu einem bestimmten Termin hatte.

Was für ein professionelles Content-Management-System (CMS) schon aus Sicht einer Revision unverzichtbar ist, dürfte der Großteil der WordPress-Nutzer, die WordPress als Blogsystem oder einfaches CMS nutzen, nie – oder selten nutzen.
Doch darauf verzichten sollte man nicht. Gerade die automatische Speicherung hat schon manchen Autor viel Zeit erspart. Eine Änderung im Artikel gemacht und der Rechner zickt: Natürlich hat man den Artikel nicht gespeichert. Wer Glück hat, kann sich nun auf eine automatische Speicherung berufen.

Doch jede Speicherung des Artikels, sei es automatisch oder durch den Autor bedingt, bedeutet, dass eine neue Version in der Datenbank abgelegt wird. So sind vier oder fünft Versionen eines Artikels in der Datenbank keine Seltenheit. Prüfen kann dies jeder über den Punkt „Revisionen anzeigen“.

Ultimative Tipps für die Beschleunigung von WordPress
Unter dieser Überschrift gibt es unzählige Artikel im Netz zu finden. Manche sind gut, manche werte ich sogar eher als gefährlich. Und gerade wer nicht sicher im Umgang mit Datenbanken ist, kann hier mehr „kaputtmachen“, als sein WordPress zu beschleunigen.

Es stellt sich natürlich die Frage, warum unzählige Revisionen eines Artikels eine Performance-Bremse darstellen. In erster Linie geht es nicht um den Speicherplatz, der auf dem Webserver belegt wird. Eine moderne Datenbank wie MySQL kommt damit sehr gut klar. Ich persönlich halte das WordPress-Projekt als sehr gut in der Umsetzung. Doch im Datenbank-Design sind meines Erachtens einige entscheidende Fehler (vielleicht historisch begründet) gemacht worden. Wenn beispielsweise ein Artikel aufgerufen wird (durch jeden Benutzer), muss WordPress mehr oder weniger mühsam die aktuellste Version des Artikels ermitteln. Daher macht es Sinn, die Zahl der Revisionen zu begrenzen. Zudem verkürzt man durch eine kleinere Datenbank auch die Zeit und CPU-Last des Webservers bei einem täglichen MySQL-Backup.

Eine Möglichkeit, ausufernden Revisionen Herr zu werden, ist die Zahl der Revisionen von vorneherein zu begrenzen. Ich persönlich bin der Meinung, dass drei Revisionen zu jedem Artikel bei einem Blog oder privaten CMS durchaus reichen. Wie der Artikel am X.ten Mai 1990 ausgesehen hat, interessiert im privaten Umfeld weniger.
Hierfür sucht man in der „config.php“ die Zeile „define“ mit dem Key „WP_POST_REVISIONS“. Mit einem Komma getrennt kann man dort die Anzahl der maximalen Revisionen eintragen (zum Beispiel „3“). Der Vorteil dieser Anpassung: WordPress überschreibt nun die ältesten Revisionen automatisch.

define(‚WP_POST_REVISIONS‘, 3);

Hinweis: Durch diese Änderung werden keine Revisionen gelöscht, wenn bereits mehr als die hier angegebene Anzahl in der Datenbank enthalten sind. Diese Änderung wirkt sich nur auf neue Revisionen aus.

Mit “define(‚WP_POST_REVISIONS‘, False);” kann man WordPress dazu veranlassen, gar keine Revisionen anzulegen. Dies ist ein harter Schritt, den ich nicht empfehle. Der Nutzen, vielleicht doch einmal auf eine Vorversion zugreifen zu können, steht vielleicht nicht im Verhältnis zum Performance-Gewinn.

Eine weitere Möglichkeit sich vielleicht lästigem Datenbank-Ballast zu entledigen, ist die Revisionen mehr oder weniger automatisch zu löschen. Diese Möglichkeit beschreibe ich im Artikel „WordPress beschleunigen – Artikel manuell löschen“ oder „WordPress Artikel mittels Plugin “Delete Revision“ löschen„.

Im Artikel „WordPress beschleunigen – Revisionen einschränken“ habe ich bereits über die Problematik der duplizierten Artikel in der WordPress-Datenbank ausführlich berichtet. Auch habe ich Lösungsmöglichkeiten aufgezeigt, die Anzahl der Revisionen von vorneherein zu begrenzen.

Heute möchten wir Artikel löschen, die wir nicht mehr in der Datenbank benötigen. Hier bieten sich Plugins oder der manuelle Eingriff in die Datenbank an. Schauen wir uns zuerst den manuellen Weg an.

In der Tabelle „wp_posts“ sind für gewöhnlich alle Artikel und Revisionen gespeichert. Diese Tabelle kann je nach gewähltem Präfix auch einen anderen Namen haben. Wir gehen hier von einer Standardkonfiguration aus. In der Tabelle finden wir eine Spalte „post_type“. In diesem trägt WordPress den Status eines jeden Datensatzes ein. Jeder Artikel taucht hier je nach Revisionsanzahl mehrfach auf. Es sollte nur ein Datensatz mit dem „post_type=’post’“ geben. Der Eintrag „revision“ deutet auf eine Vorversion des Artikels hin. Datensätze mit dem Feldwert „attachment“ sind Upload-Elemente eines bestimmten Artikels.

Nun können wir alle Revisionen eines Artikels (oder alle Revisionen) löschen. Ich würde allerdings auf JEDEN FALL eine Sicherheitskopie der Datenbank anlegen, bevor ich die Datensätze lösche!!!!

Mit folgendem Befehl kann man sich ungeliebter Revisionen entledigen:

-- löscht alle Revisionen
DELETE FROM wp_posts WHERE post_type = "revision";

Gegebenenfalls möchte man aber nur die Revisionen eines Artikels löschen. Wenn die ID des Artikels bekannt ist, kann ein einfacher SELECT alle Datensätze erst einmal anzeigen

SELECT * FROM wp_posts where post_parent=ID or id=ID

Wie wir im Bild sehen, zeigt dieser SELECT mein Impressum an. Insgesamt acht Einträge hat alleine das Impressum. Den aktuellen finalen Artikel (post_type=’page’), ein Bild (post_type=’attachment’) sowie sechs mal eine Revsions-Kopie. Um diese zu löschen, kann ich folgenden SQL-Befehl eingeben (ACHTUNG: Nutzung auf eigene Gefahr! Sicherheitskopie sinnvoll!):

DELETE FROM wp_posts WHERE post_type = "revision" AND post_parent=ID;

So können Sie also manuell sich unnötiger Artikel-Versionen entledigen. Wer der SQL-Sprache mächtig ist, kann diesen Weg jederzeit gehen. Sinnvoll ist es allemal, nicht benötigte Versionen zu löschen und die Datenbank davon zu entlasten. Besser und sicherer ist es jedoch, diese Arbeit über ein Plugin zu erledigen. Wie dies mittels dem WordPress Plugin “Delete Revision“ geschieht, können Sie hier nachlesen.