wp_comments in der sich aktuell 1.132 Kommentare befinden, ist dagegen noch nicht mal 1 MB groß und auch wp_posts und wp_postmeta belegen zusammen weniger als 5 MB. Insgesamt verbraucht WordPress also eigentlich recht wenig MySQL Datenbank Speicherplatz.

Eine kurze Google-Suche offenbarte dann, dass die Version 2.5.1 vom Akismet Plugin (welches Kommentar-Spam bekämpfen soll) die wp_commentmeta Tabelle anscheinend nicht mehr richtig geleert hat. Dieser Fehler sorgte dafür, dass die Metadaten von Kommentaren selbst dann nicht gelöscht wurden, wenn die entsprechenden Kommentare schon gar nicht mehr vorhanden waren. Und selbst obwohl ich zwischenzeitlich auf “Antispam Bee” von Sergej Müller gewechselt bin, blieben die alten Einträge von Akismet noch erhalten.

In einem weiteren Thread auf wordpress.org sind einige Lösungsvorschläge gemacht und erklärt worden, wie man die Datenbank und die wp_commentmeta Tabelle selektiv bereinigen kann. Der Großteil der Einträge sollte aus “akismet_result”, “akismet_history”, “akismet_as_submitted”, “akismet_user_result” oder “akismet_user” bestehen, da Akismet offenbar drei Einträge in der wp_commentmeta Tabelle für jeden Kommentar anlegt und sogar fünf Einträge für jeden manuell als Spam markierten Kommentar. Um die Einträge zu finden, die sich auf Kommentare beziehen, die längst gelöscht wurden, kann man in phpMyAdmin Folgendes ausführen:

select count(*) from wp_commentmeta where comment_ID not in
(select comment_ID from wp_comments)

delete from wp_commentmeta where comment_ID not in
(select comment_ID from wp_comments)

Alternativ kann man die wp_commentmeta Tabelle auch einfach komplett leeren. Dies lässt sich entweder ebenfalls über phpMyAdmin bewerkstelligen:

select count(*) from wp_commentmeta where meta_key like ‘%akismet%’

delete from wp_commentmeta where meta_key like ‘%akismet%’

oder man benutzt einfach ein Plugin, wie zum Beispiel “WP-DBManager” von Lester Chan, das auch für Backups und das automatische Optimieren der Datenbank sinnvoll ist. Nach der Installation und Aktivierung, findet sich der Punkt “Database” in der linken Dashboard-Spalte. Dort kann man dann den Unterpunkt “Empty/Drop Tables” auswählen und bei wp_commentmeta “Empty” markieren. Während “Drop” dafür sorgt, dass die ganze Tabelle gelöscht wird, leert “Empty” nur die Inhalte der Tabelle und lässt sie bestehen.

Selbstverständlich sollte man vor allen Änderungen an der Datenbank ein Backup anlegen, was dank WP-DBManager aber leicht und schnell möglich ist.

Seit ich die wp_commentmeta Tabelle dieses Blogs bereinigt habe, ist die Größe nicht mehr übermäßig angewachsen, da der Fehler bei den neuen Versionen des Akismet Plugins behoben wurde. So habe ich nicht nur 70 Megabyte Speicherplatz in meiner MySQL Datenbank gespart, sondern auch die Größe meiner Backups signifikant verringert.

Aufgrund dieses Vorfalls habe ich mir aber vorgenommen, die Tabellen und den Speicherverbrauch der Datenbank nun wenigstens einmal pro Quartal zu überprüfen. Im Normalfall verbraucht WordPress selbst nur wenig Speicherplatz, doch insbesondere Statistik-Plugins oder Plugins mit eingebauter Statistikfunktion(!) häufen schnell größere Datenmengen an, die regelmäßig bereinigt werden sollten.

Je erfolgreicher das eigene Blog ist, desto stärker ist die Notwendigkeit zur Optimierung wahrscheinlich sowieso zu spüren. Das oft eingesetzte Caching Plugin W3 Total Cache wirbt sogar damit, dass große und bekannte WordPress Blogs wie mashable.com, webdesignerdepot.com oder tutsplus.com darauf setzen, um die Auslieferung der eigenen Seiten zu beschleunigen und die Last der Webserver zu reduzieren. Daneben gibt es natürlich noch eine ganze Reihe weiterer Caching Plugins, die ich nun (nach der Anzahl der Downloads im WordPress Plugin Verzeichnis geordnet) vorstellen will:

WP Super Cache (2,862,158 Downloads)

WP Super Cache ist eine Weiterentwicklung des “alten” und mittlerweile anscheinend nicht mehr verfügbaren WP-Cache Plugins von Ricardo Galli Granada. Da WP Super Cache vom Automattic Mitarbeiter und WordPress-Mitentwickler Donncha O Caoimh programmiert wurde, kann man davon ausgehen, dass es die Möglichkeiten von WordPress so gut wie möglich ausnutzt und besonders kompatibel ist.

Während WP-Cache die einzelnen Seiten “nur” gecacht hat und sie so ohne Zugriff auf die Datenbank ausliefern konnte, spart WP Super Cache auch das Laden der PHP engine, da es statische HTML Dateien generiert. Diese können direkt abgerufen werden, ohne PHP Skripte laden und ausführen zu müssen.

W3 Total Cache (939,279 Downloads)

