Via OnSwipe wieder zu Google-Analytics

Ich habe mir eben mal das WordPress Plugin Onswipe angeschaut. Damit ist es möglich, ein WordPress Blog auf dem iPad fast wie eine native App zu bedienen. Man navigiert per Wisch-Geste von einem Artikel zum nächsten. Das sieht alles erstmal recht hübsch aus.

Allerdings stieß ich auf etwas seltsames: Blättert man von Artikel zu Artikel, wird vom Webserver bis auf die Grafiken, die in den Artikeln eingebettet sein können, nichts mehr abgerufen. Ich war nämlich auf der Suche nach einer passenden Stelle, an der ich meinen Piwik-Code einbetten kann. Da ich ad hoc nicht fündig wurde, schaute ich mir mal an, was da so am Webserver ankommt und was vom iPad abgerufen wird. Letzteres machte ich unter Verwendung des mitmproxy.

Statt auf dem Webserver wurde ich dann im mitmproxy-Protokoll fündig: Da tauchten plötzlich Abrufe bei Google-Analytics auf. Diese hatte ich aber auf meiner Seite schon vor einiger Zeit deaktiviert. In der Konfigurations-Seite des onswipe-plugins hatte ich auch keine UA-id von Google-Analytics hinterlegt.

Also woher kommt diese Anfrage?

Zu Beginn eines Requests lädt der Browser die folgende Javascript Bibliothek:

http://cdn.onswipe.com/reader/reader-1.1.0.min.js

Sucht man darin nach dem Google-Analytics Account UA-24076211-1, den man vorher gefunden hat, so wird man fündig.

a.prototype.initAnalytics = function () {
            console.log("init GA"), $("head").append("ttt<script type="text/javascript">ttt  var _gaq = _gaq || [];ttt  _gaq.push(['_setAccount', 'UA-24076211-1']);ttt  _gaq.push(['_setDomainName', '" + window.location.hostname + "']);ttt  _gaq.push(['_setAllowLinker', true]);tttttt  " + (this.state.analytics.googleAnalyticsID ? "ttt  _gaq.push(['b._setAccount', '" + this.state.analytics.googleAnalyticsID + "']);ttt  _gaq.push(['b._setDomainName', '" + window.location.hostname + "']);ttt  _gaq.push(['b._setAllowLinker', true]);ttt  " : "") + "ttt  " + (this.state.analytics.googleAnalyticsInternalID ? "ttt  _gaq.push(['c._setAccount', '" + this.state.analytics.googleAnalyticsInternalID + "']);ttt  _gaq.push(['c._setDomainName', '" + window.location.hostname + "']);ttt  _gaq.push(['c._setAllowLinker', true]);ttt  " : "") + "ttt  (function() {ttt    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;ttt    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';ttt    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);ttt  })();ttt</script>ttt");
            if (this.state.analytics.omnitureAnalyticsJS) return console.log("init Omniture " + this.state.publisher.publisher_username), $("body").append(this.state.analytics.omnitureAnalyticsJS)
        }

Wie man sieht, trackt Onswipe.com via Google-Analytics jedes Blog mit, das dieses Plugin einsetzt. Ich habe auf der Homepage des Plugins keinerlei Hinweise dazu gefunden.

Erfahrungen aus dem Einsatz von https-everywhere

Seit einigen Tagen setze ich das Firefox-add-on HTTPS-Everywhere ein, um automatisch auf die verschlüsselte Variante einer Website zuzugreifen.
Das funktioniert auch sehr gut, doch bin recht erstaunt, an wievielen Stellen ich nun Warnungen erhalte, dass Seitenbestandteile bzw. Zielseiten nicht verschlüsselt sind.

Man sieht dies zum Beispiel an den Seiten von WordPress.org. Diese sind auch via https erreichbar. Doch nutzt man die Suche der Seite, so werden diese Anfragen unverschlüsselt verschickt. Das mag in diesem Fall ziemlich harmlos sein, macht aber deutlich, dass es nicht einfach damit getan ist, „noch ’nen https-Prozess aufzusetzen“.

WordPress 3.3 verfügbar

