TiddlyWiki und neuere Firefox-Versionen.

Heute gab beim Aktualisieren der deutschen Übersetzungsdatei für TiddlyWiki eine ärgerliche Situation: Die TiddlyWiki-Datei, aus der die Übersichtsseite für die Übersetzung besteht, ließ sich nach dem Editieren nicht mehr mit Firefox speichern. Alles, was ich probierte, schlug weitgehend fehl, so dass ich dann in meiner Verzweiflung sogar kurzzeitig Google Chrome anwerfen musste, um überhaupt die Übersetzungsdatei online zu bekommen.

Da dieses Problem mit Firefox offenkundig laut einigen Kommentaren immer häufiger auftritt, habe ich mich mal eingehender mit dem Thema beschäftigt, leider mit einem eher unbefriedigenden Ergebnis.

Fakt ist wohl leider, dass Firefox mit eigenen Bordmitteln und auch mit dem TiddlySaver.jar (der auch dann nur funktioniert, wenn eine Java-Runtime-Umgebung installiert ist) insofern nicht mehr korrekt arbeitet, als dass das Speichern nicht mehr möglich ist, ich vermute aus Sicherheitsgründen, was allerdings unbestätigt ist. Diverse Tricks mit der prefs.js von Firefox funktionieren nicht, zumindest nicht bei den hier getesteten Firefox-Versionen 17 und 18.

Damit ist das Thema TiddlyWiki mit Firefox leider ein deutliches Stück umständlicher geworden, denn Abhilfe schafft nur ein Firefox-Plugin namens TiddlyFox. Das ist von Jeremy Ruston, dem Macher von TiddlyWiki, geschrieben und gepflegt und muss in jeden Firefox installiert werden, mit dem TiddlyWiki-Dateien bearbeitet werden können sollen. Zum reinen Anschauen ist das Plugin also nicht erforderlich, sondern nur für die Fälle, in denen TiddlyWiki-Dateien auch wieder gespeichert werden sollen. Wie gesagt … ärgerlich, weil damit die eigentlich ganz hübsche Autonomie von TiddlyWiki-Dateien zumindest mit der Nutzung von Firefox als Webbrowser hops geht, dennoch ist Firefox immer noch eine Empfehlung wert, dann nun eben mit der Plugin-Krücke.

Wer mehrere Firefox-Installationen auf verschiedenen Rechnern betreibt, muss also leider überall dafür sorgen, dass das TiddlyFox-Plugin in jeder Installation installiert wird. Alternativ gibt es hier die Möglichkeit, mit Mozilla Sync zu arbeiten, das sorgt nämlich seit einiger Zeit auch dafür, dass neben Lesezeichen und Browser-Einstellungen auch eventuell installierte Plugins mit anderen Installationen des gleichen Accounts synchronisiert.

Reparieren der defekten Kalender-Minianwendung unter Windows 7.

Dinger gibt es, da fasst man sich wirklich gelegentlich an den Kopf. Beispielsweise begrüßte mich heute morgen mein Windows-Desktop folgendermaßen in der Sidebar. Man beachte das orangefarbene Kalenderblatt, das normalerweise das aktuelle Datum anzeigt.

Kurzum, es hat nichts geholfen, was man akut in solchen Fällen machen würde: Minianwendung entfernen, den sidebar.exe-Prozess abschießen, Benutzer abmelden, Rechner neu starten. Es hätte übrigens, wenn man sehr auf Schmerzen steht, auch nicht geholfen, in der allergrößten Paranoia Windows neu aufzusetzen. Denn wenn der folgsame Benutzer dann irgendwann, nach einem Tag Windows-, Service-Pack- und Hotfixes-Installieren letztendlich den Internet Explorer 9 installiert hätte, wäre das Problem wieder aufgetaucht – der Internet Explorer 9 scheint nämlich das Problem zu verursachen. Wie genau er das schafft? Keine Ahnung, direkt nach der Installation funktionierte die Kalender-Minianwendung zumindest noch. Dass die Minianwendung zumindest mit dem Internet Explorer verbandelt sein könnte, lässt sich daraus schließen, dass die Windows-Minianwendungen in Wirklichkeit keine echten Programme, sondern Widgets sind, also in JavaScript gescriptete Anwendungen. Und dazu bedient sich Windows eben dem Internet Explorer bzw. dessen JavaScript-Umgebung.

Der Fix von Microsoft

Das Problem mit der nicht funktionierenden Kalender-Minianwendung scheint so häufig aufzutreten, dass es im Support-Bereich von Microsoft sogar schon einen Knowledge-Base-Artikel dazu gibt, inklusive einem Hotfix. Dieser Hotfix besteht dabei aus einer Anwendung, die lediglich einen Eintrag in der Windows-Registry abändert, der den Fehler verursacht.