Auch W3 Total Cache erstellt statische HTML Dateien, bietet darüber hinaus aber noch unzählige weitere Möglichkeiten wie zum Beispiel die Kompression und das Zusammenführen von JavaScript und CSS Dateien, Datenbank Caching, Feed Caching, Suchergebnis Caching sowie die Möglichkeit Dateien in ein eigenes (zum Beispiel cdn.domain.tld) oder Drittanbieter (zum Beispiel Amazon S3, Rackspace, MaxCDN, etc.) Content Delivery Network (CDN) auszulagern.

Natürlich bedeutet das viele Einstellungsmöglichkeiten, aber man kann sich gut Schritt für Schritt an die einzelnen Punkte “herantasten” und erst Mal mit der Standard-Konfiguration arbeiten, ohne gleich alles direkt am Anfang einrichten zu müssen.

Quick Cache (246,898 Downloads)

Wie der Name schon erahnen lässt, möchte Quick Cache den Nutzern komplizierte Menüs und langwierige Einrichtungsprozeduren ersparen. Das Interface ist daher einfach und übersichtlich gehalten. Zu jeder Einstellungsmöglichkeit findet sich ein Text der die Optionen und ihren Nutzen erklärt. Erstaunlicherweise steht in der Beschreibung von Quick Cache, dass es komplett in PHP arbeitet und weder die “mod_rewrite engine” noch den Browser Cache benötigt. Angeblich sendet es sogar einen “no-cache header” um nicht eingeloggten Nutzern gecachte Dateien auszuliefern, während eingeloggte Nutzer dynamisch generierte Seiten mit aktualisierten Kommentaren etc. sehen.

DB Cache Reloaded Fix (38,197 Downloads)

DB Cache Reloaded Fix ist ein neueres Plugin, welches das nicht mehr weiter entwickelte “DB Cache Reloaded” von sirzooro für WordPress 3.1 kompatibel gemacht hat. Laut den Versprechen des Entwicklers soll es noch besser als WP-Cache oder WP Super Cache sein (“Forget about them”), weil es nur Datenbank Abfragen cacht und dadurch schneller sein und weniger Speicherplatz für gecachte Dateien verbrauchen soll.

Hyper Cache Extended (10,288 Downloads)

Auch Hyper Cache Extended ist eine Weiterentwicklung eines älteren Plugins (Hyper Cache) und spezialisiert sich laut der Beschreibung auf Nutzer mit kleineren oder langsameren Hosting-Paketen (Prozessor und MySQL). Während die meisten Plugins auf Linux-Server optimiert sind, unterstützt Hyper Cache Extended auch Microsoft IIS Webserver. Caching für Mobile Endgeräte soll im Zusammenspiel mit WP-PDA funktionieren. Trotz der weitaus geringeren Download-Anzahl gegenüber den Caching-Schwergewichten hat Hyper Cache Extended einen festen Kern von zufriedenen Nutzern und Unterstützern, sodass ein Test des Plugins durchaus lohnenswert erscheint.

WP File Cache (9,343 Downloads)

WP File Cache wurde zuletzt am 16.12.2010 aktualisiert, weshalb ich persönlich schon von einer Nutzung absehen würde. Aufgrund der anderen Herangehensweise an das Thema Caching wird es jedoch trotzdem ab und zu empfohlen. Laut dem Entwickler liegt der Vorteil von WP File Cache darin, dass nicht ganze Seiten sondern nur weniger oft geänderte Teile einer Seite gecacht werden. Dadurch bleibt der Blog dynamisch, aber die Zahl der Datenbankabfragen kann reduziert werden. Um optimal zu funktionieren, muss WP File Cache durch Nutzung der wp_cache_xxx() API Funktionen jedoch gezeigt werden, welche Teile gecacht werden sollen. Die entsprechenden Aufrufe müssen also im Theme oder in den Plugins vorhanden sein, sonst ist wenig Nutzen zu erwarten.

Cachify (7,247 Downloads)

Cachify ist das Caching Plugin des in Deutschland recht bekannten und beliebten Entwicklers Sergej Müller, der auch WordPress Antivirus (206,461 Downloads) und die Akismet-Alternative Antispam Bee (153,602 Downloads) entwickelt hat. Der Fokus liegt auf Simplizität und Funktionalität, es gibt also viel weniger Einstellungsmöglichkeiten als bei WP Super Cache oder W3 Total Cache und damit auch weniger Gelegenheiten für eventuelle “Verschlimmbesserungen”. Cachify prüft beim Aufruf einer Blogseite ob diese bereits im Cache als statischer Quelltext vorliegt und liefert dann die zwischengespeicherte Version aus. Falls nicht, wird die Seite in der Datenbank gespeichert. Hier liegt wohl der Haupt-Unterschied zu den anderen Caching-Plugins, die meist auf statische HTML Seiten setzen, die auf der “Disk” gespeichert werden.

WP Green Cache (1,480 Downloads)

WP Green Cache ist die Weiterentwicklung des ehemaligen WP Simple Cache Plugins vom türkischen Entwickler Ozgur Koca. Während der neue Name dadurch begründet wird, dass durch Caching Ressourcen gespart und Emissionen reduziert werden können (= Green), war der alte Name aussagekräftiger. Die Hauptfunktion ist nämlich einfach statische HTML Seiten anstatt dynamisch generierter Inhalte auszuliefern. Die sonstigen Einstellungsmöglichkeiten beschränken sich auf die Zeitangaben, wie lange gecachte Versionen vorgehalten und wann sie neu erstellt werden sollen (= Simple).

