Soeben habe ich mein erstes Plugin für WordPress veröffentlicht. Picasa Upload ermöglicht den Upload von Bildern direkt zu Picasa Web aus dem Admin von WordPress. Zum Einsatz kommt hierbei relativ wenig Code und die Cloud Picker API von Google.

Bei GoogleWatchBlog hosten wir die meisten Grafiken und Bilder eigentlich schon immer extern bei Flickr oder Picasa Web. Da der Workflow nicht gerade sinnvoll war, habe ich mich dazu entschlossen diesen etwas zu vereinfachen. Bisher ging es so:

• Picasa Web im neuen Tab öffnen und Bild hochladen
• Bilder einfügen in WordPress laden (bei uns wurde hier direkt der Tab “von URL” geladen)
• Bild URL einfügen
• Beschreibung eingeben.
• Verlinkung setzen
• In Artikel einfügen

Nun schaut es so aus:

• Bilder einfügen in WordPress laden (direkt von URL)
• kurz warten bis Google Picker geladen ist
• Datei und Album wählen.
• Auswählen klicken
• Beschreibung eingeben.
• In Artikel einfügen.

Weggefallen ist eigentlich nur, dass laden von Picasa Web und das Setzen der Verlinkung, aber der Google Picker lädt schneller als Picasa Web.

Nachdem ich es erst einmal fest direkt in den WordPress Code geschrieben habe um zu testen, ob es überhaupt geht, habe ich mich entschlossen das als Plugin für WordPress anzubieten. In dieser ersten Version gibt es keine Optionen. Sobald man den Tab “Von URL” beim Einfügen von Bildern anklickt wird der Google Picker geladen.

Neben dem Upload von neuen Bildern kann man aber auch aus bereits vorhandenen Bildern in den Alben wählen und diese einfügen. Das eingebundene Bild ist bei seiner längsten Seite grundsätzlich 400 Pixel breit bzw. hoch und mit der Originalgröße verlinkt.

Das Plugin ist vor allem für die Nutzer von WordPress sinnvoll, die selbst regelmäßig ihre Bilder bei Picasa Web speichern oder es in Zukunft tun wollen

In den kommenden Wochen werde ich wahrscheinlich einige Optionen und auch das explizite Laden des Uploads zu Picasa integrieren.

Der Download steht über die WordPress Plugins zur Verfügung.

Getestet habe ich das Plugin mit WordPress 3.1, 3.2 sowie dem aktuellen Trunk von WordPress 3.3. Außerdem mit Chrome, Firefox und Safari.

So erhalten Bestandskunden auch wpSEO 3.0 als kostenloses Update. Ich selbst habe das Plugin hier und auf GoogleWatchBlog.de bereits in der Version 3.0 erfolgreich im Einsatz. wpSEO übernimmt die SEO-Optimierung vollkommen automatisch und ist eigentlich pflegeleicht zu bedienen. Mit der neuen Version bringt Sergej wieder neue Features mit, die die Arbeit noch einfacher machen, aber auch eine Option fällt weg, die vor allem Hobby-SEOs für genauso wichtig halten wie Links von einige Seite mit höheren Google PageRanks: Keywords für jede Seite.

Die automatische erstellt ist verschwunden. Möchte man weiterhin Keywords verwenden, kann man diese entweder manuell eintragen oder mittels eines zuschaltbaren Buttons markieren. Auf Keywords achtet Google bereits seit einigen Jahren nicht mehr und daher sind diese eigentlich unnötig. Jede Ausgabe von wpSEO braucht Zeit und Rechenleistung auf dem Server. Daher hat das Fehlen der Keywords noch einen Vorteil: Die Ausgabe der Webseite erfolgt schneller und dies ist Google ja bekanntlich auch wichtig.

Bei wpSEO gab es zwei Arten, wie die Ausgabe der SEO-Infos in die Seite eingebunden wurden: wpSEO ersetzt die vorhandenen Meta-Daten oder man verzichtet auf die Suche danach und fügt diese einfach ein. Mit der Version 3.0 sind es drei unterschiedliche Arten:

