Wordpress

Im Artikel „WordPress Plugin GD Star Rating” bin ich auf die Möglichkeit eingegangen, wie man ein Artikel-Bewertungssystem für Googles Rich-Snipptes unter WordPress einbindet. Nur kurz habe ich den Rich Snippets Bewertungs-Spam angesprochen..

Wozu nutzt Rich Snippets-Spam?
Zuerst einmal das Gute: Für das Google-Ranking nutzt das Manipulieren der Rich Snippets-Bewertungen erst einmal gar nichts. Ein Webmaster teilt per Rich Snippets bzw. Micro-Data den Suchmaschinen lediglich mit, wie das interne Ranking aussieht. Die Suchmaschine entscheidet anhand anderer Kriterien über das Ranking. Nach meinen Beobachtungen werden die Rich-Snippets jedoch nur auf den vorderen Platzierungen eingeblendet und dann auch nur, wenn das Ergebnis „positiv“ ist. Wohlgemerkt, dies ist meine Beobachtung. Google selbst sagt, dass das Manipulieren nichts bringt, ruft aber gleichzeitig dazu auf, solchen Spam zu melden (Spam in Rich Snippets melden). In der Regel bedeutet dies, dass die Suchmaschine also automatisiert solchen Spam nicht entdecken kann und es sinnvoll ist, zu spammen.

Warum wird dann trotzdem Rich Snippets-Spam betrieben?
Wenn Google ein positives Star-Voting in den SERPS anzeigt, bedeutet dies, dass viel mehr neue Besucher diesen Eintrag anklicken werden, also ohne das Rich Snippet. Es ist also von Vorteil, ein positives Voting zu haben, da sich die Klickrate deutlich erhöht. Aus diesem Grund manipulieren viele Webmaster ihre Votings oder gleich die ganze Micro-Data-Übermittlung.

Wir suchen nach Rich Snippets-Spam
Wenn man Googles Suche benutzt und speziell nach positiv bewerteten Seiten sucht, kommt man aus dem Staunen nicht heraus. Vor allem, wenn Google positiv bewertete Seiten anzeigt, man als Besucher dann jedoch kein Bewertungssystem präsentiert bekommt, macht dies einem mehr als stutzig. Auch Startseiten werden oft manipuliert. Wenn der Webmaster die Bewertungen der einzelnen Artikel heranzieht und daraus einen Mittelwert bildet, ist dies zwar nicht richtig, aber immerhin hat die Bewertung eine Grundlage. Hier sehen wir nun also auch, warum das WordPress Plugin GD Star Rating für die Startseite keine Rich Snippets im HTML-Code einbindet.

<span class="rating">
<span class="average">5.0</span> out of 
    <span class="best">5</span> based on <span class="votes">2</span> ratings 
    <span class="summary"></span>
</span>

Sicherlich sind sie schon jedem Google-Benutzer aufgefallen: Die Sterne in Googles Treffer-Anzeige, die anzeigen, wie gut ein Artikel bewertet wurde, oder wie viel Kommentare samt Bewertung ein Händler oder ein Produkt vorzuweisen hat.
Mit Hilfe der sogenannten „Google Rich Snippets“ gibt Google den Webmastern die Möglichkeit, weitere Details einer Webseite Google mitzuteilen. Wenn Google dann diese Angaben verarbeitet und in den SERPS anzeigt, steigt natürlich die Chance, dass ein Suchmaschinennutzer die Seite über die Maschine anklickt, denn die bunten Sterne laden förmlich zum Klicken ein.

WordPress Artikel-Bewertung per Rich Snippet
Die Möglichkeit, einen Artikel zu bewerten, ist nicht gerade neu. Der Gedanke, dass Benutzer Artikel bewerten und der Autor somit ein Feed-Back zur Qualität erhält, ist leider aufgrund von Spam (siehe auch Kommentar-Spam) von vielen Webmastern schnell at acta gelegt worden. Auch wenn über das Rating keine Links generiert werden können, so kann ein nicht wohlwollender Besucher schnell einmal alle Artikel schlecht bewerten. So hat sich bisher die Frage nach dem Sinn gestellt.

Inzwischen ist eben durch die Möglichkeit, diese Daten auch Google mitzuteilen, ein neuer Hype, der „Rating-Star-Hype“, entstanden. Zwar sind die Probleme mit „Fake-Bewertung“ in nicht gelöst, doch zu verlockend erscheint es den meisten SEOs, so ihre Artikel zu „pushen“.

Googles Micro-Data Format
Rating-Pluins für WordPress gibt es unzählige. Wir suchen eines, das auf jeden Fall Googles Micro-Data Format beherrscht, denn wir möchten ja schließlich unsere Webseite mit Rich Snippets anreichern.

Meine Auswahl fiel auf „DG Star Rating“. Die Installation dieses WordPress-Plugin ist gewohnt einfach. Sofort werden Rating-Stars unterhalb der Artikel angezeigt. Dennoch sollten die sehr umfangreichen Einstellungen durchgearbeitet und gegebenenfalls angepasst werden.