Sprich: Auf der obigen Seite mit dem Knowledge-Base-Artikel gibt es weiter unten einen Button zu einer „Fix-it“-Anwendung. Diese Datei herunterladen, auf dem betreffenden Windows-7-Rechner ausführen, Windows neu starten und dann sollte die Kalender-Minianwendung wieder das aktuelle Datum anzeigen.

Manchmal kann man über so manch Windows-Problem und dessen Lösung nur staunen. Und das vor allem deshalb, weil das so eine Kategorie von Problemen ist, wo man ein halbes Wochenende darüber brüten könnte, wenn man nicht sofort mal eine Suchmaschine des Vertrauens damit betraut, Lösungen zu suchen.

Kleine Entwarnung in Sachen Kontakte-Sync via Google Contacts.

Nur der Form halber: Blog-Leser Benjamin (danke nochmal!) hat die Meldung durchgegeben, dass die vor einigen Tagen beschriebene Problematik der falschen Geburtstage bei der Synchronisation zwischen Google Contacts und synchronisierenden Gerätschaften wie z.B. dem iPhone nun behoben sind. Ich habe mich da auch nochmal im Google-Forum informiert, so dass nun sicher ist, dass seit Mittwoch die Synchronisation wieder korrekt läuft und Geburtstage nicht mehr verfälscht werden.

Es darf also wieder munter synchronisiert werden, wobei die Arbeit, jetzt mal alle Geburtstage manuell zu prüfen, erst anfängt. Man glaubt es nicht, was man für ein Geschäft mit Adressen und Kontaktdaten haben kann. Echt wahr.

Achtung! Akutes Problem mit der Synchronisation von Kontakten zwischen iPhone und Google Contacts.

[Update 6. August 2010] Das Problem ist inzwischen von Seiten Googles behoben worden, siehe auch hier: Kleine Entwarnung in Sachen Kontakte-Sync via Google Contacts.

Die Blog-Leser und Kommentatoren Steve und Benjamin haben mich zu meinen Artikel zur Einrichtung der Synchronisation von Kontakten zwischen iPhone und Google Contacts darauf hingewiesen, dass es offensichtlich einen bösen Bug gibt, den ich so auch nachvollziehen kann. Kurz umrissen:

Synchronisation zwischen iPhone und Google Contacts funktioniert. Auf dem iPhone wird eine Adresskarte geändert, beispielsweise eine neue Telefonnummer hinzugefügt. Nach dem Abspeichern synchronisiert das iPhone ordnungsgemäß via Google Sync mit Google Contacts. Nun ist jedoch bei Google Contacts das Geburtsdatum um einen Tag in die Vergangenheit verschoben. Auf dem iPhone scheint das Datum auch nach dem übernächsten Synchronisieren weiterhin korrekt zu bleiben.

Dummerweise kaskadiert das Problem jedoch, wenn nun jemand in Google Contacts die betroffene Adresskarte öffnet und dort in guter Absicht etwas an den hinterlegten Daten ändert und übersieht, dass das Geburtstagsdatum falsch ist. Denn speichert er die veränderte Adresskarte ab, wird das falsche Geburtstagsdatum natürlich auch abgespeichert und der Kontakt zur Synchronisation freigegeben, so dass die Adresskarte beim nächsten Synchronisieren die Inhalte auf dem iPhone überschreibt und das Geburtstagsdatum dann ebenfalls abändert. Wird nun danach auf dem iPhone die Adresskarte nochmals bearbeitet und wieder synchronisiert, schiebt sich das Geburtstagsdatum auf diese Weise Tag für Tag in die Vergangenheit.

Laut einem Thread in einem Google-Forum ist das Problem bekannt und wurde bereits für das iPhone-OS 3.0 gefixt, tauchte aber unter iOS 4.0 wieder auf. Im obigen Link, das auf den aktuellsten Teil des Threads führt, ist das Problem am 23. Juli 2010 auch für iOS 4.0 gefunden und wird im nächsten Update von Google Contacts gefixt. Wann das Update stattfinden wird, wird allerdings leider nicht gesagt.

Das Problem kann man so lange leider nur dadurch umgehen, in dem man bis auf weiteres konsequent darauf achtet, Kontakte nur auf dem iPhone anzulegen bzw. bestehende Kontakte auch nur dort abändert. Und für eine Übersicht über die bevorstehenden Geburtstage sollte man derzeit dann eben eher nicht auf Google Calendar vertrauen, sondern nur auf den Kalender im iPhone.

Vom ungefragten Deaktivieren ungefragter Add-Ons.

Wer am Samstag unter Windows seinen Firefox angeschmissen hatte, hat sich möglicherweise über die Meldung gewundert, dass Firefox im Begriff war, zwei installierte Add-Ons zu deaktivieren.

Es handelt sich hierbei um eine Erweiterung namens “Microsoft .NET Framework Assistant 1.1”, die nichts anderes macht, als die installierte Version des .NET-Frameworks an den Webserver zu übermitteln und um das Plugin namens “Windows Presentation Foundation”, das immerhin schon etwas wichtiger ist, ebenfalls zum .NET-Framework gehört, und, in sehr einfachen Worten umfasst, einen Baukasten bereitstellt, um Benutzeroberflächen abzubilden.