• Metadaten automatisch einfügen, vorhandene Tags ersetzen
• Metadaten automatisch einfügen, vorhandene Tags behalten
• Ausgabe der Metadaten im Template manuell anstoßen

Alle haben ihre Vor- und Nachteile: Beim ersten wird nach vorhandenen Tags geschaut und dieser ersetzt, ist aber auch am langsamsten. Beim letzten findet keine Prüfung statt und somit kann es vorkommen, dass die Daten doppelt vorhanden sind.

Hier ein Screenshot der überarbeiteten Einstellungen:

Einige weitere Features, die mit wpSEO 3.0 kommen, gibt es im Helpdesk.

Wer sich wpSEO* noch nicht angeschaut hat, kann die Testversion im uneingeschränkten Umfang für 10 Tage testen. Erst danach ist eine Lizenz nötig. Übrigens wer schon eine Lizenz erworben hat, erhält auf Anfrage Zugriff auf die Beta-Version und kann somit bei der Weiterentwicklung helfen.

Fazit: wpSEO 3.0 ist das Produkt von ständigen Tests und einer sinnvollen Weiterentwicklung. Die neuen Features bringen neue Möglichkeiten fürs SEO mit und machen so das Optimieren einer Webseite auch ohne große Kenntnisse kinderleicht.

*Partnerlink

Im Gegensatz zu anderen Caching-Plugins schreibt das Plugin die Daten nicht in einer HTML-Datei auf dem Server ab, sondern schreibt sie in die Datenbank des Blogs. Diese werden dann beim Aufrufen des Blogs aus der Datenbank gelesen. Es sind aber weiterhin insgesamt weniger Daten aus der Datenbank gelesen. Die Anzahl sinkt hier im Blog von 52 Queries auf 22. Je nach Plugins und Themes sind auch deutlich weniger Queries möglich. Sergej gibt in der Beschreibung an, dass bis zu 80% Einsparung drin sind.

Ein weiterer Vorteil von Cachify gegenüber statischem Cachen: Nutzt man ein Stats-Plugin, das seine Daten in die Datenbank von WordPress schreibt, funktioniert weiterhin. Viele andere Plugins wie WP Super Cache “verlieren” einige Statistikdaten, da hierbei nicht immer ein Zugriff auf die DB erfolgt.

Die HTML-Komprimierung löscht unnötige Kommentare aus dem Quelltext und spart so weiteren Traffic. Mit WP-Minify, das CSS und JS-Daten komprimiert, kann es zu Problemen kommen, wenn man die komprimierten Daten nicht direkt als erstes im Header haben möchte. Die Besteine <!-- WP-Minify CSS --> und <!-- WP-Minify CSS --> werden nämlich gelöscht.

Cachify ist vor allem für kleine Blogs sinnvoll, die so unnötigen Datenbank-Traffic vermeiden wollen. Mit Statify ist das Plugin übrigens kompatible. Die neuen Features in der Version 1.0 sind:

• Leerung des Cache beim Aktualisieren von statischen Seiten
• Seite mit Plugin-Einstellungen
• Inline-Dokumentation innerhalb der Optionsseite
• Ausschluss von Passwort-geschützten Seiten
• WordPress 3.2 Support
• Unterstützung der WordPress Multisite Blogs
• Umstellung auf den template_redirect-Hook (Plugin-Kompatibilität)
• Interne Code-Bereinigung

Ist ein Artikel als Entwurf gespeichert, mit einem Passwort geschützt oder wird er oben gehalten, wird dies in der Artikelliste im Admin angezeigt. Das Plugin UI Labs hinterlegt den Text farbig. Hierbei wird auf CSS3 gesetzt. So verwendet er neben gerundeten Ecken, auch Gradients und Schatten für den Text sowie die Box.

Da das Plugin die Klassen übersetzt, ist es mit dem deutschen Sprachpaket nicht gleich nutzbar. Hierzu müssen die übersetzten Klassen in die CSS Datei des Plugins übernommen. Ich habe diese hier ergänzt.

Die Informationen zu WordPress 3.2 dazu sind natürlich noch recht dürftig. Als Mindestvoraussetzung für WordPress 3.2 muss der Server PHP 5.2 sowie MySQL 5.0.15 installiert sein. Weiterhin wollen die Entwickler WordPress beschleunigen. Man will das Laden verbessern und auch beim Upgraden etwas tun.