Wann lohnt sich ein Caching Plugin?

Die Frage ob, wann und welches Caching Plugin sich lohnt ist schwierig zu beantworten, da fast jeder Blogger andere Umstände vor sich hat. Die einzelnen Webhosting-Unternehmen setzen verschiedene Server mit verschiedenen Betriebssystemen und verschiedenen Einstellungen ein. Man kann also nie gemeinsame Ausgangsbedingungen erwarten, die einen genauen Vergleich möglich machen. Wer des Englischen mächtig ist, findet hier einen Test zwischen WP Super Cache, W3 Total Cache und Hyper Cache von Stephen Cronin.

Sein Ergebnis war, dass W3 Total Cache die geringsten Ladezeiten auf der Server-Seite hat und am wenigsten Ressourcen verbraucht, während Hyper Cache die schnellsten Ladezeiten auf der Client-Seite, also für die Besucher, hat.

Einen ähnlich ausführlichen Test, der die Frage nach dem besten Caching Plugin zu beantworten versucht, findet man auf tutorial9.net. Erstaunlicherweise kommt als Ergebnis eine Empfehlung für die Kombination aus Hyper Cache und DB Cache Reloaded heraus, während W3 Total Cache auch wieder als die nächst beste Alternative genannt wird.

Tools zur Überprüfung der Ladezeit

Das bekannteste und meist-empfohlenste Tool zur Überprüfung der Ladezeit von Webseiten ist wohl Google Page Speed. Es ist als Browser-Plugin für Firefox und Chrome verfügbar, wurde aber auch in Webpagetest.org, Show Slow sowie die Google Webmaster Tools und über die API selbst in W3 Total Cache integriert.

Möchte man die Performance der eigenen Webseite über einen längeren Zeitraum hinweg kontinuierlich verfolgen, bieten sich Tools wie Pingdom, Site24x7.com, mon.itor.us, 100pulse oder UptimeRobot an.

Fatal error: Call to undefined function is_rtl() in /wp-includes/general-template.php on line 2102

Eine kurze Google-Suche brachte zum Glück gleich die Lösung zutage: Die Plugins müssen deaktiviert und einzeln wieder reaktiviert werden.

1. Da man aufgrund der Fehlermeldung nicht mehr ins Admin Dashboard und dort ins Plugin-Menü kommt, muss man sein FTP-Programm nutzen, um den Plugin Ordner im Verzeichnis “wp-content” umzubenennen. Anstatt plugins kann man ihn beispielsweise “old-plugins” nennen. Dadurch werden automatisch alle Plugins deaktiviert
2. Nun sollte das Login ins Admin Dashboard wieder möglich sein und das Update kann fertiggestellt werden
3. Der im ersten Schritt veränderte Ordnername kann jetzt wieder in “plugins” geändert werden und die deaktivierten Plugins können im Backend einzeln wieder reaktiviert werden, um das “kaputte” Plugin ausfindig zu machen
4. Wahrscheinlich tritt der Fehler nach dem Aktivieren des betroffenen Plugins wieder auf, aber da es dadurch erkannt wurde, kann es einzeln deaktiviert werden, indem der Ordnername des Plugins abgeändert wird

Falls es sich um ein Problem mit einem Theme handelt, können die entsprechenden Schritte natürlich auch mit dem Theme-Ordner durchgeführt werden. Normalerweise wird dann automatisch auf das Standard-Theme “Twenty Eleven” umgeschaltet.

Die sonstigen Konditionen können sich wirklich sehen lassen, denn die Domain wird sogar auf den eigenen Namen registriert und nicht auf den des Anbieters. Zusätzliche Kosten muss man ebenfalls nicht befürchten, denn es werden keine Einrichtungskosten fällig und solange man das Blog aktiv nutzt (also neue Beiträge schreibt) bleibt das Paket komplett kostenlos.

Der Datentransfer ist durch eine Flatrate abgedeckt und es lassen sich auch unendlich viele E-Mail-Adressen mit Posteingangs- und Postausgangsserver in Form von pop.eigene-domain.de und smtp.eigene-domain.de einrichten (1 GB Speicherplatz für IMAP- und POP3 Post).

Sollte man irgendwann doch einmal faul werden und nicht mehr Bloggen aber die Domain behalten wollen, wird das Paket auf den “Mail Domain”-Tarif umgestellt. Dort kostet die .de-Domain 97 Cent pro Monat, also knapp 12 Euro pro Jahr.

Die aktuellen Kundenbewertungen von prosite, zum Beispiel bei webhostlist, sind durchweg positiv. Man sollte bei weiterem Googlen und Lesen von Erfahrungsberichten auf Ciao oder dooyoo allerdings beachten, dass die Speedbone GmbH die Marke und Domain prosite.de erst im Jahr 2002 von einer anderen Firma übernommen hat und somit alle älteren Bewertungen nicht für das gleiche Unternehmen gelten! Anscheinend hatte der vorherige Betreiber nämlich nicht so einen guten Ruf und deshalb finden sich noch alte negative Berichte.

Kostenpflichtige Alternativen

Wer kostenlosen Angeboten nicht vertraut und lieber selbst für Domain und Webspace bezahlt, bekommt bei prosite 1 GB Webspace mit einer MySQL Datenbank auch für 2,95 Euro pro Monat bei 6 Monaten Laufzeit.