Ich persönlich reduziere die Bewertung von zehn auf fünf Sterne. Bei der Gelegenheit passe ich den Text über der Abstimmbox an („Gefällt Ihnen dieser Artikel …“) und passe auch die AJAX-Warteschleife an.

WordPress Plugin GD Star Rating auf Deutsch
Während fast die gesamten Einstellungs-Masken des Plugins GD Star Rating auf Deutsch übersetzt wurden, hapert es bei der Anzeige im Artikel. Hier wird der Leser nach wie vor in englischer Sprache gegrüßt. Um dies zu ändern, müssen einige Dateien manuell geändert werden. Da wir aktuell kurz vor dem 2.0-Release (angekündigt: Ende März 2012) stehen, nehme ich diese Änderungen nicht (mehr) vor in der Hoffnung, dass dieses Problem in der kommenden Version behoben ist.

Rich Snippet auf der Startseite
Aktuell liefert das WordPress Plugin GD Star Rating keine Rich-Snippets für die Startseite aus. Über das Google-RichSnippets-Tool  kann dies geprüft werden. Die einzelnen Artikel erhalten jedoch wie gewünscht die Google Micro-Data. Wenn man einige Sekunden darüber nachdenkt, macht dieses Verhalten auch Sinn.

Plugin GD Star Rating und der Cache
Meine Wahl fiel nicht nur durch das einfache Einbinden auf GD Star Rating. Viel wichtiger für mich war, dass das WordPress-Plugin auch mit CACHE zurechtkommt. Aus Gründen der Performance sollte man einen gutbesuchten WordPress-Blog unbedingt cachen. Allerdings macht es wenig Sinn, dass das Abstimmungsverhalten durch den Cache verfälscht wird. Der Entwickler von GD Star Rating hat dieses Problem erkannt und in seiner Entwicklung auch optimal gelöst.

Das beliebte Content-Management-System lebt von Plugins. Und so ist die Frage nach einem WordPress-Plugin für die Anzeige von YouTube-Videos natürlich berechtigt, auch wenn man diese Videos über einem embed-Tag recht leicht selbst in einen Artikel einbinden kann.

Plugin: WP YouTubeLyte
Für das einfache Einbinden von YouTube-Videos und Audio-Dateien empfehle ich das WordPress-Plugin „WP YouTube Lyte“ von Frank Goossens. Dieses Plugin ist stabil und bewährt. Die Installation ist gewohnt einfach, Probleme sind bei mir bei keiner Installation aufgetreten.

Wie wird ein YouTube-Video dann in WordPress eingebunden?
Das Einbinden eines YouTube-Videos in WordPress ist dank des PlugIn sehr einfach. Ein YouTube-Link sieht bekanntermaßen so aus:
http://youtu.be/BLABLAbmFUObGI

Um aus einem Link schon das gewünschte Video anzuzeigen, wird einfach an gewünschter Stelle im Text die URL zum Video eingebunden. Die URL muss jedoch verändert werden. Aus „http“ wird manuell „httpv“ gemacht. Der Rest der URL bleibt unverändert. Das Plugin „WP YouTubeLyte“ ersetzt nun die „httpv“-URL und zeigt nun das YouTube-Video samt Vorschaubild an.
ACHTUNG: Es ist einfacher, als gedacht. Lediglich die URL in den Text einbinden und um das „v“ ergänzen. Aus der URL keinen Link oder ähnliches machen!

Das Plugin hat jedoch einen Nachteil: Es zeigt die Videos nur im Content-Bereich an. Wer Videos auch in der Sidebar anzeigen möchte, muss auf ein anderes Plugin zurückgreifen.

YouTube-Videos in der Sidebar anzeigen
Der Wunsch, auch einige Vorschauvideos zuzusagen als Link in der Sidebar anzuzeigen, liegt nahe. Mit dem Plugin „WP YouTubeLyte“ ist dies leider nicht möglich. Empfehlen kann ich das Plugin „Video Sidebar Widgets” von Denzel Chia, wenn ich auch nicht rundum zufrieden mit dem Plugin bin.
Die Installation ist ebenfalls ohne Probleme machbar. In den Design-Widgets findet man nach der Installation die Widgets „Video Sidebar Widget“ und „Random Sidebar Widget“, die sich per Drag-and-Drop beispielsweise in den „Primären Widget-Bereich“ ziehen lassen.

Video Sidebar Widget: Anzeige eines bestimmten YouTube-Videos in der Sidebar
Zieht dieses Widget in den Widget-Bereich. Die Konfiguration ist einfach. Öffnet das Widget, wählt die Video Source aus (beispielsweise „YouTube“) und gebt die VideoID an. Die ID ist bei YouTube der kryptische Wert der URL, also beispielsweise „BLABLAbmFUObGI“.
Die Breite und die Höhe des Videos (Anzeige) muss angegeben werden. Eine Beschreibung (Video Caption) kann angegeben werden. Auf ein Fehler im Plugin hierzu komme ich später noch zu sprechen. Als letztes kann noch der Wert „Auto Play“ auf „No“ gestellt werden.
Dieses Widget kann mehrmals in die Sidebar „gezogen“ werden mehrere verschiedene Videos in der Sidebar anzuzeigen.