Mit WordPress 3.0 wurde das Design TwentyTen eingeführt. Mit WordPress 3.2 soll es ein weiteres neues geben. Dieses mal wird es TwentyElven heißen. Nach derzeitigem Stand wird es auf dem Design duster passieren. Einen Link zum Download gibt es im Codex.

Ich habe es hier einmal installiert.

Direkt nach der Aktivierung des Plugins werden alle Aufrufe des Blogs gezählt. Die Statistik im Dashboard werden ungefähr alle 15 Minuten neu geladen. Hier findet man neben dem Verlauf der letzten Tage auch die Top Referrer sowie die Seiten mit den meisten Zugriffen. Eine Einstellungsseite gibt es nicht. Standardmäßig werden die Daten 14 Tage gespeichert, wer länger oder kürzer speichern will, kann über die Einstellungen direkt im Widget ändern.

Die Daten, die Statify erfasst, werden komplett lokal in der selben Datenbank wie WordPress gespeichert. Aktuell gibt es dort nur diese Daten:

• ID
• Datum
• Verweis (Referrer)
• Zielseite (Target)

Da die IP-Adresse nicht gespeichert wird, kann man keine unique visits erfassen. Jeder Seitenaufruf wird anonym erfasst.

Dieses Tool hat auf jeden Fall Potenzial und lässt sich sicherlich auch noch etwas erweitern. Wünschenswert wäre eine noch eine Verteilung der einzelnen Browser, die man dann als Torte darstellen könnte. Da Statify ohne Cookies oder JavaScript arbeitet, werden alle Nutzer erfasst, auch wenn sie Cookies oder JavaScript blockieren. Weiterhin werden keine persönlichen Daten gespeichert und deswegen ist auch keine Anpassung des Impressum nötig.

Das Diagramm wird mithilfe der Google Chart API erstellt.

Nötig für die Anzeige des Grundes ist, dass man die Option Hinweis “MARKED AS SPAM” unterdrücken nicht setzt. Anschließend öffnet man die Datei antispam-bee.php mit einem Texteditor und sucht die Zeile 756
$comment['comment_content'] = "[MARKED AS SPAM BY ANTISPAM BEE]\n" .$comment['comment_content'];
Diese ersetzt man durch diesen Text:
$comment['comment_content'] = "[MARKED AS SPAM BY ANTISPAM BEE – ".$reason."]\n" .$comment['comment_content'];

Der Unterschied zum Original ist klein. Neben dem Grund wird auch ein – eingefügt. Es wird an dieser Stelle der gleiche Grund ausgegeben, wie man ihn in der Mail findet. In der Version 1.9 gibt es diese Gründe: CSS Hack, Server IP, Country Check, Honey Pot und Empty Data. Die Erklärung dazu gibt es in der Dokumentation.

Ich habe Sergej vor dem Posting gefragt, ob was dagegen spricht, diese Anpassung zu Veröffentlichen. Er war einverstanden und hat mir gesagt, dass er diese in die nächste Version aufnehmen wird. Wer also nun seine Antispam Bee anpasst, wird diese Änderung auch in den nächsten Versionen finden.

Unwanted Plugins Remover klinkt sich beim Upgraden ein. Ist das Update heruntergeladen, entpackt, installiert und die Datenbank aktualisiert, werden in der Standardausführung die beiden Plugins Akismet und Hello Dolly gelöscht. Diese Liste lässt über die Anpassung der php-Datei des Plugins noch erweitern.

Sollte jemand doch Akismet nutzen und hat es daher aktiv, wird es nicht gelöscht und ist weiterhin vorhanden. Ich habe das Plugin schon seit einigen Tagen in unterschiedlichen Versionen testen können. Es funktioniert problemlos und macht genau was es soll. Sollte nun WordPress auf die Idee kommen und bspw. auch WordPress.com Stats mit einem Update auszuliefern, lässt sich die Liste problemlos erweitern. In einer zukünftigen Version sollen bei Upgrades nur noch der WordPress Core aktualisiert werden. Wann es soweit sind wird, ist noch offen. Bis dahin wird das Plugin helfen. Es läuft in allen Blogs ab WordPress 3.0