Für dieses Blog nutze ich ein WebPack® von Hosteurope, das es mit 2 GB Speicherplatz und 2 MySQL-Datenbanken aktuell 3 Monate lang kostenlos gibt. Danach werden 3,49 Euro pro Monat fällig, allerdings muss man sich 12 Monate lang binden und 14,99 Euro Einrichtungsgebühr zahlen.

Eine recht günstige Alternative stellt das Angebot von One.com dar, bei dem man 3 GB Webspace mit einer MySQL Datenbank für 14,28 Euro pro Jahr bekommt. Ab dem zweiten Jahr werden 1,49 Euro pro Monat fällig, also 17,88 Euro pro Jahr. Bisher hatte One.com teilweise den Ruf, die Server stärker als andere Hoster zu belasten, wodurch manche Kunden lange Ladezeiten bemängelt haben. Im letzten Newsletter (Dezember 2010) berichtete One.com allerdings, dass Sie “eine umfassende Aktualisierung der Server-Systeme” vornehmen und “anschliessend alle Webseiten im Durchschnitt sieben mal schneller sein werden, als sie es heute sind”. Außerdem wurde der PHP Safe Mode deaktiviert, was zu größerer Flexibilität führen soll.

Zum Versprechen, dass die Server schneller geworden sein sollen und sich die Ladezeiten verkürzt haben, kann ich folgende Grafik von Site24x7.com präsentieren, die die Response Zeit eines meiner Blogs bei One.com anzeigt:

Wie man sieht, sind die Werte seit dem 08. Dezember tatsächlich stark gesunken.

Als dritte und ebenfalls sehr preiswerte Alternative zu Prosite kann ich noch Alfahosting empfehlen. Ein WordPress Blog lässt sich dort ab dem sogenannten “Starterpaket” betreiben, das 500 MB Speicherplatz, 2 MySQL Datenbanken sowie eine .de-Domain ab 1,29 Euro pro Monat bietet. Wenn man bedenkt, dass man oft allein für die Domain 1 Euro pro Monat zahlt, ist das recht günstig und die Performance sowie der Kundenservice stimmen bei Alfahosting auch noch, was ich persönlich fast als wichtiger als den Preis empfinde.

Ich muss gestehen, dass mir die Backup-Erstellung lange Zeit auch viel zu aufwändig erschien und ich keine große Lust hatte nach geeigneten Lösungen dafür zu suchen. Erst beim Einsatz des “WP-DBManager”-Plugins von Lester Chan bin ich zufällig darauf gekommen, dass man sich damit auch automatisch Backups an seine E-Mail Adresse schicken lassen kann. Nutzt man dann noch GMail und profitiert von fast 7.5 GB kostenlosem Speicherplatz, ist das Datenbank-Backup schon fast in trockenen Tüchern.

Durch einen Beitrag auf Yoast.com (und die Kommentare darauf) bin ich allerdings auf noch viel ausgeklügeltere Lösungen aufmerksam geworden, die auch Themes und hochgeladene Bilder sichern.

Yoast selbst empfiehlt das “Online Backup for WordPress”-Plugin von Backup Technology. Die englische Firma bietet das Plugin und 50 MB Speicherplatz auf ihren Servern kostenlos an. Sehr wahrscheinlich soll durch die Berichte der Blogger und den entstehenden Buzz das restliche “Backup-Geschäft” der Firma gefördert werden, aber das ist bei einer kostenlosen Lösung ja durchaus legitim!

Geheimniskrämer und Blogger mit Datenschutz-Bedenken können ihre Backups sogar DES, AES128 or AES256 verschlüsselt speichern lassen und wie man auf dem Screenshot sieht, ist das Backend sehr übersichtlich und ansprechend gestaltet.

In den Kommentaren wurde meiner Meinung nach aber sogar noch auf ein besseres Backup-Plugin hingewiesen: Automatic WordPress Backup. Diese Lösung speichert neben der WordPress MySQL Datenbank auch Themes, Plugins und Uploads, sodass man im Falle eines Falles das gesamte Blog wiederherstellen kann!

Da Amazon S3 als Speicher genutzt wird erfordert das ganze jedoch auch etwas mehr Aufwand bei der Einrichtung und ist nicht ganz kostenlos. Andererseits: Bei 0,15 USD pro GB und 0,01 USD pro 1.000 PUT, COPY, POST oder LIST Abfragen kann man nicht wirklich meckern und sollte der Bequemlichkeit und Sicherheit Vorzug geben!

Wie man das ganze einrichtet, wird im folgenden Video gezeigt:

Click here to view the embedded video.

Eine dritte und ebenfalls sehr attraktive Möglichkeit ist die Nutzung von www.backupify.com. Das interessante an Backupify ist, dass man nicht nur WordPress Blogs sichern kann, sondern auch seinen Twitter-, GMail-, Picasa-, Flickr- oder Facebook-Account! Aktuell gibt es sogar 2000 MB Speicherplatz kostenlos. Falls man wirklich so viel Gefallen an der Lösung findet, dass man mehr als sein Blog sichern will und den Speicherplatz erweitern muss, gibt es zwei kostenpflichtige Optionen. 10 GB kosten sehr moderate 39,95 US-Dollar pro Jahr (ungefähr 30 Euro) und 25 GB gibt es für 59,95 USD.

Das WordPress Plugin von Backupify findet sich momentan leider nur auf der Webseite selbst und noch nicht bei WordPress.org.

