(Updateinformationen werden am Ende des Artikels eingefügt, 12 Updates)

Heise hat eine meiner Meinung nach hervorragende Aktion mit dem Namen “2 Klicks für mehr Datenschutz” gestartet, um die beliebten Social-Buttons von Google, Facebook und Twitter datenschutzkonform in Webseiten einzubinden. Wer sich darüber etwas umfangreicher informieren möchte, macht das am Besten direkt auf der Seite des Heise Verlages.

Heute nun hat Heise den Code für ein JQuery-Plugin unter der MIT License (http://www.opensource.org/licenses/mit-license.php) veröffentlicht, was mich nun wiederum dazu angeregt hat, schnell mal ein Plugin für WordPress zusammen zu hacken, welches diese Funktion in WordPress einbindet. Wie das am Ende aussieht, kann man ab sofort sehr gut unterhalb meiner Beiträge sehen.

Das Plugin ist noch eine recht simple Version, wahrscheinlich werde ich in den nächsten Tagen an der einen oder anderen Stelle noch ein wenig basteln. Aber es funktioniert und erleichtert all jenen die Einbindung, die sich eben nicht sonderlich gut mit dem Bearbeiten von Templates auskennen.

Die Installation ist ziemlich simpel:

• Plugin herunterladen
• Datei entpacken und den Ordner xsd_wp_socialshareprivacy komplett in das Verzeichnis “wp-content/plugins” hoch laden
• Plugin in der Admin-Oberfläche aktivieren
• Facebook App-ID besorgen und unter “Einstellungen/XSD socialshareprivacy” in Eurer Admin Oberfläche eintragen (die Beschreibung, wie Ihr die App-ID erhaltet findet Ihr dort ebenfalls)

Das war auch schon alles. Die Buttons werden jeweils unterhalb der Beiträge in der Einzelansicht angezeigt. Wichtig ist, dass ohne eine Facebook App-ID der Facebook-Button nicht angezeigt wird.

Wie man sieht ist dieser Beitrag hier recht flott herunter geschrieben, wahrscheinlich ist an der Einen oder andere Stelle noch eine Frage offen. Fragt einfach nach, ich ergänze dann diesen Beitrag im Bedarfsfall, heute Abend habe ich etwas mehr Zeit als im Augenblick Ich werde auch schauen, dass ich das Plugin kurzfristig auf der WordPress-Seite zur Verfügung stellen kann, was natürlich Installation und Updates enorm vereinfachen wird.

Sollten Probleme mit dem Plugin auftauchen dann bitte einen Hinweis in den Kommentaren hinterlassen.

Update 08.09.11: Ich habe dem Plugin noch ein paar Verbesserungen gegönnt und ein paar Schönheitsfehler entfernt, die sich gestern beim herunterhacken eingeschlichen haben.

Die Änderungen im Detail:

• Das Script wird nun minified eingebunden, spart doch eine Menge Downloadzeit
• Infotexte für die Mouseover sind in der Admin-Oberfläche frei konfigurierbar. Per default werden die Original-Texte von heise angezeigt, wer hier andere Informationen sehen möchte, kann diese Texte nun anpassen.
• Menüeintrag unter “Einstellungen” heißt nun “XSD socialshareprivacy”
• Plugin ist nun im WordPress Plugin Directory unter dem Namen XSD socialshareprivacy gelistet. Updates ab sofort dann über wordpress.org

Update 09.09.11: Die letzte Version (0.6.2) ist bereits im Plugin Directory verfügbar. Wer am ersten Tag die Version installiert hatte, die ich hier zum Download bereit gestellt hatte, deinstalliert diese am besten und installiert von dort neu, somit erhaltet Ihr dann auch regelmäßig die Updates und müsst nicht mehr selbst nachschauen.

Die letzten Änderungen betreffen in erster Linie den Code, ich habe ein wenig aufgeräumt und aus dem Quick and Dirty Code nun so langsam eine etwas elegantere Lösung gestrickt. Die Parameter werden nun nicht mehr im Header übergeben sondern auf “anständige” Weise. Ich überlege, ob ich sämtliche Optionen des JQuery-Plugins von heise in die Admin-Oberfläche einbinden soll, so ganz bin ich mit mir da noch nicht im Reinen. Würde die Administration wieder recht unübersichtlich machen wie ich finde, aber falls der Bedarf da sein sollte, kann ich mich sicherlich breit schlagen lassen…

Update 11.09.11: Version 0.6.3 beseitigt einen kleinen Schönheitsfehler im JQuery-Plugin von heise. Der iframe für Twitter war zu groß, wodurch er den Bereich unterhalb der Buttons unsichtbar überlagerte und Links z.T. unklickbar machte. Dieser Fehler wurde entfernt.

Update 15.09.11: Soeben Version 0.6.4 eingecheckt, müsste im Laufe des Tages dann als Update angezeigt werden. Die Version beseitigt einen kleinen Anzeigefehler in manchen Templates, bei dem die Buttons für Twitter und Google+ in die nächste Zeile rutschen (siehe Kommentare unter diesem Beitrag).

Update 25.09.11: Version 0.6.5 bei WordPress.org hochgeladen. Nun kann auch der beim hovern von i angezeigte Infotext bearbeitet werden, wie in den Kommentaren gewünscht wurde.

Update 25.09.11 #2: Schwupps – und schon bei Version 0.6.7 (sollte bald via Update-Funktion in WordPress verfügbar sein). heise hat eine neue Version seines JQuery-Plugins bereit gestellt (Changelog), diese ist nun implementiert. Die neuen Optionen werde ich in den nächsten Tagen in die Admin-Oberfläche meines Plugins integrieren.

Update 25.09.11 #3: Version 0.6.9.1 ist nun aktuell. Das Admin-Backend wurde etwas aufgeräumt in Vorbereitung für die Erweiterung der Optionen. .1 am Ende, weil ich noch flott einen Bug beseitigt habe, der mir zu spät aufgefallen ist.

Update 27.09.11: Soeben Version 0.7 eingecheckt, Update sicherlich in Kürze für alle verfügbar. Beschreibung der Optionen nun änderbar, außerdem habe ich den Hinweis auf mich als Plugin-Entwickler wieder aus der Infobubble entfernt… zu aufdringlich.

Update 04.10.11: Version 0.7.1 steht nun zum Download zur Verfügung und wird wie gewohnt in Kürze über die Updatefunktion ausgeliefert. Ab dieser Version verwende ich wieder eine neue Version des JQuery-Plugins (aktuell 1.2). Für den Facebook-Button ist nun keine App-ID mehr erforderlich, daher wurden die Hinweistexte und die Funktionen rund um die App-ID aus meinem Code entfernt.

Update 06.10.11: Version 0.7.2 sollte nun allen via Updatefunktion zur Verfügung stehen. Neu ist die Möglichkeit, das Plugin auch für Seiten zu aktivieren, dafür gibt es in den Einstellungen nun einen neuen Eintrag. Aber bitte beachten: Bei der Verwendung von Caching-Plugins (z.B. W3TotalCache) kann es nach dem Umschalten dieser Option (aktivieren/deaktivieren) zum Teil lange dauern, bis die Änderung auf den Seiten Wirkung zeigt. Und übrigens: Über ein paar Bewertungen auf der Pluginseite würde ich mich echt freuen

Update 08.10.11: Schon wieder eine neue Version, wieder neue Features. 0.7.3 erlaubt es nun, jeden Button nach Belieben zu de-/aktivieren. Wer also keinen Facebook-Button anzeigen mag, kann diesen nun ausblenden. Darüber hinaus ist es nun auch möglich zu bestimmen, ob die Buttons vor oder nach dem Text angezeigt werden sollen. Ich persönlich bevorzuge immer die Position am Ende des Beitrags, andere mögen das aber anders sehen. Ihr könnt das nun wählen.

Update 08.10.11: Die Mehrsprachigkeit ist fertig, das Plugin kommt in Version 0.8 nun mit deutscher und englischer Oberfläche. Noch nicht übersetzt sind die Infotexte, die werden zunächst noch in Deutsch angezeigt, daran arbeite ich noch.

http://www.xsized.de/wp-login.php?action=logout&redirect_to=http%3A%2F%2Fwww.xsized.de%2Fein-ende%2F&_wpnonce=xxxxxxxxxx

Alle erzeugten einen 403-Fehler und verschlechtern natürlich die Bewertung des eigenen Blogs bei Google. Seiten mit fehlerhaften Links sind unschön und somit auch nicht wichtig. Also mal im Seitenquelltext nachgeschaut und festgestellt: Der Link wie oben im Beispiel dargestellt wird durch die WordPress Admin-Bar in die Seite eingefügt. OK, gut und schön, nachvollziehbar. Nur warum zur Hölle sieht der Crawler von Google die Admin-Bar?

Des Rätsels Lösung scheint in meinem Fall das Plugin W3 Total Cache zu sein. Dieses Plugin beschleunigt die Auslieferung der Inhalte, indem es diverse Caching-Mechanismen aktiviert. Unter anderem cached es auch die fertig zusammengebauten Seiten für eine gewisse Zeit auf der Festplatte und kann im Idealfall diesen Cache ausliefern, statt erst den deutliche längeren Weg über Datenbankabfragen nehmen zu müssen. Dieses Feature hatte mir schon einmal den Allerwertesten gerettet, als aufgrund eines massiv retweeteten Blogeintrages urplötzlich hunderte von Besuchern binnen 2-3 Minuten hier aufschlugen…

Nun, soweit, so schön. Aber eigentlich hatte ich erwartet, dass aufgrund der Aktivierung von “Don’t cache pages for logged in users” im Plugin meine Besuche NICHT gecached werden würden. Macht ja auch Sinn, anderenfalls würden Besucher meiner Seite unter Umständen MEINE Admin-Bar im Quelltext ausgeliefert bekommen. Und möglicherweise auch angezeigt… Überhaupt nicht schön. Nur scheint es exakt an diesem Punkt einen Bug im Plugin W3 Total Cache zu geben, denn ganz offensichtlich wurde meine Besuche sehr wohl gecached, nur nicht aus dem Cache an mich ausgeliefert. Googles Crawler hingegen hat die Seiten offenbar aus dem Cache bekommen, MIT meiner Admin-Bar. Und lief beim überprüfen der Links dann in den “403 Forbidden”-Fehler. Unschön.

Da ich die Admin-Bar ohnehin nicht nutze, habe ich sie nun kurzerhand ausgeblendet. Eine sehr einfache Möglichkeit dazu habe ich im Blog von WordPress Deutschland gefunden und somit war es nur eine Sache von einer Minute. Es gibt nun keine Admin-Links mehr in der Seite, auch nicht, wenn ich eingeloggt bin. Somit kann auch nichts falsches gecached und ausgeliefert werden. Problem (offenbar) gelöst. Werde in den nächsten Tagen mal verstärkt darauf achten, wie es in den Webmaster Tools aussieht.

Habe das Blog bereits aktualisiert, soweit ich sehen kann, läuft auch noch alles problemlos. Die Updates machen ja inzwischen dank dem integrierten Updater kaum noch Mühe. Falls jemandem Fehler oder Probleme auffallen sollten, einfach schrei(b)en.

Einfach ein wunderbares Eigentor von Sony. Mehr davon bitte. http://bit.ly/8ZH5Cx

04.11.2010 13:45 via TweetDeckReplyRetweetFavorite

@XSized

XSized

“Entdeckt” habe ich das Plugin über das Kulturmanagement Blog.

Im Feed sieht es nicht so toll aus, in die Seite werden die Tweets allerdings gut eingebunden.

Der erste Monat ist nun also vorbei, Zeit für eine erste kurze Bilanz. Beginnen wir mit meinen Einnahmen:

Wie der Screenshot zeigt, wurde genau 2 Mal der flattr-Button geklickt, was zu Einnahmen in Höhe von 41 Cent führte. Damit traf also ziemlich genau das ein, womit ich bereits vorab gerechnet hatte. Aktuell bin ich nicht sonderlich aktiv hier im Blog und zudem schreibe ich derzeit kaum Artikel, die meiner Meinung nach einen Klick wert wären.

Im Gegenzug habe ich im vergangenen Monat 4 mal geklickt. Und in ein paar Fällen hätte ich geklickt, wenn ein flattr-Button vorhanden gewesen wäre. Es gibt jedoch eine Menge Blogger, die flattr nicht oder auch nicht mehr anbieten wollen. Ist selbstverständlich auch die Entscheidung jedes Einzelnen, gar keine Frage. Die Entscheidung gegen flattr liest sich in verschiedenen Fällen auch durchaus exakt so wie die Bedenken, die ich in meinem ersten Beitrag zum Thema geäußert habe.

Ich werde den flattr-Button zunächst allerdings weiter aktiv lassen. Nicht, weil ich mir doch noch Einnahmen wie manch andere erhoffen würde, sondern weil ich meinen Test einfach noch ein wenig fortsetzen möchte. Ich habe mir keinen fixen Zeitrahmen gesetzt, insofern entscheide ich da aus dem Bauch heraus, ob und wann ich den Test beenden werde und ob ich anschließend den Button drin lasse oder entferne.

Mein aktuelles Fazit ist: Die Einnahmen bewegen sich in dem erwarteten Rahmen. Mit mehr hatte ich nicht gerechnet und ein anderes Ergebnis hätte mich ehrlich überrascht. Würde ich die Angelegenheit als “Geschäft” sehen, wäre es ein Minus-Geschäft, ich hätte also Verlust gemacht. Ich sehe es aber nicht auf diese Weise sondern schätze durchaus die Möglichkeit, sehr einfach einem Autoren für einen für mich wertvollen Beitrag zu danken. Dass dabei der eine oder andere Cent eventuell an mich zurück fließt, ist dabei eher nebensächlich.

Übrigens kann ich noch 2 Einladungen vergeben. Die Codes dafür lauten 1966d95db6f1f58d7 und 0fd6fa92499135e18. Wenn einer davon genutzt wurde, bitte in den Kommentaren darauf hinweisen, damit es nicht jemand dann vergeblich versucht

Tja, ein paar Minuten überlegt – updaten oder warten? Warten, oder doch updaten?

Nun, die Neugier hat gesiegt und mit ihr die Risikobereitschaft Bin gerade durch mit dem Update und bislang sieht es so aus, als würden die wichtigsten Dinge noch wunderbar funktionieren. (Die Fehlermeldung von Flattr am Ende der Beiträge war bereits vor dem Update da, die scheinen wohl gerade ein paar Probleme zu haben).

Bislang ist mir lediglich 1 Plugin aufgefallen, was nicht so ganz sauber zu funktionieren scheint: Fluency Admin. Wird also erst mal deaktiviert. (der Autor hat aber bereits ein Update angekündigt) Ansonsten ist mein Eindruck nach den ersten Tests: Alles läuft wir gewohnt, keine besonders auffälligen Probleme.

Sollte Euch etwas auffallen, einfach melden, ich schau es mir dann an.

Nachtrag: Eine Kleinigkeit ist mir gerade aufgefallen. Beim Erstellen eines neuen Artikels ist es nicht mehr möglich, die URL des Beitrages direkt anzupassen. Das geht im Moment nur, wenn man den Artikel nachträglich zum Bearbeiten öffnet. Bisher konnte man das direkt auch beim Erstellen. Keine Ahnung, ob das ein kleiner Bug oder so gewollt ist, hoffe auf Bug. Denn wäre es so gewollt, dann wär es tatsächlich etwas blöd.

Lediglich an einer Stelle war ich eine Weile wirklich nicht sicher, wie ich vorgehen sollte. Auf der Startseite sollen ein paar spezielle Artikel/Seiten in Slides dargestellt werden, in diesem Fall ein paar besondere Features des Produkts, für das die WebSite erstellt wird. Geht ohne Probleme, wenn man dafür Artikel (also Blogeinträge) nutzt. Hier gibt es dann nur ein paar Problemchen, wenn exakt diese Seiten dann auch im Navigationsmenü auftauchen sollen. Dynamisch. Von Hand ins Menü einbauen ist kein Problem, aber jedes Mal das Template anpassen, wenn ein Feature hinzu kommt oder entfällt will ich auch nicht. Zudem soll evtl. auch die eine oder andere externe Seite im Hauptmenü verlinkt werden (ein Doku-Wiki zum Beispiel).

Nach ein wenig Suchen bin ich dann allerdings doch fündig geworden: Die Lösung präsentierte sich in Form des Plugins Big Big Menu. Zumindest fast…

Mit Hilfe dieses Plugin kann der Administrator das Menü weitestgehend selbst erstellen. Und hierbei ist es möglich Seiten, Kategorieseiten, Autorenseiten und einzelne Links nach Belieben als Menüpunkte auszuwählen und anzuordnen. Schicke Sache. Das Plugin hat nur einen Haken: Es kann nur eine Menüebene darstellen.

Der Autor hat seit 2008 nichts mehr am Plugin getan, also habe ich mich heute selbst dran gesetzt und das Plugin nach meinen Vorstellungen ein wenig erweitert. Inzwischen kann das Menü auch Unterseiten einer Seite darstellen (wenn gewünscht) und, wenn eine Kategorie als Menüpunkt verwendet wird, auch eine (noch fixe) Anzahl von Artikeln aus dieser Kategorie im Untermenü einblenden. Also exakt das, was ich benötige. Allerdings feile ich noch ein wenig an den Optionen, die Zahl der anzuzeigenden Artikel im Untermenü soll beispielsweise noch einstellbar werden und einige Fehler, die sich im Laufe der unterschiedlichen WordPress-Versionen im Admin-Bereich nun eingeschlichen haben, will ich auch noch ausbügeln.

Das ursprüngliche Plugin wurde von Jason Tremblay unter einer Creative Commons Attribution-Share Alike 3.0-Lizenz veröffentlicht und demzufolge werde ich meine Version in Kürze unter der gleichen Lizenz zur Verfügung stellen. Sobald die Optionen wie gewünscht funktionieren und die auffälligsten Fehler beseitigt sind. Ich denke, damit werde ich in den nächsten paar Tagen fertig sein (vorausgesetzt, mein Main-PC ist bis dahin wieder fit) und dann wird es hier einen entsprechenden Beitrag geben, der die Funktionsweise etwas näher erläutert.

Falls jemand Interesse hat, vorab schon mal einen Blick auf meine Beta zu werfen und so vielleicht noch den einen oder anderen Fehler zu finden, der mir evtl. noch nicht aufgefallen ist, einfach in den Kommentaren mit eMail-Adresse melden und ich schick ab morgen dann die jeweils aktuellste Version per Mail heraus.

Nachtrag: Manchmal ist es echt verhext. Da setz ich mich gestern ein paar Stunden an den Code und schreibe ihn um und kurz danach stelle ich fest: WordPress 3.0 bringt nahezu identische Funktionalität mit. Out of the box. Na prima…

Heute habe ich mir das dann mal in Ruhe angeschaut, ist auf jeden Fall sehr gut gelöst. Aber: Artikel kann ich dennoch nicht ins Menü einbinden. Insofern war die Arbeit am Plugin nicht vollkommen umsonst und ich werde es fertig stellen. Der Vorteil des Plugins ist: Es arbeitet (nahezu) mit jedem Theme, Anpassungen sind nicht erforderlich. Zudem kann ich eben Artikel im Menü einblenden. Möglicherweise benötigen andere diese Funktionalität ebenfalls. Und wenn ich etwas mehr Zeit habe, schaue ich mir WP 3.0 etwas genauer um und baue die mir fehlenden Features dann eben in den neuen Menü-Editor ein. Schauen wir mal.

“Möglicherweise” schreibe ich, weil ich mir diesbezüglich noch nicht so ganz sicher bin. Es muss sich letztlich erst zeigen, ob diese Variante, Leser für Beiträge “spenden” zu lassen, tatsächlich erfolgreich sein wird oder nicht. Verschiedene Dinge erscheinen mir persönlich aktuell nicht ganz ausgereift bzw. zu Ende gedacht. Ist vielleicht nur ein Gefühl, da bin ich noch nicht so sicher. Beispielsweise betrifft das die Art der Aufteilung der Beträge. Intransparent, zumindest aktuell. Und zwar sowohl für den “Spender”, als auch für den “Empfänger”. Als Spender habe ich eher das Gefühl, einen Betrag X für einen sehr guten Beitrag spenden zu wollen. Beispielsweise 1 Euro. Weil mir der Beitrag möglicherweise einen Euro wert erscheint. Aktuell geht das nicht, zumindest nicht direkt. Aktuell teilt sich mein monatliches Budget einfach auf auf alle Beiträge, bei denen ich den Button geklickt habe. Womit ein Beitrag, dem ich vielleicht einen Wert von 50 Cent beimessen würde, genau so entlohnt wird wie ein Beitrag, der mir eigentlich 5 Euro wert wäre. Aber gut, vielleicht wird es die Möglichkeit dieser “Direktspende” später noch geben.

Für die Empfänger ist es ebenso wenig ersichtlich, wie viel ein Beitrag den Lesern wert ist. Man sieht sicherlich: Dieser Beitrag ist x Benutzern etwas wert. Was? Keine Ahnung. Am Ende des Monats zeigt sich erst, ob die Beiträge insgesamt 50 Euro wert waren oder gerade mal einen… Genau aus diesem Grund sehe ich auch noch keinen wirklichen Nutzen für beispielsweise kommerzielle Online-Magazine oder -Zeitungen. Einfach weil keinerlei Kalkulationen möglich sind. 10 Flattr-Klicks in einem Monat können theoretisch durchaus mehr Geld einbringen als 200 Klicks in einem anderen Monat.

Nun, prinzipiell finde ich die Idee allerdings durchaus in Ordnung und deshalb mache ich diesen Test. Einfach weil ich schauen will, wie sich die Idee in der Praxis durchsetzt und was es bringt. Große Einnahmen rechne ich mir nicht aus, woher auch. Dafür bin ich aktuell viel zu inaktiv und schreibe zu wenig “richtige” Beiträge, meine automatisierten Linkpostings kann man nicht wirklich zählen. Aber dennoch bin ich einfach neugierig und probiere es aus. Wie gesagt: Der Ansatz ist nicht verkehrt und in meinen Augen könnte durchaus etwas daraus werden. Wenn (hoffentlich recht bald) weitere Zahlungsmöglichkeiten geschaffen werden. Gerade hier in Deutschland sind PayPal und Moneybookers für viele sicherlich nicht die Zahlungsmethoden der Wahl… Aber schauen wir mal eine Weile.

Eingebunden habe ich Flattr hier übrigens mit Hilfe des WordPress-Plugins “Flattr“. Einfacher gehts nun wirklich nicht. Das muss man eigentlich nicht mal erklären, Spreeblick hat es trotzdem getan.

Als Flattr-Nutzer kann ich übrigens 3 Einladungen vergeben. Einfach in den Kommentaren melden (und korrekte Mailadresse eintragen), ich schicke die Einladungen dann einfach der Reihe nach heraus.

btw: Ja, ich will meinen Flattr-Account auch nutzen, um selbst zu flattrn. Sprich: Ich habe ein monatliches Budget eingestellt, mit dem ich mich für Beiträge bedanken möchte. Gefällt mir besser als der “Gefällt mir”-Button.

Optimierungsmöglichkeiten gibt es hier einige, überflüssige Gimmicks und Plugins zu entfernen wäre eine Möglichkeit, die man als erstes in Angriff nehmen sollte, wenn die Ladezeit des Blogs zu lang wird. Aber auch Caching trägt einen guten Teil zur Beschleunigung einer Seite bei.

Ich habe hier auf meinem Blog seit 3-4 Wochen das Caching-Plugin W3 Total Cache im Einsatz. Der Geschwindigkeitszuwachs beim laden der Seite war deutlich spürbar. Die Ladezeiten meines Blogs lagen laut Webmaster Tools vor dem Einsatz des Plugins bei teilweise bis zu 8-10 Sekunden, vor allem bei Einträgen mit vielen Kommentaren. Hier hatte ich zunächst die Paged Comments aktiviert (sieht man ja bereits seit einiger Zeit) und so ca. 1 Sekunde Ladezeit gewonnen. Mit dem Plugin ging die Ladezeit der langsamsten Seiten dann herunter auf unter 4, teilweise unter 3 Sekunden. Ziemlich flott, wie ich finde. Weitere Optimierungsmöglichkeiten würde ich jetzt noch am Template sehen, hier kommt aber möglicherweise demnächst ohnehin etwas ganz anderes.

Vor 2 oder 3 Tagen hatte ich ein weiteres Caching-Plugin für WordPress getestet: Hyper Cache. Und ich fand, dass die Seite noch einmal spürbar flotter geladen wurde. Zumindest in Chrome, den ich ja einsetze. Subjektiv war die Seite richtig schnell, messbar war es noch nicht, da die Webmaster Tools ja immer mit ein paar Tagen Verzögerung die Wirkung einer Maßnahme anzeigen.

Leider wurde mir allerdings gestern gemeldet, dass mein Blog “völlig zerschossen” sei. Der erste Check mit Chrome brachte nix, sah alles toll aus, keine Probleme zu sehen. Doch dann versuchte ich es mit dem Firefox und meine Seite sah so aus (was möglicherweise einigen von Euch ebenfalls aufgefallen ist):

Schick, oder?

Nach einer ersten Schrecksekunde fiel mir auf: Moment, exakt so sehen die Cache-Files aus, die Hyper Cache auf der Platte ablegt. Also Hyper Cache deaktiviert, erneut geprüft und alles war wieder schick.

Bisher habe ich noch keine Lösung gefunden, ich hab noch keinen Schimmer, warum Firefox die Seiten nicht darstellen kann, wenn Hyper Cache aktiviert ist. Ich hoffe, hier noch eine Lösung finden zu können denn ich empfand die Beschleunigung durch Hyper Cache doch noch etwas besser als die, die mir W3 Total Cache liefert. Die ist durchaus auch nicht schlecht, keine Frage, aber Hyper Cache war eben subjektiv einen Touch flotter. Was nur leider nichts bringt, wenn die Browser die Seiten anschließend nicht mehr darstellen können.

Eigentlich (!) hatte ich nur mal wieder experimentiert. Ich wollte ein Plugin testen, welches in meiner lokalen Installation anstandslos funktionierte: Shared Items Post. Dieses Plugin liest meine aktuellen Empfehlungen aus, die ich im Google Reader gesetzt habe und postet sie als eigenständigen Beitrag, einmal am Tag. So weit die Theorie.

Was in der Praxis daraus resultierte, konnte man nun gerade eben schön beobachten: Das Plugin hat binnen weniger Sekunden 49 identische Einträge in die Datenbank geschrieben, worauf diese dann dicht machte. Schnelle erste Hilfe: Per FTP das Plugin vom Server gelöscht und einige Sekunden später war der Server wieder erreichbar und die Datenbank um 49 Beiträge größer Diese hab ich nun wieder gelöscht und das Plugin bleibt draußen.

Eigentlich ein wenig schade, genau diese Möglichkeit würde ich gern noch nutzen. Bislang habe ich immer den Umweg über Delicious genommen, finde aber die Empfehlungen im Reader direkt ungemein praktisch. Als Widget mag ich die Empfehlungen nicht einbinden, mir gefällt die Möglichkeit, dafür täglich einen eigenständigen Beitrag automatisch zu erstellen. Aber leider scheint daraus vorerst nichts zu werden, denn auch die Weiterentwicklung dieses Plugins mit dem Namen SharedItems2WP funktioniert nicht. Im Gegensatz zum Original macht diese nämlich garnix (was angesichts der möglichen Ausmaße, die mir glücklicherweise erspart geblieben sind, angenehm harmlos ist).

So wie es aktuell integriert ist, macht es allerdings in meinen Augen noch nicht ganz so viel Sinn. Man kann “Mitglied” werden und das wird dann auch schön mit bunten Bildchen angezeigt, das war es auch schon. Funktionell ist nichts gewonnen. Einen Nutzen bringt das Ganze erst dann, wenn beispielsweise dadurch die lästigen Zusatzangaben beim kommentieren entfallen würden.

Genau da liegt aber im Augenblick noch der Hase im Pfeffer: Ich hab bislang noch kein vernünftiges WordPress Plugin dafür entdeckt. Ein Plugin erweckt den Eindruck, das zu können, aber die Seite der Entwickler steht zum Verkauf, hier ist also wohl nicht mit Updates zu rechnen. Und der getestete Rest ist irgendwie nix. Das Plugin von Google integriert sich so radikal, dass anschließend alle vorhandenen Kommentare nicht mehr zu sehen sind und nur noch die über Google Friend Connect verfassten Kommentare angezeigt werden. Ist also auch nix.  (siehe Update am Ende)

Ich schaue mich natürlich weiter um, vielleicht finde ich ja noch etwas, vielleicht kennt auch jemand von Euch eine gute Lösung. Vorerst ist die Integration von Friend Connect hier definitiv noch im Alpha-Stadium

Update: Anders als eben noch geschrieben, integriert sich das Plugin von Google doch auch wesentlich angenehmer. Die Option “Enable FriendConnect Comments” tauscht die Kommentarfunktion komplett aus und integriert eine eigene. Dadurch sind auch die alten Kommentare nicht mehr sichtbar. Deaktiviert man diese Funktion, dann hängt sich das Plugin nur über einen Hook in die WordPress Kommentarfunktion und erlaubt es dann, wenn man per Friend Connect angemeldet ist, mit den dort hinterlegten Daten zu kommentieren. So macht das alles natürlich wesentlich mehr Sinn. Also korrigiere ich von Alpha- auf Beta-Stadium

Wie einfach es beispielsweise ist, eine Backdoor in ein Template zu integrieren, welche einen Benutzer in WordPress anlegt und diesem Administrator-Rechte zuweist, zeigt der Beitrag “How-To: Create Backdoor Admin Access in WordPress“. Der Code sitzt in der functions.php des Templates und wird durch einen speziellen Aufruf der Zielseite aktiviert. Mittels der Funktion wp_create_user aus wp-includes/registration.php wird nun ein neuer Benutzer in der Datenbank angelegt und zum Administrator gemacht. Fertig, die Tür ist offen. Egal, ob die Registrierung von neuen Benutzern erlaubt ist oder nicht.

Um solch eine Backdoor nachträglich in eine WordPress-Installation zu integrieren, benötigt ein Angreifer natürlich Zugriff auf die Daten, beispielsweise via FTP. Allerdings ist man darauf nicht zwingend angewiesen, was hindert einen potentiellen Angreifer daran, eine Seite aufzusetzen, von der man Unmengen an WordPress-Templates herunter laden kann, die durch die Bank mit einer solchen Funktion präpariert sind? Oder warum sollte ein Entwickler nicht ein solches Hintertürchen in sein wunderbares WordPress-Plugin integrieren? Hand aufs Herz: Wie groß wird der Anteil an WordPress-Nutzern wohl sein, die PHP beherrschen und ein solches Hintertürchen erkennen könnten? 10%? Und wie viele prüfen denn tatsächlich jedes Plugin oder Template auf potentiellen Schadcode? 1%? Weniger?

Aktuell überwiegt einfach das Vertrauen. Vertrauen in die Redlichkeit der Entwickler und Vertrauen in die Ehrlichkeit der Betreiber von Template-Portalen. Sicherlich löblich, offenbar ist noch nicht zu viel passiert in der Vergangenheit. Aber ein wenig Vorsicht sollte dennoch angebracht sein und somit sind vorbeugende Maßnahmen sicherlich nicht falsch.

Den oben beschriebenen “Exploit” (um einen “echten” Exploit handelt es sich meiner Meinung nach nicht wirklich) kann man auf verschiedene Weisen aushebeln.

Variante 1: Wir benennen die Datei wp-includes/registration.php einfach um. Damit hebeln wir allerdings automatisch sämtliche Funktionen zur Bearbeitung bereits existierender Benutzer aus. Also nicht so schick. Zudem ist das nach jedem WordPress-Update zu wiederholen.

Variante 2: Wir kommentieren die Funktion wp_create_user in der Datei wp-includes/registration.php aus. Das Gleiche müssten wir mit der Funktion wp_insert_user in der gleichen Datei tun. Auch hier sind verschiedene Funktionen in der Admin-Oberfläche anschließend defekt und auch dieses Procedere müsste nach jedem Update wiederholt werden. Also auch nicht wirklich schön…

Variante 3 (empfohlen): Wir legen einen zusätzlichen Verzeichnisschutz für das Verzeichnis /wp-admin/ an. Die meisten Provider bieten diese Funktion in der Admin-Oberfläche an, wer diese Funktion bei seinem Provider nicht findet, dem empfehle ich Punkt 8 dieses Artikels. Hier wird die Vorgehensweise recht gut erläutert, auch die anderen Tipps sind prinzipiell sehr zu empfehlen.
Dieser zusätzliche Verzeichnisschutz sorgt nun dafür, dass für den Zugriff auf /wp-admin/ eine zusätzliche Anmeldung erforderlich ist. Bevor also ein Angreifer, der bspw. die oben beschriebene Backdoor ausführen konnte, sich mit seinem neuen Benutzer an Eurem Blog anmelden könnte, müsste er eine weitere, von WordPress unabhängige Authentifizierung erfolgreich vollziehen. Wenn Ihr hier mit einem ausreichend starken Passwort arbeitet, wird das (relativ) schwierig.

Wie weiter oben bereits geschrieben, sehe ich die im verlinkten Beitrag aufgezeigte Möglichkeit zum Anlegen eines administrativen Benutzers nicht als “echten” Exploit an sondern sehe die Problematik allgemein in der Möglichkeit der Erweiterbarkeit. Und sicherlich beschränkt sich das Problem somit nicht allein auf WordPress. Allerdings ist es natürlich durch die von WordPress zur Verfügung gestellten Funktionen wesentlich einfacher, erfolgreich eine Hintertür einzurichten. Möglicherweise sollten gerade die Funktionen zur Erstellung und Änderung von Benutzern gekapselt werden und eben nicht von jedem xbeliebigen Addon genutzt werden können. Aktuell ist es aber möglich, daher sollten WordPress-Nutzer sich nicht allein auf die mitgelieferten Sicherheitsfunktionen verlassen, sondern selbst Hand anlegen. Und sicherlich auch hin und wieder mal nachschauen, ob plötzlich neue Benutzer in der Datenbank auftauchen, obwohl die Registrierung nicht erlaubt ist.