Tja, Twitter möchte in der API seine Benutzer nicht mehr auf die althergebrachte Art (also mit einer einfachen HTTP-Authentifizierung) anmelden lassen, sondern verwendet jetzt ein etwas komplexeres Verfahren. Darüber kann man denken, was man will – ich denke zum Beispiel erstmal nichts Gutes darüber – aber wenn man mithilfe der API twittert (oder twittern lässt), denn muss man damit leben. Es hat sich ja auch schon vor längerer Zeit angekündigt, dass es einmal dazu kommen wird.
Man muss zum Beispiel damit leben, wenn man in sein WordPress das sehr beliebte Plugin Twitter Tools verbaut hat, das sowohl das automatische Twittern von Blogeinträgen als auch eine automatische tägliche oder wöchentliche Zusammenstellung der Tweets in einem Blogeintrag aufbereiten kann. Bislang war dies ein recht einfaches Plugin, man gab seinen Twitter-Benutzernamen und sein Twitter-Passwort ein, machte ein paar Einstellungen, welche Features man haben wollte und es führte sich so auf, wie Technik sich gegenüber dem Menschen aufzuführen hat und funktionierte einfach. Na ja, meistens – ältere Versionen haben sich zuweilen etwas eigenwillig verhalten und die Zusammenfassung mehrfach gebloggt.
Im WordPress-Dashboard kann man seit einigen Tagen (wenn man den Upgrade noch nicht gemacht hat) sehen, dass die Version 2.4 von Twitter Tools erschienen ist, und der Update ging wie gewohnt mit einem einfachen Klick vonstatten. Der Grund für die neue Version ist, dass die Tage des alten Authentifizierungsverfahrens bald endgültig gezählt sind und dass die Twitter-API dann über OAuth bedient werden muss. Nach dem Upgrade des Plugins hatten etliche Leute Probleme – ich übrigens auch. Zum einen sind die neuen Einstellungen für »normale Menschen« ein bisschen verwirrend, zum anderen stellt der Plugincode gewisse Anforderungen an die PHP-Version, die in dieser Form vorher nicht bestanden haben. Wer dann auch noch Probleme damit hat, die meist englischen Texte zum Thema zu lesen, fühlt sich schnell ein bisschen alleingelassen mit solchen Updates, die die Welt nicht braucht.
Deshalb dieser kleine Text, der hoffentlich jedem Menschen mit seinen Problemen dabei hilft, Twitter Tools 2.4 in den verbleibenden 9 Tagen zum Laufen zu bringen. Er soll keine vollwertige Anleitung werden, aber eine allererste Hilfe und vielleicht auch eine Ermutigung angesichts der oft auftretenden Schwierigkeiten. 😉
Ich sage es gleich vorab: Es ist für die meisten Menschen keine Kleinigkeit, die man »mal eben so nebenbei« erledigt. Deshalb lieber etwas Zeit nehmen und ruhig vorgehen – wer sich etwas mehr Zeit genommen hat, als er braucht, wird schon etwas damit anzufangen wissen…
Voraussetzungen
(Ich schreibe das hier nicht für Menschen, die einen Server selbst verwalten und sich zu helfen wissen, wenn etwas installiert werden soll, sondern für die vielen anderen Menschen, die einfach nur ein Hosting gemietet haben und vor dem Rätsel einer nicht funktionierenden Software stehen.)
Twitter Tools 2.4 benötigt PHP5. Einige Webhoster haben immer noch Pakete mit PHP4 im Angebot, und so lange es nur um WordPress geht, ist das auch kein besonderes Problem. Auch die aktuelle WordPress-Version 3.0.1 kann noch mit PHP4 betrieben werden.
Wer nicht weiß, welche PHP-Version auf seinem Webspace vorliegt, sollte es einmal herausbekommen. Das geht sehr einfach. Man nehme sich einen Texteditor (für diesen Zweck reicht wirklich der einfachste Editor, aber ein besserer Editor kostet nichts und macht einem das Leben so unendlich viel leichter, dass ich nur dazu raten kann) und erstelle damit eine Datei mit folgendem Inhalt:
<?php phpinfo (); ?>
Ja, das ist alles! Manche Dinge gehen auch einfach. Diese Datei speichert man unter irgendeinem Namen mit der Extension .php – ich empfehle phpinfo.php, damit man auch ein paar Tage später noch weiß, wofür sie gut ist – und lädt sie wie gewohnt auf seinen Webspace hoch. (Einige Editoren hängen immer die Dateinamenserweiterung .txt an ihre Dateien, solche Editoren sind zu gar nichts geeignet und sollten nicht benutzt werden.) Danach muss diese Datei einfach nur im Browser aufgerufen werden, und schon erfährt man mehr über die verwendete PHP-Installation, als man vermutlich jemals wissen wollte:
Ganz oben und recht groß steht die meist wichtigste Info, die verwendete PHP-Version, hier im Beispiel 5.2.10-2ubuntu6.4. Wenn diese Zeichenkette mit einer 5 beginnt, hat man gewonnen. Wenn sie mit einer 4 beginnt, sollte man beim Support seines Hosting-Providers nachfragen, wie man seinen Webspace auf PHP5 upgraden kann. Und sollte das nicht gehen, denn sollte man sich so schnell wie möglich einen anderen Provider suchen.
Übrigens ist die Ausgabe von phpinfo() auch für jene Zeitgenossen recht interessant, die einen Webserver ownen wollen und deshalb brennend an Einzelheiten der Installation und an damit verbundene Schwachstellen interessiert sind. Das ist ein Grund, weshalb eine solche Datei nicht länger als unbedingt benötigt auf dem Server herumliegen sollte. Man muss ja niemanden zu »Experimenten« einladen. Also bitte diese Datei wieder löschen, wenn die offenen Fragen zu den Voraussetzungen geklärt sind!
Mit PHP5 allein ist es noch nicht getan. Ferner wird die curl-Bibliothek für PHP5 benötigt. Ob diese installiert ist, wird erfreulicherweise ebenfalls in der Ausgabe von phpinfo() angezeigt. Das sieht im günstigen Fall so aus:
Sollte eine derartige Sektion für die curl-Bibliothek von PHP fehlen (man kann einfach mit der Seite-durchsuchen-Funktion im Browser nach curl suchen), denn liegt ebenfalls ein Problem vor, das vom Hosting-Provider am Webserver behoben werden muss und sollte. Vermutlich kennt der Support das Problem bereits, WordPress wird ja doch öfter verwendet und die Twitter Tools sind ebenfalls sehr beliebt. Also keine Hemmungen, einmal freundlich beim Support anzufragen…
Im Regelfall, und das ist die erfreuliche Sache, sind diese beiden Voraussetzungen für die Lauffähigkeit des Plugins erfüllt.
Installation und Konfiguration
Der Upgrade des Plugins Twitter Tools geht so einfach wie jeder andere Upgrade auch. WordPress ist inzwischen so gereift, dass dabei meist keine Probleme mehr auftreten. Wer ganz sicher gehen will, lädt sich das aktualisierte Plugin herunter und lädt es wie gewohnt über FTP auf den Webspace hoch.
Die Schwierigkeiten beginnen für die meisten Menschen erst danach.
Statt der bisher leicht verständlichen Eingabe eines Benutzernamens und eines Passwortes sind nun vier Zeichenketten zu konfigurieren, die nicht unbedingt leicht verständlich sind. Das ist der schwierige und umständliche Teil, denn um an diese Zeichenketten zu gelangen, wird man als Blogger mit Dingen konfrontiert, die nicht zum normalen Benutzeralltag gehören. Es ist nämlich erforderlich, sein Blog als Applikation für Twitter zu registrieren – ein Verfahren von kaum zu überbietender Dämlichkeit für eine an sich einfache Funktionalität.
Hierzu wird zunächst die Registrierungsseite für eine neue Applikation aufgerufen – wenn man bereits in seinem Twitter-Account angemeldet ist, muss man sich wenigstens dort nicht noch einmal einloggen. Auf dieser Registrierungsseite sind einige Angaben über die »Applikation« zu machen, die an sich eher für Entwickler als für jene »einfachen Blogger« gedacht sind, die doch nur eine Verbindung zwischen ihrem Blog und ihrer Twitter-Timeline herstellen wollen. Natürlich ist das alles in Englisch gehalten, der lingua franca des Internet. Gut, dass es kein Chinesisch ist! Wir Freunde des lateinischen Alphabetes werden noch trüben Zeiten entgegengehen.
- Application Name
Hier sollte ein eindeutiger Name vergeben werden, also nicht so ein allgemeines Wort wie »Twitter Tools« oder der Name einer bereits registrierten Applikation. In vielen Fällen dürfte der Name des Blogs eine gute Wahl sein, und wenn dieser nicht eindeutig ist, kann er um weitere Angaben ergänzt werden. Dieser Name erscheint übrigens unter jedem Tweet als Angabe, mit welcher Applikation getwittert wurde, von daher empfieht sich nicht ein beliebiger »Zeichensalat«, sondern ein kurzer, prägnanter Text mit Wiedererkennungswert. Übrigens darf das Wort »Twitter« und das Wort »Web« nicht im Applikationsnamen enthalten sein, vermutlich sind auch weitere derart allgemeine Wörter blockiert.
- Description
Dieser Text wird zwar nicht in der Timeline sichtbar, ist aber eine Pflichtangabe. Er muss mindestens zehn Zeichen lang sein. Ich habe dort regelmäßig einen Hinweis hinterlegt, dass hier mein Blog twittert. Ich sehe diese Texte, wenn ich mir auf Twitter anschaue, welche Verbindungen ich freigegeben habe, und es gut, wenn ich hier schnell verstehe, welche Bedeutung die einzelnen Freigaben haben.
- Application Website
Die hier angegebene URL wird als Link für den angezeigten Namen der Anwendung in der Timeline verwendet, und deshalb ist es wohl in der Regel eine gute Idee, hier einfach die Adresse der Startseite des Blogs anzugeben.
- Organization
Wird nicht benötigt und kann einfach leer bleiben.
- Application Type
Die Voreinstellung »Browser« kann belassen werden. Gemeint ist eine Anwendung, die in einem Browser läuft, im Gegensatz zu einer Desktop-Anwendung.
- Callback URL
Hier einfach noch einmal die Adresse der Startseite des Blogs eingeben.
- Default Access type
Ganz wichtig: Als Voreinstellung ist hier »Read-only« ausgewählt, dies muss in »Read & Write« geändert werden, wenn Twitter Tools auch twittern soll. Ansonsten erhält das Plugin einfach nicht die Rechte, einen Tweet abzusetzen. Wenn dies vergessen wurde, kann es auch nachträglich geändert werden, aber typischerweise sucht man den Fehler an allen möglichen anderen Stellen.
- Application Icon
Vermutlich die überflüssigste Möglichkeit der Welt, wenn man Twitter Tools mit seinem WordPress-Blog verwenden will. Ein kleines Icon, das niemals in der Timeline (wohl aber in der Liste der freigegebenen Verbindungen auf Twitter) sichtbar wird. Zum Glück muss man keins hochladen, sonst würde ich hier ein angeschossen zu Boden sinkendes, blaugefärbtes Moorhuhn zum Download anbieten. 😉
Nun ist nur noch ein Captcha zu entziffern, was übrigens auch nicht immer eine leichte Übung ist. Nach dem abschließenden Klick auf »Register application« darf noch ein Fenster mit »I Accept« weggeklickt werden, in dessen überlangen Text man nebenbei seine Seele an Twitter verkauft; akzeptiert, dass Twitter für keine technischen Probleme irgendwie haftbar zu machen ist; mit gekreuztem Finger schwört, dass man die niemals richtig gelesenen Richtlinien von Twitter als verbindlich anerkennt und voller tiefverneigter Dankbarkeit das gnädig gewährte Privileg entgegennimmt, nun auch Twitter über die API benutzen zu dürfen. Früher hat es mal ein Username und ein Passwort getan… ach, lassen wir das! 
Nachdem man das getan hat, sieht man eine Seite für die neu angemeldete Applikation. Wenn man etwas runterscrollt, finden sich unter der Überschrift »OAuth 1.0a Settings« die beiden Zeichenketten für »Consumer key« und »Consumer secret«, die man am besten über das Clipboard in seine Twitter-Tools-Einstellungen in WordPress überträgt.
Danach ist man bereit, wieder etwas nach oben zu scrollen (jedenfalls, wenn man durch so ein kleines Bullauge ins Internet schaut, wie ich das tue – ein großer Monitor hat wohl weniger Scrollbedarf). Auf der rechten Seite neben den Angaben zur Applikation finden sich fünf weiße Links in himmelblauen Kästchen, was übrigens nicht gerade die Richtlinien für die Zugänglichkeit einer Website erfüllt. Der vierte Link von oben lautet »My Access Token«, dieser muss für die beiden verbleibenden Schlüssel geklickt werden. Dort werden die Zeichenketten für »Access Token« und »Access Token Secret« angezeigt, die wiederum am besten über die Zwischenablage in die gleichnamigen Felder in der Konfiguration der Twitter Tools übernommen werden.
Wenn die weiter oben genannten Voraussetzungen erfüllt sind, können diese Einstellungen in den Twitter Tools jetzt gespeichert werden, um die Verbindung zwischen Twitter Tools und Twitter herzustellen. Meistens war es das! Das Blog kann wieder twittern…
Probleme
Manchmal treten dennoch unerwartete Probleme auf, die drei am häufigsten gelesenen werde ich hier kurz erwähnen:
Parse error on line 19 of twitteroauth.php – die wahrscheinlichste Ursache für diesen Fehler ist, dass PHP4 verwendet wird. Der oben erwähnte Hinweis mit phpinfo() sollte diese Fehlerquelle eigentlich ausschließen. Ob der Fehler auch in einigen Versionen von PHP5 auftreten kann, weiß ich nicht; in jedem Fall hat der Hosting-Provider etwas zu tun.
Call to undefined function curl_init() – dieser Fehler geht immer darauf zurück, dass das PHP-Modul curl nicht zur Verfügung steht, auch dieser Fehler sollte mit dem Hinweis auf phpinfo() im Vorfeld ausgeschlossen werden.
Class ›OAuthSignatureMethod_HMAC_SHA1′ not found beim Versuch, sich mit den mühsam erworbenen Schlüsseln an Twitter anzumelden, ist hingegen ein Problem, das man nicht so einfach im Vorfeld ausschließen kann. Es handelt sich um ein PECL-Modul, das ebenfalls OAuth zur Verfügung stellt und bei einen Webservern geladen wird. Dieses Modul verträgt sich nicht mit Twitter Tools, und auch hier sollte im Zweifelsfall der Support des Hosters helfen.
Abschließendes
Ich kann nicht umhin, zum Schluss ein paar Worte Einsicht und Meinung (manche nennen das auch: Wirrheit) zu verbreiten.
Ich weiß nicht, was sich die Entwickler bei Twitter gedacht haben. Es ist ja nicht so, dass sie einen Kern ihrer bislang einfachen und sehr leicht verständlichen API umstellen würden und nebenbei erzwingen würden, dass viele Plugins und Anwendungen neu geschrieben werden müssen, nur weil man dort böse ist oder einen heimlichen Vertrag mit den Herstellern von Kopfschmerztabletten abgeschlossen hätte.
Vermutlich handelt es sich um die Kombination zweier Dinge: Große Pläne für die Zukunft Twitters, und große Probleme mit der von Spam und massenhaft geownten Accounts geprägten Gegenwart Twitters. Die Neigung vieler Twitter-Anwender, ihren Usernamen und ihr Passwort an andere Dienste rund um Twitter zu geben, um an gewisse Mehrwerte wie das Veröffentlichen von Fotos und kurzer Videoschnipsel zu gelangen, war schon sehr groß – und die Nachdenklichkeit darüber, dass man damit einem Fremden einen vollwertigen Zugriff auf das eigene Twitter-Konto ermöglicht, oft viel zu klein. Das neue Verfahren gibt kein Passwort mehr preis, und der Twitter-Anwender kann dennoch Rechte an seiner Timeline vergeben und auch wieder mit geringem Aufwand entziehen, wenn sich herausstellt, dass diese Rechte für Spam oder andere unerwünschte Aktivitäten missbraucht werden. In der früheren Version der API musste zu diesem Zweck das Passwort geändert werden, und wenn man einige Anwendungen mit Twitter-Schnittstelle benutzte, denn musste das Passwort in allen diesen Anwendungen geändert werden. Das ist schon eine gewisse Verbesserung der Sicherheit, denn es gibt die Kontrolle an den Anwender zurück. Natürlich wird sich dieses bessere Verfahren nur durchsetzen, wenn es auch erzwungen wird. Auch Programmierer sind faul (eine Charaktereigenschaft, mit der es die Menschheit übrigens weit gebracht hat) und werden immer den mühelosesten Weg gehen. Deshalb steht die alte API in ein paar Tagen nicht mehr zur Verfügung, und es steht zu hoffen, dass damit viele Hacks und die Flut der Spam eingedämmt werden.
Das nicht nur ein wenig umständliche Verfahren für die Twitter Tools zeigt, wie viel Aufwand hinter einem derartigen Feature steckt. Meistens läuft dieser Aufwand aus Nutzersicht im Hintergrund ab, wenn man einer Anwendung das Recht erteilt, auf Twitter zuzugreifen, hierfür zu Twitter weitergeleitet wird, dort die Rechtevergabe bestätigt und alles läuft reibungslos zusammen. Die Anwendung wurde von einem Techniker registriert, und die Schlüssel für die Anwenderrechte werden automatisch ausgetauscht. Im Falle eines selbst betriebenen Blogs mit Twitter Tools befindet man sich plötzlich in der ungewohnten Doppelrolle, nicht nur Anwender einer Twitter-Anbindung zu sein, sondern darüber hinaus auch die für eine derartige Anwendung technisch verantwortliche Person zu sein. Die Umständlichkeit des Verfahrens ist für diesen Sonderfall eine Schwäche, und diese für solche Sonderfälle in Kauf genommene Schwäche zeigt, dass das OAuth-Verfahren in erster Linie dafür gemacht wurde, wenigen zentralen Diensten eine gegenseitige Integration zu ermöglichen, während der gewöhnliche Websitebetreiber vor einer beachtlichen technischen Hemmschwelle steht. Der Websitebetreiber auf »eigene Faust« kommt in diesen modernen technischen Erwägungen nicht mehr vor, er ist marginalisiert und wird wie eine aussterbende Spezies behandelt, die so lästig ist, dass sich jede Rücksicht darauf verbietet. Wenn er bloggen will, soll er doch zu blogspot (punkt) com oder einen anderen zentralen Anbieter gehen – dort kann man sich beim Kommentieren übrigens prächtig und sehr einfach über seinen Twitter-Account, also über OAuth, authentifizieren. Es spiegelt sich in dieser Schwäche eine Tendenz des so genannten Web 2.0, den Menschen immer weiter die Verfügungsmöglichkeit über ihren eigenen Auftritt im Internet zu entziehen, um ihnen auf der anderen Seite eine bequeme Alternative in fremder und meist gewinnorientiert-wirtschaftlicher Hand anzubieten, von der sie im kaufmännischen Idealfall so abhängig wie nur möglich werden sollen.
Was am erstrebten Ende eines solchen Prozesses steht, ist nichts weiter als die Enteignung des user generated content jener in Abhängigkeit von zentralen Diensteanbietern gehaltenen user, die vor allem deshalb auch im deutschen Sprachraum eine community gerufen werden, weil dies Wort widerspiegelt, wie wenig Gemeinschaft in einem solchen Miteinander herrscht. Wer unter diesen Bedingungen noch eine eigene, selbstverantwortete Website ganz ohne die zwei Handvoll social buttons an jeder Stelle betreibt, muss sich sogar den Vorwurf gefallen lassen, altmodisch zu sein, einfach nur, weil er die Ideen der virtuellen Modeschöpfer des Web 2.0 nicht im vollem Umfang mitträgt, sondern auf persönlichen Wert abklopft und bei dabei erklingender Hohlheit und Wertlosigkeit auch verwirft. Manche sollen sogar ihre Häuser für Google Street View verpixeln lassen. Wie altmodisch diese Hinterwäldler doch sind!
Die modernen Menschen des Web 2.0 tragen voller kindischen Stolz ihre Produkte mit dem Apfel darauf und finden nichts weiter dabei, dass ihnen die Nutzungsmöglichkeiten einer derartigen Technik zentral und in bevormundender Weise eingeschränkt werden. Sie werden als die Sklaven des Web 3.0 enden. Und. Vermutlich jeden Gang zur Toilette twittern.