Seit heute ist ein neues Update von WordPress verfügbar. Das Upgrade selbst verläuft ziemlich harmlos, wenn man sich an die sehr gute Dokumentation hält.

 

 

zerschossene Seitenleiste

An Neuerung fällt mir zunächst eine etwas zerschossene Seitenleiste auf, in der man das Format wählen kann. Diesen Effekt beobachte ich sowohl im aktuellen Firefox 8.0.1 wie auch im ebenfalls aktuellen Chrome 15.

Ich hatte zunächst gecachete CSS-Dateien im Verdacht. Aber ein Leeren des Caches brachte hier auch keine Verbesserung. Allerdings kann ich mit diesem Darstellungsproblem leben.

Ein wichtiger Punkt für Blogs, an denen mehrere Autoren beteiligt sind, ist die Neuerung, dass man nun wohl erkennen kann, wenn ein anderer Autor einen Artikel gerade bearbeitet.

Unter der Motorhaube hat sich auch einiges getan.  Einen absoluten Zwang zum Update sehe ich nur darin begründet, dass zukünftige Sicherheitslücken hier schnell behoben werden, die alten Versionen aber angreifbar bleiben werden.

Google +1 WordPress Plugin

Die ganze Diskussion um die Datenschutzprobleme von Facebooks I like it Button hat mich nun dazu bewogen, mal einen Blick in die Google Webmaster Tools zu werfen, um zu sehen, ob denn irgend jemand mich „geplus-einst“ hat. Das Ergebnis war doch sehr ernüchternd. Daher ziehe ich nun als Konsequenz den Stecker (zumindest, was dies anbelangt, nicht beim Bloggen selbst 😉 ) und deaktiviere wieder das von mir genutzte Plugin wp-plus-one.

iOS WordPress App

Ich nutze auf meinem iPhone regelmäßig die WordPress App hauptsächlich, um eingegangene Kommentare freizuschalten. D.h., wenn ich ehrlich bin, nutze ich sie häufiger, um die eingegangenen Kommentare als Spam zu markieren 🙁

Und hier kommt auch gleich meine Kritik an der neuen Version zum Tragen. Früher war es so, dass man über die App alle Kommentare erreichen konnte. Nun ist es aber so, dass man nur noch die neuen oder freigeschalteten Kommentare erreicht. Hat man einen aber versehentlich als Spam klassifiziert, so kann man ihn nun nicht mehr über die App freigeben.

WordPress-Darstellung auf dem iPhone

Auch wenn der Safari auf dem iPhone auch normale Webseiten recht gut darstellt, lässt sich eine Seite natürlich für die Darstellung auf solchen mobilen Geräten noch optimieren.

Für WordPress gibt es eine sehr schöne Erweiterung: WPtouch heißt das Plug-in. Unter http://svn.wp-plugins.org/wptouch/ findet man das Subversion Repository dazu.

Wenn man dann dieses Plug-in aktiviert, wird die Darstellung für das iPhone dahingehend optimiert, dass zum Beispiel der Text genau auf der Bühne angezeigt wird und man nicht horizontal scrollen muss.

Update Day bei wordpress

Gestern kam sowohl bei WordPress eine neue Version heraus, als auch bei dem von mir verwendeten Theme Suffusion.

WordPress ist nun in der Version 3.1 erhältlich.

Nachdem ich nun diese Updates nachgezogen habe, habe ich einen kurzen Blick auf meine Seiten geworfen. Soweit scheint wohl alles zu funktionieren.

Die Administrationsseiten scheinen nun etwas anders auszusehen. So hat der Dialog zum Verlinken nun nicht mehr dieses Selectbox zum Auswählen des Targets, die sich nie per Tastatur bedienen ließ. Stattdessen ist es nun einfach eine Checkbox  (vgl. Bild).

Ansonsten werden die nächsten Tage sicherlich noch die eine oder andere Merkwürdigkeit an den Tag legen. Seien wir gespannt.

Erste Erkenntnisse

Ich habe heute erste Schritte zur Anaylse unternommen:

Zunächt habe ich wie vom Provider vorgeschlagen den swap-Speicher komplett deaktiviert. Ich dachte mir aber schon, dass dies keine gute Idee sein kann. Der Apache konnte dann erwartungsgemäß keine Child-Prozesse mehr forken.

