Wütende Worte im Wordpress-DE-Forum

Seit Erscheinen der deutschen Version 2.3, mit der das beliebte Open-Source CMS Wordpress einige Veränderungen seiner Schnittstelle zur Anwendungsprogrammierung (API) erfahren hat, werden die kritischen Stimmen lauter, die Anwender/innen des PHP- und MySQL-basierten Blogsystems verunsichern.

Der Schutz von Daten ist für sich genommen ein Thema, das in Zeiten von Vorratsdatenspeicherung und Bundestrojaner seine Berechtigung hat; und das gilt im Übrigen für auf Protokollen basierende Daten-Kommunikation im Allgemeinen. Trotzdem rückt Wordpress Deutschland hierbei in den Fokus.

Der Grund für diese Paranoia besteht offensichtlich darin, dass Datenschutz und die Verwendung von Plugins in Verbindung mit der deutschen Distribution von Wordpress öffentlich zum Thema gemacht werden.

Mittlerweile sind Aufrufe zur Gründung einer alternativen WP-Community zu vermelden, die sich von Wordpress-DE abgrenzen möchte. Wieso so eine Aufregung um ein paar Zeilen Code, die im Zusammenhang mit LinkLift stehen und als mitgeliefertes Plugin in der neuen Wordpress Version aktiviert werden können?

Werfen wir mal einen Blick in den Code des umstrittenen Plugins von LinkLift. Das Markup, welches im WP-Adminpanel unter Plugins ausgegeben wird, enthält die Zeile:

Register at <a href=”http://www.linklift.de/?ref=2d2abc54341″ target=”_self”>http://www.linklift.de/</a>

Im Plugin selbst ist entsprechend folgendes notiert:

define(”LL_PLUGIN_REGISTER_LINK_URL”, “http://www.linklift.de/?ref=2d2abc54341″

Der Stein des Anstoßes besteht in der Art und Weise, wie das LinkLift-Plugin, welches durchaus mit kommerziellen Interessen behaftet ist, den arglosen Wordpress-Nutzern mit der neuen deutschen Version “untergejubelt” wird.

Wurde der Update-Monitor in der Version 2.3 ersetzt, so gingen damit auch Änderungen einher, mit denen nicht alle zufrieden sind. WP Deutschland informiert zwar über Neuerungen, allerdings ist anzunehmen, dass nicht jeder weiß, was er sich herunterlädt und installiert.

Dennoch: “Unwissenheit schützt vor Strafe nicht”, so die Worte meines Politiklehrers, die ich nach all den Jahren nicht vergessen konnte.

Updatebenachrichtigungen

Das gute Update-Monitor Plugin hat ausgedient, da WordPress nun selber über neue Versionen Auskunft gibt. Auch über neue Aktualisierungen von Plugins wird man nun informiert, sofern sie bei wordpress.org gelistet sind.

So sollen Daten, wie die Namen aller installierten Erweiterungen (Plugins) mit Versionsnummer und auch der Name der Domain übers Internet versendet werden. Kritiker sehen darin eine Verletzung ihrer Privatsphäre und ihres Bedürfnisses nach Selbstbestimmung und Datensicherheit und werfen in polemischer Weise den Betreibern von WP Deutschland die Kommerzialisierung eines OpenSource-Projektes vor, indem indirekt Nutzerdaten mithilfe des LinkIt-Plugins an LinkIt gesendet werden würden. Im offiziellen Forum von WordPress Deutschland wird auch der Vorwurf laut, dass hierbei Geld geflossen sei.

Neben der Spam-Problematik sei dies auch eine Security-Sache, denn wer über verwendete Versionsnummern, Plugins und Domaindaten verfügt, besitzt ein mächtiges Wissen angesichts der unzähligen deutschen Wordpress-Installationen.

Diese Bedenken bezüglich der Sicherheit wurden in der Newsgroup wp-hackers thematisiert, doch auch die hilflosen Erklärungsversuche gegenüber Anfragen zu diesem Thema konnten mir nicht wirklich weiterhelfen. Als Außenstehender bin ich auch vorsichtig, wenn es um gemeinschaftliche Versäumnisse geht und werde lieber pragmatisch das Beste aus allem machen, zum Beispiel Plugins löschen und Dateien anpassen, die ich für überflüssig halte.

Einige Vorschläge, wie das Problem mit der WordpressDE 2.3 - wenn es denn als solches wahrgenommen wird - umgangen werden kann:

  • Verzicht auf sämtliche Plugins, WP läuft auch ohne Erweiterungen sehr fein.
  • Englische Version verwenden, deutsche Version löschen.
  • Den Teufel mit dem Beelzebub austreiben: Die Core-Änderungen, die dafür sorgen, dass der Benutzer durch Hinweise und Anzeigen über Updates informiert wird, durch ein Plugin von John Blackbourn ausschalten. So wie es aussieht, schaltet das Plugin mehr ab, als es soll.
  • Lösungsvorschlag unter Verwendung der veralteten my-hacks.php, wobei die Update-Funktion erhalten bleibt. Weiteres dazu und Download bei Schnurpsel oder etwas anders bei Il Filosofo.
  • Manuelle Anpassung der Datei wp-admin/include/update.php durch Ersetzen des Funktionsaufrufs get_bloginfo(’url’), der den URI der WordPress-Installation preisgibt (siehe unten).

Trotz aller Unkenrufe sollte niemand vergessen, dass auch eine Google-Erweiterung für den Browser, Adwords im Blog und der Seitenaufruf von Yahoo-Groups Nutzderdaten übermitteln. Wer Windows verwendet, findet nach einer Neuinstallation auch den Alexa-Bot vor, da beschwert sich niemand öffentlich darüber.

Eine schnelle, aber dreckige Lösung, die ich oben als letzten Punkt in der Liste genannt habe, findet sich neben anderen Vorschlägen auch hier. Man ersetzt also in der Datei wp-admin/include/update.php die vorhandene Zeile:

$http_request .= 'User-Agent: WordPress/' . $wp_version . '; ' . get_bloginfo('url') . "\r\n";

durch etwas wie:

$http_request .= 'User-Agent: WordPress/' . $wp_version . '; http://www.example.com/' . "\r\n";

Dabei wird der Funktionsaufruf durch eine Domain ersetzt, die anstelle der Domain des Wordpress-Benutzers dann Verwendung findet. Man kann da im Prinzip eintragen, was erlaubt ist. Ich habe als ein mögliches Beispiel http://www.example.com/ eingesetzt, natürlich gibt es auch andere Lösungen. Wenn die Änderungen vorgenommen wurden, muss die Datei noch auf den Server übertragen werden und fertig.

Absolute Datensicherheit hat man vielleicht dann, wenn man sein System nicht mit dem Internet verbindet und nur selbst von seiner Existenz weiß. Doch genau das widerspricht der Idee des gemeinsamen Austauschs, des SocialNetwork, dem Bloggen mit Wordpress oder anderen Systemen und somit der Art und Weise, wie Kommunikation in unserer Zeit passiert.

Wer dabei an eine Verschwörung denkt, der sollte mal wieder an die frische Luft und konzentriert seinen Namen tanzen gehen. Vielleicht hilft das bei der Erdung. Mir hat das geholfen.

XAMPP und Skype zusammen verwenden

Wer eine XAMPP-Installation (Windows) verwendet, kennt vielleicht auch das Problem: Die Software Skype läuft nicht mehr ohne Störung. Verbindungen brechen ab oder können erst gar nicht hergestellt werden.

Um während der Server läuft mit anderen Skype-Nutzern kommunizieren zu können, musste man bisher XAMPP immer als erste der beiden Anwendungen ausführen. Skype sucht sich dann einen alternativen Port, wenn XAMPP zuvor bereits gestartet wurde. Sowohl Skype als auch XAMPP verwenden den gleichen Port, doch auf diese Weise können beide parallel betrieben werden, ohne in ihrer Funktionalität beeinträchtigt zu sein.

Trotzdem ist dies eine gewisse Einschränkung, und zudem nicht immer gewollt - dabei genügt doch eine kleine Anpassung in einer Datei, um zu ermöglichen, dass Skype und XAMPP ohne Konflikte bei der Portbelegung zusammen ausgeführt werden können.

Das Logo von XAMPP Das Logo von Skype

Die kleine Anpassung ist im Prinzip nichts anderes, als die Änderung des Ports, auf den XAMPP zugreift. Ich habe es im Juni 2006 mit XAMPP 1.8, 2.1 und 2.2 auf WinXP Pro SP2 und der damals aktuellen Skype-Version vorgenommen. Auch heute klappt es natürlich noch, mit aktuellen Versionen der Programme. Zuletzt getestet mit der XAMPP für Windows Version 1.6.4 und Skype 3.5.0.234.

Allerdings werden die Änderungen bei einem Update auf eine neuere Version nicht übernommen. Sie müssen danach wieder angepasst werden.

Wir gehen mal davon aus, dass die Installation von XAMPP auf Partition E im Ordner \Server liegt. Bei einer Standardinstallation auf Windows findet man das XAMPP-Verzeichnis hier: C:\Programme\xampp bzw. C:\xampp.

Für die Anpassung habe ich den Editor verwendet, der bei Windows standardsmäßig vorhanden ist. Der Shortcut Gehe zu… hat die Tastenkombination Strg + G. Anschließend einfach die Zeilennummer eingeben. In der Statusleiste erscheint - wenn sie aktiviert ist - die aktuelle Nummer der Zeile, zur Orientierung bei umfangreichen Dokumenten.

Und so einfach ist es:

  1. XAMPP ist nicht gestartet. Öffne die Datei httpd.conf mit dem Editor. Die Datei findet sich in E:\Server\xampp\apache\conf\. Im Editor wird unter Ansicht ein Haken bei Statusleiste gesetzt (falls nicht schon vorhanden).
  2. Gehe in Zeile 53 und ändere die Portangabe 80 in 8080. Es steht dann Listen 8080 da.
  3. Ändere anschließend Zeile 169 in: ServerName localhost:8080.
  4. Speichern. Schließen.
  5. Öffne die Datei httpd-ssl.conf im Ordner E:\Server\xampp\apache\conf\extra\mit dem Editor und gehe in Zeile 37. Hier änderst du die Angabe in: Listen 4430.
  6. In Zeile 74 steht nach deiner Änderung: <VirtualHost _default_:4430>
  7. Jetzt änderst du noch Zeile 78 so, dass dort ServerName localhost:4430 zu lesen ist.
  8. Speichern. Schließen.

Wenn der Server gestartet wurde, müssen in den Browsern die entsprechenden Anpassungen vorgenommen werden. Wenn man im Browser als Startseite z. B. das Index-Dokument im htdocs-Ordner anzeigen lassen möchte, dann muss nur noch die Adresse http://127.0.0.1/ bzw. http://localhost/ um den geänderten Port ergänzt werden. In den Einstellungen des Browsers trägt man für die Startseite ein: http://localhost:8080/.

Das war es auch schon. Beide Programme lassen sich jetzt nach Lust und Laune unabhängig voneinander starten und beenden, ohne dass es Verteilungskämpfe um die verwendeten Ports gibt.

(Dieser Beitrag wurde am 06.12.2007 ergänzt.)