Foto: © SXC.hu/Leon Lai

Hat man vergessen vor dem automatischen Update die Plugins zu deaktivieren, erscheint erst einmal wieder die Fehlermeldung: “Fatal error: Out of memory (tried to allocate 2591173 bytes) in /wp-includes/http.php on line 1331”.
Ein Hinweis darauf, dass bei 1&1 trotz etwaiger anderslautender “WP_MEMORY_LIMIT”-Einstellungen das effektiv nutzbare PHP memory limit nur bei 32 MB liegt.

Ist diese einfache Hürde überwunden wartet aber gleich die nächste Fehlermeldung:

The Update cannot be installed because WordPress 2.9 requires MySQL version 4.1.2 or higher. You are running 4.0.27.
Die Installation ging schief.

Nach etwas Googeln findet man schnell heraus, dass viele langzeitige 1&1-Kunden eine MySQL Datenbank mit veralteter Version 4 nutzen und WordPress 2.9 aber unbedingt eine neuere Version erfordert. Dies ist zwar kein Hindernis für das Update, aber es erfordert ein paar umfangreichere Schritte. Grundsätzlich sieht die Lösung so aus:

1. “Alte” MySQL 4 Datenbank sichern
2. Neue MySQL 5 Datenbank anlegen
3. Backup der alten Datenbank einspielen
4. WordPress auf Version 2.9 updaten

Nutzt man jedoch “nur” ein 1&1 Homepage Perfect Paket wie ich, kann man aber nur eine einzige MySQL-Datenbank anlegen und muss zum erstellen der neuen mit Version 5 erst die alte mit Version 4 löschen. Dazu sollte man 100% sicher sein, dass das Backup korrekt und funktionsfähig ist, sonst sitzt man nach dem Löschen der alten Datenbank auf einem Haufen Datenmüll.

Die Anleitung von 1&1 “Migration Mysql 4.0.25 zu 5.0.16” ist leider auch nicht besonders hilfreich und das manuelle Exportieren über das 1&1 Interface hat bei mir auch nicht besonders gut funktioniert. Bei Blogs die schon länger bestehen, gibt es ja leider immer wieder Probleme mit den verschiedenen Zeichensätzen latin und UTF-8.

Ein Trick sollte sein, dass man das Backup der Datenbank in Notepad kopiert und im “Speichern-unter”-Dialog bei Codierung “UTF-8” auswählt.

Bei einer anderen Datenbank hatte ich damit schon mal Erfolg, aber es geht noch einfacher!

1. MySQL 4 Datenbank sichern

Ich empfehle für diesen Schritt das “WP-DBManager”-Plugin von Lester Chan einzusetzen. Die Funktionen dieses Plugins sind bei Updates wirklich Gold wert und zudem kann man damit auch sonst nützliche Sachen erledigen, wie zum Beispiel die Datenbank automatisch optimieren lassen. Es zeigt einem auch in welchen Tabellen besonders viele Daten gespeichert sind, so kann man Plugins mit besonders hohem Datenverbrauch ganz leicht identifizieren und eventuell die Performance seines Blogs verbessern.

Also, WP-DBManager herunterladen und installieren, eine Sicherung der Datenbank durchführen und die Datei auf dem eigenen Computer abspeichern. Zur Sicherheit lässt sich das Datenbank-Backup auch per E-Mail verschicken.

2. Bei 1&1 MySQL 5 Datenbank anlegen

Um die neue Datenbank anzulegen muss man sich in den 1&1 Kundenbereich (neudeutsch: “Control Center”) einloggen und dort im Menü “Homepage/ Anwendungen” den Punkt “MySQL-Datenbank” anwählen.

Im nächsten Schritt löscht man die alten MySQL 4 Datenbank. Anschließend wird einem die Meldung angezeigt “Datenbank wird gelöscht”. Zuerst habe ich mich gewundert wie lange 1&1 nun wohl für die Löschung der Datenbank braucht. Das Aktualisieren der Seite mit F5 hat leider nichts genutzt. Doch auch hier hilft Google: Das Löschen dauert Datenbank dauert genau so lange wie man braucht um sich auszuloggen und wieder neu im 1&1 Kundenbereich einzuloggen.

Nun kann man die neue MySQL 5 Datenbank anlegen:

Man sollte allerdings unbedingt beachten, dass sich dabei sowohl Datenbankname als auch Benutzername und Hostname ändern!

Diese Daten müssen also in der wp-config.php aktualisiert werden bevor es weitergehen kann.

3. Datenbank-Backup einspielen

Das “1&1 MySQL-Control-Center” bzw. die phpadmin-Oberfläche sieht bei 1&1 ebenfalls etwas anders als sonst gewohnt aus. So fand ich zuerst keinen Punkt um das Backup in die neue Datenbank einzuspielen. Die Punkte “Import” oder “Importieren” gibt es auf den auf ersten Blick nicht. Hier die Lösung:

1. Links auf den Datenbanknamen klicken
2. Oben zwischen “Struktur” und “Suche” den Reiter “SQL” anklicken
3. Datei auswählen (Maximale Dateigröße: 2.048KB) und hochladen

Mit der Backup-Datei vom WP-DBManager-Plugin hat es bei mir problemlos geklappt, die selbst erstellte Export-Datei wurde allerdings nicht angenommen. Ältere und umfangreichere Blogs mit Backups die größer sind als 2.048KB müssen die Dateien vorher auch noch in kleinere Pakete aufteilen.