Also habe ich mich daran gemacht, den Apache und PHP selbst zu kompilieren. Erstes lief straigt forward durch. Bei PHP musste ich dann aber schon anfangen zu tricksen. Ich merkte schon, dass das Compilieren recht lange dauerte. Ein kurzer Blick ins laufende

vmstat 1

zeigte auch gleich, wohin der Hase läuft. Auch hier war der Kernel mächtig am Swappen. Es kam sogar soweit, dass der Vorgang abbrach, weil der virtuelle Speicher ausging.

Nun gut. Ich habe also erstmal ein zusätzliches Swap-File angelegt. Das ist zwar nicht performant. Davon war ich aber sowieso schon meilenweit entfernt. Nach gefühlten Ewigkeiten war PHP dann doch glücklich compiliert. Voller Hoffnung startete ich diesen Apache. Doch leider zeigte sich hier das gleiche Schreckensbild.

Ein paar kurze Versuche mit simpleren php-Skripten ließen ein etwas besseres Bild. Die Frage ist daher, ob vielleicht WordPress nicht ein Hauptgrund ist. Da aber ja auch das Compilieren von PHP zunächst auf die Bretter ging, denke ich, dass einfach der Hauptspeicher von 128MB für diesen virtuellen Server zu klein. Das Verrückte ist, dass auf meinem alten virtuellen Server diese 128MB völlig ausreichen sind. Vermutlich ist der Wechsel von 32-Bit auf 64-Bit, die leider nicht vorher zu erkennen waren, der Grund für diesen Speicherhunger.

Als Notmaßnahme habe ich nun erstmal die Anzahl der Apache Prozesse auf 2 (in Worten zwei) zurückgeschraubt!

Mal schauen, was aus meiner Support Anfrage wird. Ich sehe zwei Alternativen. Entweder ich gehe zurück auf den alten Server. Dort habe ich zumindest schon die aktuellen Orte der Debian-Quellen eingetragen. Oder aber ich stelle um auf mehr Hauptspeicher. Mit nur 128MB ist aber dieser Server aus meiner Sicht nicht zu gebrauchen.

Ein Umzug

Nach nun recht langer Ruhe auf diesem Blog, habe ich mich dazu entschlossen, mal was neues auszuprobieren:

Ich habe auf WordPress umgestellt. Aber nicht nur das. Ich habe dies zum Anlass genommen, auch meinen virtuellen Server, den ich bei vollmar.net angemietet habe, zu aktualisieren.

So habe ich also mich die letzten Tage damit befasst, den neuen Server einzurichten, um dann WordPress zu installieren. Dies geht auch recht zügig — aber dann…

Ich machte mich zunächst an den Import der alten Meldungen – samt Kommentare. Das war meine Vorgabe. Und siehe da, mit ein bisschen Stöbern klappte das recht gut.

Der nächste Schritt war die Layout-Anpassung. Da muss ich gestehen, habe ich (zunächst) den Stecker gezogen. Um mein altes Layout zu übernehmen, hätte ich doch zu sehr in die Materie eintauchen müssen. Also habe ich das erstmal zurückgestellt.

Nach dem Umschalten war die Entäuchung erstmal ziemlich gross. Grottenlahm war der Auftritt. Bei jedem Request swappte das System munter vor sich hin. Was hatte ich geändert?

  • Statt Apache 1.3 ist’s nun ein Apache 2.2
  • Statt selbst-compiliert nun das Debian Paket
  • Statt MySQL 4 nun MySQL 5
  • Statt selbst geschriebenes CMS WordPress

Ich stellte sehr schnell fest, dass der Apache viel Speicher fraß und ihn nicht mehr hergab. Also habe ich erstmal die Ressourcen dort begrenzt. Weniger Prozesse, weniger Keep-alive. Schön finde ich es nicht. Aber es tut’s erstmal. Vielleicht baue ich mir dann doch nochmal einen eigenen Apache samt eigenem php….

Was das Layout betrifft, so werde ich mich sicherlich damit auch noch befassen, zunächst muss es aber erstmal ein Standard Theme sein.