Das Unniedliche an der Geschichte dieser zwei Module ist, dass sie Microsoft dem Firefox weitgehend ungefragt unterjubelt, wenn der Benutzer das .NET-Framework installiert oder aktualisiert, beispielsweise mit einem Service Pack. Installiert man das Framework bzw. das Service Pack, befinden sich diese beiden Module danach in der Firefox-Installation – ohne dass der Benutzer das irgendwie steuern könnte.

Hübscherweise ist Microsoft bei der Idee, diese beiden Module dem Browser unterzujubeln, kurzfristig offenbar den alten, herrschaftlich veranlagten Zeiten verfallen und hat gar nicht daran gedacht, dass ein Benutzer das vielleicht gern wieder deinstallieren würde: Die im Firefox implementierte Deinstallationsfunktion für Add-Ons wurde von Microsoft für diese beiden Add-Ons einfach außer Kraft gesetzt.

Dieser gequirlte Mist – von Seiten Microsofts für diese Aktion und auch von Seiten der Firefox-Macher für so einen architektonischen Schnittstellenpfusch – hat sich nun gerächt, da über diese Module eine aktuelle Sicherheitslücke des .NET-Frameworks ausgenutzt werden könnte. Und deshalb haben sich die Firefox-Macher nach Rücksprache (!) mit Microsoft dazu entschlossen, diese beiden Module, wiederum ungefragt, zu deaktivieren. Informiert hat natürlich keiner von beiden und so muss der geneigte Interessierte das entweder aus dem Heise-Ticker lesen oder dumm sterben.

Mal so die Frage am Rande, gerichtet an Microsoft und an die Firefox-Macher: Was glaubt ihr Helden eigentlich, wem der Computer hier auf dem Tisch gehört, auf dem ihr hier eure Schlampereien ein- und ausschaltet, wie euch gerade der Rotz aus der Nase tropft?

Lösung zweier latenter WordPress-Probleme.

Ich kann es nur wiederholen – ich mag die Folks von WordPress Deutschland, sie machen ihren Job einfach klasse. Heute gibt es nämlich zwei Lösungsansätze für zwei WordPress-Problemchen, die zwar nicht wirklich schädlich, aber nervig sind.

Zum einen die Problematik mit dem Ping und der zu kurzen Timeout-Zeit, zu der es leider nach wie vor keine Lösung gibt, so dass man die Timeout-Zeit in der betreffenden Datei manuell hochsetzen sollte. Dass dieses Problem nach wie vor existiert, hatte ich vor einigen Tagen selbst bemängelt. Ich verstehe bei solchen Dingen die WordPress-Entwickler manchmal nicht – warum machen die für solche Dinge nicht einfach einen Schalter in den Optionen und gut ist? Soll doch bitte jeder selbst entscheiden, ob er Performance oder Zuverlässigkeit haben möchte. Mannometer…

Zum anderen die Problematik, dass heute morgen selbst bei frisch upgedateten WordPress-Installationen die Meldung erscheint, dass „WordPress 2.8 verfügbar“ sei. Das liegt leider schon wieder/immer noch daran, dass es neben wordpress-deutschland.org (den „Guten“) noch de.wordpress.org (die „weniger Guten“) gibt und eine WordPress-Installation per default letzteres abfragt. Leider stellen sich die WordPress-Entwickler auch hier noch auf taube Ohren. Dabei wäre es endlich mal Zeit, zu begreifen, dass die Folks, die sich unter de.wikipedia.org de.wordpress.org verstecken, die eigentlichen Protestler waren, die wirklichen Sprachdateienpfleger aber unter WordPress Deutschland hausen und auch die bessere Arbeit machen.

Bugfixing in TiddlyWikiDeutsch.

Schon seit einer ganzen Weile habe ich mit meiner TiddlyWiki-Übersetzung das Problem, das diese zwar fast überall funktioniert, nur nicht richtig im Internet Explorer. Dort wird beim Aufruf einer TiddlyWiki-Datei mit ebendieser Übersetzung der Plugin-Manager aufgerufen, der rot-warnend auf Fehler hinweist. Da nun auch zwei Nutzer diesen Fehler in Mails beschrieben habe, habe ich dieses Problem mal näher analysiert und auch gefixt.

Das Problem ist das Komma ganz am Ende der Zeile 437 in der Übersetzungsdatei. Das darf dort nicht sein, weil nach dieser Zeile schon die endende, geschweifte Klammer kommt, die die Funktion abschließt.

Sprich: Entweder in dieser Zeile das Komma entfernen oder auf TiddlyWikiDeutsch gehen und die Version GermanTranslation2.4b ziehen und ins eigene TiddlyWiki installieren.