Nach dem Einspielen des Backups habe ich mich erst mal ins Backend eingeloggt und geschaut ob dort irgendwelche Fehler zu erkennen sind. Danach habe ich ein paar ältere Beiträge angeschaut und kontrolliert ob alle Sonderzeichen richtig dargestellt werden oder ob sich irgendwo “Fragezeichen” eingeschlichen haben. Ist dies nicht der Fall und es hat bis zu diesem Punkt alles geklappt, sollte das Update auf WordPress 2.9 dann keine weitere Hürde mehr darstellen und problemlos funktionieren!

Die Tatsache, dass Intense Debate kürzlich von Automattic Inc., der Firma hinter WordPress übernommen wurde, hat meine Erwartungen und mein Vertrauen in die Nützlichkeit dieses Plugins noch verstärkt. Allerdings ist mir gleich aufgefallen, dass es als weiteres externes Element (JavaScript!) die Ladezeit des Blogs verlangsamt. Und nachdem ich alles eingerichtet und die verschiedenen Funktionen getestet hatte, fand ich die angeblichen Vorteile gar nicht mehr so besonders. Das “normale” WordPress Kommentar-Template lädt viel schneller (weil es statisch ist), sieht auch gut aus (wenn man ein vernünftiges Theme hat), die eigene Twitter- oder Facebook-URL können die Besucher ja auch so eingeben, für die Benachrichtigungsfunktion gibt es das bewährte “Subscribe to Comments” und eine Editierfunktion bietet “WP Ajax Edit Comments”… So sind schon alle anfänglichen Vorteile aufgewogen bzw. ausgeglichen!

Zusätzlich habe ich festgestellt, dass sich trotz angeblicher Zusammenarbeit mit Akismet mehrere Spam-Kommentare durch die Kontrolle geschlichen haben und damit meine E-Mail Inbox verstopfen. Alles zusammen hat dazu geführt, dass ich Intense Debate nun wieder deinstalliert habe und nicht mehr so schnell wieder ausprobieren werde. Da ich aber nicht so schnell aufgeben wollte, habe ich das “Konkurrenz-Plugin” Disqus installiert. Es bietet nahezu die gleichen Features, kann aber zusätzlich auch noch “Reaktionen” aus dem Web, wie Tweets oder Votes bei Digg etc. im Kommentarbereich anzeigen. Insgesamt bin ich mit der Performance und vor allem der Integration des Kommentarbereichs von Disqus zufriedener und werde es vorerst installiert lassen. Die wichtigsten Funktionen und Erleichterungen der Kommentarverwaltung werden jedoch immer noch von anderen Plugins erfüllt. Daher im folgenden eine Liste mit den für mich nützlichsten Kommentar-Plugins.

No No-Follow Plugins für WordPress

Seit geraumer Zeit werden Links in Kommentare ja auf “No-Follow” gesetzt, oder anders ausgedrückt für die Suchmaschinen entwertet, um Spam-Kommentare von “Link-Sammlern” zu reduzieren. Viele Blogger wollen allerdings ihre Kommentatoren belohnen und das “nofollow”-Attribut wieder entfernen. Meiner Wahrnehmung nach hat zuerst das “Nofollow Case by Case”-Plugin Berühmtheit erlangt und ich habe es selbst lange Zeit eingesetzt. Links von Spam-Kommentaren konnte man ganz einfach durch Anhängen von “/dontfollow” an den Kommentarlink “entwerten”. Kürzlich bin ich aber auf eine neuere und bequemere Lösung vom gleichen Autor aufmerksam geworden.

“NFCBC SEO Light” ist eine Weiterentwicklung, die Kommentaren mit weniger als 50 Zeichen den Link komplett entzieht, Kommentaren mit weniger als 170 Zeichen ein “nofollow” anhängt und alle längeren Kommentare mit einem “follow” belohnt. Da dies automatisch geschieht, muss man nur noch in den seltensten Fällen manuell eingreifen. Mit dem “NFCBC SEO Plugin Add-on” wird die Verwaltung sogar noch einfacher, weil man die Erweiterungen “/dontfollow”, “/nolink” und “/thisfollow” nicht mehr manuell an die Kommentarlinks anhängen muss, sondern dies ganz bequem über entsprechende Links in der Kommentar-Administration oder sogar den Benachrichtungs-Mails automatisch ausführen lassen kann. (“WP Ajax Edit Comments” hat übrigens auch eine Schaltfläche zum Entfernen von Links, um follow/nofollow kümmert es sich dagegen nicht!)

Noch einfacher – nach dem Prinzip “Wie Du mir, so ich Dir” – funktioniert Nofollow Reciprocity. Je nachdem wie der Kommentator follow/nofollow auf seinem Blog handhabt, wird auch sein Kommentar bearbeitet.

Automatische Benachrichtigung

Setzt man weder Intense Debate noch Disqus ein, die dieses Feature integriert haben, erfüllt “Subscribe to Comments” die Benachrichtigung per E-Mail sehr zuverlässig. Vor einiger Zeit geriet die Deutsche Blogosphäre allerdings in Aufregung, weil die Kommentar-Abos ohne “Double-Opt-In”, also ohne Bestätigung des Abonnement-Wunsches, erfolgen. Deshalb wurde “Subscribe to Double-Opt-In Comments” entwickelt, bei dem Kommentatoren vorher durch Klicken eines Links bestätigen müssen, dass sie wirklich über folgende Kommentare benachrichtigt werden wollen.