Random Sidebar Widget: Anzeige EINES „zufälligen“ Videos
Dieses Widget dient dazu, ein Video in der Sidebar anzuzeigen. Zur Auswahl können jedoch bis zu fünf verschiedene Videos definiert werden. Wenn also mehrere Videos zur Auswahl stehen, jedoch nur eines davon zufällig angezeigt werden soll, ist dies das Widget Eurer Wahl. Die Definition des Widgets an sich ist dem „Video Sidebar Widget“ ähnlich. Es werden grundlegende Dinge wie die Überschrift und Größe an einer Stelle eingegeben und bis zu fünf verschiedene Videos definiert.

Link in der Video Caption (Bug):
Es macht natürlich Sinn, unterhalb des Videos auch einen Link anzuzeigen. Beispielsweise um einen Link auf eine Unterseite mit dem Video zu generieren. Dies kann per HTML in der Textbox „Video Caption“ erfolgen. Leider hat der Programmierer dieses Plugins dies so nicht vorgesehen. Der Link funktioniert, jedoch ist die Anzeige in Widget nicht richtig, wie auf den Bildern zu sehen.

WordPress ist und bleibt das Content-Management-System der ersten Wahl. Es ist umsonst, sehr gut entwickelt und wird ständig weiter gepflegt. Die Installation ist einfach, geht schnell und man kann relativ schnell loslegen.

Jedoch wer seinen Webserver immer im Auge hat wird feststellen, dass WordPress mit der Zeit immer langsamer wird. Es wird speicherhungrig und die Performance sinkt. Hier ist nicht unbedingt die Schuld bei den Entwicklern zu suchen. Es ist vielmehr wie bei einem Auto. Nur fahren und ab und zu tanken langt nicht. Mit den Jahren muss man auch mal eine Inspektion machen und vielleicht auch überlegen, ob man den Dachgepäckträger wirklich braucht (und auch mal den Kofferraum ausmisten). So ist es auch mit WordPress. Man neigt gerade am Anfang dazu, dem System jedes Plugin zu spendieren (ob sinnvoll oder nicht) und man macht sich auch um die Datenbank keine großen Gedanken. Und dies rächt sich, irgendwann.

Hier meine Tipps für eine Performance-Verbesserung eines WordPress Blogs

1. WordPress und seine Plugins stets aktuell halten. Man muss nicht gleich am Erscheinungstag ein Update machen, doch wenn ein Update vorhanden ist und man Zeit hat: installieren.
2. Unnötige Plugins entfernen. Jedes Plugin benötigt für seine Arbeit CPU und Speicher. Teilweise führen die Plugins mehr oder weniger aufwändige Datenbankabfragen durch, die die Performance deutlich nach unten ziehen. Daher alle Plugins entfernen, die nicht wirklich benötigt werden.
3. Die Datenbank im Auge behalten. Eventuell von Hand ab und an die Datenbank auf Inkonsistenzen prüfen und die Tabellen optimieren. Als Tipp kann hier das Plugin “WP-Optimize“ eingesetzt werden.
4. Die Bilder ebenfalls prüfen. Ist die Auflösung optimal, können die Bilder verkleinert werden? Zu empfehlen sind hier auch Online-Dienste wie smushit.com oder andere.
5. Wer wirklich hohe Zugriffe aus seinem Server hat, sollte sich Gedanken über einen Cache und eine Komprimierung machen. Ein Howto zu diesen Themen habe ich im Artikel „WordPress mit Cache beschleunigen: Plugin Quick Cache“ und „GZip: Webseite beschleunigen (Page Speed) durch Kompression“ veröffentlicht.
6. Unnötige Artikel löschen. Hier sind die Revisionen gemeint, die WordPress automatisch anlegt. Dieses Thema habe ich im Artikel „WordPress beschleunigen – Revisionen einschränken“ und „WordPress Artikel mittels Plugin “Delete Revision“ löschen bereits ausführlich behandelt.
7. Java-Script oder JQuery-Bibliotheken nicht vom eigenen Server nachladen, sondern von externen Quellen. Der Grund liegt einerseits an der meist besseren Serveranbindung von Google- oder Amazon-Servern an das Internet, als das dies der eigene Serverhoster bereitstellen kann, andererseits werden diese Standard-Bibliotheken dann auch gerne gecached, was ebenfalls zu einem nicht zu verachtenden Performance-Gewinn führen kann. Und letztlich spart man auch noch eine Menge Traffic. Wer sich mit dem Thema weiter beschäftigen möchte, findet im Artikel „Drei Gründe, warum wir Google JQuery für uns hosten lassen sollen“  (Englisch) weitere Informationen.

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„.