Für einen guten und datenschutzfreundlichen Spamschutz empfehle ich Antispam Bee.

[via]

Eines der Feature von Akismet ist eine Statistik, die anzeigt wie viele Spamkommentare es an einem Tag gegeben hat. Sergej Müller setzt nun eine solche Statistik erweitert. Während Akismet auf Flash setzt, verwendet Sergej hier moderne Techniken und schließt damit Browser aus dem Hause Microsoft aus, die nach wie vor kein Canvas unterstützen.

Die Biene hält bei mir seit über einem Jahr den Blog schön frei von Spam und hat seit rund einem Jahr fast 4000 Spams verhindert. Beim GoogleWatchBlog läuft es nun seit drei Wochen und hier schon fast 850 blockiert.

Antispam Bee ist zum einen schlanker als WordPress’ Akismet und ist dabei sogar sehr datenschutzfreundlich. Die IP-Adresse wird optional mit einer Spammerdatenbank verglichen ohne, dass dort Daten gespeichert werden. Dies verhindert, dass ein falsch eingestufter Nutzer bei späteren Kommentaren als Spammer gilt. Bei Akismet wird auch die Mail-Adresse und weitere Angaben in den USA gespeichert. Wer einmal ein Spammer ist, wird den Status wohl nur mit neuer Mail-Adresse wieder los.

Die Statistiken können über die Einstellungen aktiviert werden und erscheinen dann auf dem Dashboard. Für Internet Explorer-Nutzer, die es leider teilweise zwangsweise teilweise aus überzeugt noch gibt, wird diese Statistik automatisch ausgeblendet.

Da bei mir leider noch kein Spams eingegeben sind und eine Statistik mit nur einem Balken langweilig ausschaut, hier die Grafik vom Entwickler:

Sowohl auf meinem privaten Blog als auch auf GoogleWatchBlog.de werden einige seiner Plugins eingesetzt. Neben wpSEO auch Antispambee, wpTwitbox und Antivirus. Nun gibt es ein neues Plugin, das ein schlankes Caching-Plugin darstellt.

Cachify speichert alle Postings in der Datenbank von WordPress zwischen. Hierbei wird auf die Caching-Funktion von WordPress zurückgegriffen. Auf eine Optionsseite wird verzichtet, weil das eine weitere Abfrage nötig hätte.

Die beiden Einstellungen werden fest als Variable in das Plugin gesetzt. Derzeit gibt es nur zwei: EXPIRES und ONLYGUESTS. Mit erstem wird festgelegt wie lange die Daten im Cache gehalten werden sollen ehe es eine Aktualisierung geben soll. Der Wert ist in Stunden angegeben.

Mit ONLYGUESTS (Standard 1) wird festgelegt, ob Admins oder eingeloggte Nutzer eine gecachete Version erhalten oder nicht. Ist dieser 1 werden die Daten für eingeloggte Leser direkt aus den Tabellen der Datenbank gelesen.

Ich habe hier nun Cachify installiert und bin soweit zufrieden. Aus 38 Queries für die Startseite wurden 10 und auch die Zeit für die Ausführung ist. Unterm Strich ist das eine Einsparung von 73% der Queries.

Caching hat aber auch einen Nachteil: Die Seiten schauen für alle Besucher gleich ist. Hinweise für Nutzer von alten Browser (Stichwort IE 6) werden dann bei allen eingeblendet.

Bei dem mächtigen Tools wie WP Super Cache kann man einige Useragent ausschließen. Dies ist speziell für mobile Versionen wie wpTouch nützlich. Noch fehlt eine Art Blacklist für Useragents und daher ist es vorerst nichts für den GWB. Ich bin mir aber sicher, dass Sergej hierfür wohl eine Lösung finden wird.

Das Caching erstellt Cachify mehr oder weniger on the fly. Bei Aufruf wird geprüft ob die Daten im Cache liegen und falls ja, dann werden die gespeicherten Daten ausgeliefert. Falls nein, werden die Daten erstellt.

Der Download ist hier möglich.