WordPress Kommentare verwalten

Möchte man die gesamten Kommentare aufräumen, bzw. von Links und Code bereinigen, hilft Comments Cleaner. Mit einem Klick lassen sich sowohl die Links im Webseite-Feld als auch in den Kommentar-Texten entfernen.

Die beliebtesten oder “aktivsten” Beiträge, wenn es um Kommentare geht, lassen sich mit Easy Popular Posts an verschiedenen Stellen auf dem eigenen Blog darstellen.

Beim Bereinigen der Datenbank von Spam-Kommentaren (und Revisionen von Beiträgen) hilft WP-Optimize. Zusätzlich kann man noch die Datenbank mit einem Klick optimieren und den “admin”-Username für zusätzliche Sicherheit abändern.

Weitere Reaktionen auf die eigenen Beiträge, wie z.B. Tweets, Diggs, etc. lassen sich (neben Disqus) auch mit BackType Connect im Kommentarbereich darstellen. Aber auch ohne das Plugin zu installieren, ist eine Anmeldung bei BackType für Blog-Schreiber und –Leser eine sinnvolle Bereicherung! Eigene Kommentare auf anderen Blogs werden gesammelt dargestellt und man kann sich gezielt über bestimmte Themen benachrichtigen lassen.

Erst wollte ich auf den altbekannten Trick zurückgreifen, einfach im Hauptverzeichnis in der Datei wp-settings.php den Wert ‘WP_MEMORY_LIMIT’ in der Zeile “define(‘WP_MEMORY_LIMIT’, ’32M’);” auf 64M hochzusetzen, aber dieser hilft nur gegen die Fehlermeldung “Fatal error: Allowed memory size of 33554432 bytes exhausted”.

Bei 1&1 liegt das Problem jedoch darin, dass das PHP memory_limit zwar theoretisch bis zu 40M zulässt, praktisch aber nur 32M nutzbar sind. Die Lösung ist dennoch vollkommen simpel: Einfach vor dem Update alle Plugins deaktivieren, dann funktioniert es auch bei 1&1!

Hinweis: Bei der Fehlermeldung “Fatal error: Allowed memory size of 33554432 bytes exhausted” ist es sinnvoll, nicht die wp-settings.php sondern die wp-config.php zu bearbeiten, denn erstere wird mit jedem Update überschrieben und dann findet sich dort beim nächsten Mal wieder der Wert 32M. Fügt man jedoch in der wp-config.php folgende Zeile hinzu, ist die Sache ein für alle mal gegessen:

define ('WP_MEMORY_LIMIT', '64M');

[UPDATE] Nachdem mir die Probleme mit dem WordPress Update bei 1&1 irgendwann dann doch einmal zu nervig wurden, habe ich mich dann vor kurzem mal unter vertrag.1und1.de eingeloggt und mein “1&1 Homepage Perfect” Webhosting-Paket gekündigt. Lustigerweise bekommt man dann angezeigt, dass man nicht so einfach aus dem Vertrag herauskommt, sondern erst Mal selbst bei 1&1 anrufen muss, damit die lieben Kundenbetreuer einem zum Bleiben überreden können. Auf Englisch nennt sich so was “Retention Call”:

Da ich zu dem Zeitpunkt wirklich die Nase voll hatte, habe ich direkt bei 1&1 angerufen mit der festen Absicht mich nicht bequatschen zu lassen. Die nette Dame hat dann wie erwartet gefragt, warum ich kündigen will und ob man denn nicht irgendwas tun kann, damit ich doch 1&1 Kunde bleibe. Ich habe ihr daraufhin gesagt, dass ich mein WordPress Blog gerne automatisch Updaten würde, was aufgrund einer “Fatal error: Out of memory”-Fehlermeldung aber nicht möglich ist…

Obwohl ich glaube, dass Sie mein Problem nicht bis ins letzte Detail verstanden hat, bot Sie mir an auf eines der neuen “1&1 Dual Hosting” Pakete zu wechseln. Normalerweise wäre diese Option im Kundencenter deaktiviert und man kann nur auf größere (und damit teurere) Pakete wechseln, aber da ich gekündigt hätte, könnte Sie mir auch den Wechsel zu kleineren oder gleichgroßen Paketen freischalten! Da ich generell mit den Ladezeiten und der Serververfügbarkeit bei 1&1 zufrieden war, habe ich meine Kündigung dann doch storniert und bin auf das Angebot eingegangen.

Das “1&1 Dual Hosting Basic” Paket kostet mich nun zwar 6,99 Euro pro Monat, aber dafür sind im Gegensatz zum alten “Homepage Perfect” Paket nun gleich 5 MySQL-Datenbanken enthalten, die jeweils bis zu 1GB umfassen dürfen. Damit hat sich das “Out of memory”-Problem beim Update endlich komplett gelöst!

Das wirklich Schlimme ist, dass man die Eindringlinge nur sehr schwer wieder los wird. Ist das Blog einmal “geknackt” können die Betrüger fast ungehindert Dateien verändern und weitere, versteckte Zugänge in Unterverzeichnissen anlegen. Da es in den letzten WordPress Versionen wieder eine Lücke gab, über die das Admin-Passwort zurückgesetzt werden konnte, wurde das Thema “WordPress Absichern” auch nochmal von Matt Mullenweg im WordPress Blog aufgegriffen. Im Folgenden habe ich die wichtigsten Punkte zusammengefasst und ein paar Plugins aufgelistet, die einen bei der Absicherung des Blogs unterstützen und dabei Helfen, schädliche Veränderungen im Auge zu behalten:

1. Updaten!
   Dieser Punkt ist für Computernutzer ja allgemein gültig – egal ob Windows, Antivir oder WordPress… Regelmäßige Updates verhindern, dass es überhaupt zu einem Schaden kommen kann. Das häufige Erscheinen neuer Versionen ist zwar mitunter etwas nervig, aber mittlerweile lassen sich WordPress Blogs ja relativ bequem über das Backend updaten, sodass man nicht mehr jedes Mal das FTP-Programm starten muss.
2. Die Secret-Keys in die wp-config.php eintragen
3. Den Datenbank-Prefix in der wp-config.php abändern
   Standardmäßig ist “wp_” voreingestellt, diesen Wert sollte man jedoch in einen beliebigen anderen Wert abändern (beispielsweise “meinblog_”)
   Bei neuen Blogs ist diese Änderung sehr einfach, bei bestehenden müssen selbstverständlich auch die Einträge in der Datenbank abgeändert werden. Mit einem entsprechenden Plugin wie WP-Security-Scan ist dies aber nicht aufwendig und nur eine Sache von wenigen Minuten.
4. Den Benutzernamen des Administrators ändern bzw. einen neuen Administrator mit neuer User-ID anlegen
   Die Änderung des Benutzernamens erfordert zwar einen Eingriff in die MySQL Datenbank, zahlt sich aber mehrfach aus, da die meisten Scripte auf den Nutzernamen “admin” ausgelegt sind. Der Wert findet sich in der “users” Tabelle:
   Noch einfacher geht es, wenn man einfach einen neuen Administrator anlegt und den alten Nutzer mit der User-ID “1” löscht. Die User-ID erhöht sich automatisch mit jedem neuen Nutzer.
5. wp-admin Verzeichnis per .htaccess schützen
   Die benötigten .htaccess und .htpasswd Dateien lassen sich hier online erstellen und herunterladen oder natürlich auch selbst erstellen (Anleitung dazu bei Frank Bueltge)

Plugins um WordPress Blogs abzusichern

Neben den bereits genannten Maßnahmen und WordPress Blogs manuell abzusichern, kann man sich auch durch Plugins unterstützen lassen. Dies ist vor allem bei der kontinuierlichen Überwachung und Kontrolle hilfreich.

• WP Security Scan
  Hilft die genannten Punkte einzuhalten und überprüft beispielweise Passwörter auf Sicherheit und Zugriffsrechte. Weiterhin versteckt es die WordPress-Version und erlaubt es einem den Datenbank-Prefix zu ändern.
• WordPress Exploit Scanner
  Scannt Dateien und Datenbank auf verdächtige Textstellen, Links und Scripte. Falls bereits ein Schaden eingetreten ist, kann man ihn so lokalisieren und Gegenmaßnahmen einleiten.
• WordPress AntiVirus
  Arbeitet ähnlich wie der “Exploit Scanner”, allerdings komfortabler durch optionale E-Mail Benachrichtigung im Fall einer Manipulation des WordPress Codes

Befolgt man alle genannten Punkte und setzt mindestens eins der drei genannten Plugins ein, ist man schon sehr gut abgesichert. Hundertprozentigen Schutz gibt es leider nicht, aber das Risiko lässt sich mit geringem Aufwand auf ein Minimum reduzieren.

Foto: © SXC.hu/simon stratford

Anscheinend kommt es weiterhin darauf an, in welchem Verzeichnis man WordPress installiert hat. Während bei diesem Blog (www.compboard.de/blog/) kryptische Fehlermeldungen erschienen, funktionierte das automatische Upgrade bei einem anderen Blog, der im Hauptverzeichnis einer Subdomain liegt, auf Anhieb völlig reibungslos.

Die Lösung ist aber relativ einfach und sieht folgendermaßen aus:

1. Bei Hosteurope ins KIS einloggen und die Administration aufrufen
2. Unter “Allgemeine Informationen” die Zeile “Pfad” kopieren (Je nachdem welches Paket ihr bei Hosteurope habt, sieht der absolute Pfad in etwa so aus: /is/htdocs/wp12345_ABCDEFG/
3. Die wp-config.php im Hauptverzeichnis des Blogs öffnen
4. Folgende Zeilen ans Ende einfügen:

   putenv("TMPDIR=/__ABSOLUTER PFAD ZUM BLOG__/wp-content/tmp");
   define('WP_TEMP_DIR', ABSPATH . 'wp-content/tmp');
   

5. Bei “Absoluter Pfad zum Blog” muss natürlich die Zeile aus dem KIS eingetragen werden. Dabei auch darauf achten, eventuelle weitere Verzeichnisse, wie z.B. /blog/ anzuhängen.
6. Fertig

Unter Umständen muss im Verzeichnis /wp-content/ noch der Ordner “tmp” angelegt und mit den Rechten 777 versehen werden.

Ähnliche Anleitungen und die selben Codezeilen findet man unter anderem in diesen Blogs. Allerdings sollte man darauf achten, dass die Anführungszeichen und Semikolons richtig gesetzt sind. Wenn die Anführungszeichen in der ersten Zeile “so” aussehen, sind sie nicht korrekt.