WordPress Autoupdate

Seit dem das Blog mal wieder auf einen neuen Server umgezogen ist habe ich das Problem, dass Updates von WordPress (egal ob WordPress selbst oder Plugins) zwar ein problemlos durch laufen, allerdings scheinbar dabei nicht wirklich aktualisiert werden. Resultat war dass ich letztenendes WordPress direkt über die Kommandozeile up2date gebracht habe und meine Plugins derzeit nicht vernünftig aktualisieren kann. Kann mir jemand sagen, woran das liegen bzw. wie ich es beheben kann? Wie gesagt – Fehlermeldungen gibt es gar keine – nur kein erfolgreiches Update am Ende (kann alles immer und immer wieder updaten).

Piwik-Bug bei Output-Compression

Nach dem Update von Piwik (eine OpenSource Software zum Erstellen von Besucherstatistiken auf Websites) auf die aktuelle Version 1.1.1 stellte ich fest, dass das Design vollständig zerschossen war und auch die JS-Dateien nicht mehr geladen werden konnten. Genauer: es wurde noch alles geladen allerdings enthielten all diese Dateien nur noch seltsam anmutende Zeichen. Ein genauerer Blick verriet, dass es sich hier um doppelt gepackte Serverausgaben handelte.

Da mein Server von sich aus alles komprimiert (per gzip) was auszugeben ist – inkl. aller von PHP generierten Inhalte, lag es nahe zu vermuten, dass Piwik selbst ebenfalls noch einmal zur Tat schreitet. In der zentralen Klasse „Piwik“ (core/Piwik.php) Zeilen 664 und 665 findet sich der Auslöser:

$zlibOutputCompression = ini_get('zlib.output_compression');
$phpOutputCompressionEnabled = !empty($zlibOutputCompression);

Hier wird offensichtlich nur eine von mehreren Möglichkeiten der Ausgabe-Komprimierung geprüft. Ergebnis: für alle anderen möglichen Einstellungen wird die interne Kompression im nachfolgenden else-Zweig aktiv und somit doppelt komprimiert. Um das zu umgehen habe ich meine eigene config mit geprüft – heraus gekommen ist nun folgendes:

$zlibOutputCompression = ini_get('zlib.output_compression');
$outputHandler = ini_get('output_handler');
$phpOutputCompressionEnabled = (!empty($zlibOutputCompression) || $outputHandler == 'ob_gzhandler');

Mit diesem Fix läuft Piwik jetzt für mich wieder problemlos.

Debian „Squeeze“(6.0) veröffentlicht

Heute Nacht wurde Version 6.0 der freien Linux Distribution Debian veröffentlicht [1], die unter anderem PHP 5.3.3 (vermutlich mit einigen Sicherheitspatches, die u.a. das Rechenproblem von PHP fixen – die auch in der offiziellen PHP Version 5.3.5 enthalten sind), MySQL 5.1.49, Apache 2.2.16 und lighttpd 1.4.28 enthält[2]. Neben zahlreichen Versionsupdates enthält der Standardkernel seit dieser Version keinerlei unfreie Bestandteile mehr[3], Intallations-Images die ohne proprietäre Bestandteile nicht auskommen wurden im „non-free“-Bereich angesiedelt, allerdings mit dem Hinweis, dass die Debian-Community deren Weiterentwicklung nicht gewährleisten kann, weil man hier auf die Anbieter der entsprechenden Bestandteile angewiesen ist.

In den nächsten Tagen werde ich meinen Server – dessen „Herz“ ebenfalls mit Debian schlägt auf Squeeze updaten, nachdem ich einige Tests vorgenommen habe um unerwünschte Nebeneffekte zu vermeiden.

Zeitgleich mit dem Release von Squeeze wurden die Internetseiten des Debian-Projektes vollständig überholt und erstrahlen nun in einem (wie ich finde) schönerem und modernerem Design

Quellen:
[1] Debian 6.0 “Squeeze” released
[2] Debian GNU/Linux 6.0 — Release-Informationen
[3] Debian 6.0 »Squeeze« wird mit vollständig freiem Linux-Kernel veröffentlicht

Update (18.02.2011):
Das Update des Servers ist jetzt erfolgreich und nahezu problemlos erfolgt.

Firefox 4 Beta 8 und WordPress

Nach langer Zeit mal wieder ein Post hier im Blog – mangels passender Themen (obwohl reichlich passiert ist). Ein Kunde von mir machte mich vor Kurzem darauf aufmerksam, dass scheinbar AJAX-Requests im WordPress Admin-Bereich nicht mehr funktionieren. Auf der Suche nach dem Fehler – bzw. beim Versuch den Fehler nachzuvollziehen fiel mir auf, dass das Problem scheinbar nur den Firefox (4, Beta 8) betrifft. Ein Test mit Chrome lief problemlos durch.

Jetzt stellt sich natürlich die Frage, was dieses Problem auslöst, ein Bug in der JS-Engine von Firefox 4 oder ein solcher in WordPress, der schlicht noch nicht aufgefallen ist. Hatte schon jemand einen ähnlichen Effekt?

PHP Tools Integration (PTI) für eclipse (PDT): „Project does not exist“

Nachdem mir gestern das – meiner Meinung nach äußerst sinnvolle – eclipse Plugin PHP Tools Integration (kurz PTI) begegnet ist, habe ich mich daran begeben es ein wenig zu testen. Schon deswegen weil es (für mich vor Allem anderen) in Sachen PHPUnit ein echter Fortschritt beim Arbeiten wäre. Einziges Problem dass ich bisher habe und was das Plugin für mich unbenutzbar macht: Wenn ich per Rechtsklick auf eine PHP-Datei „PHP Tools“ -> „PHPUnit“ -> „Create Test Case“ klicke, behauptet eclipse (oder viel mehr das Plugin) „Project does not exist“. Angemerkt sollte noch sein, dass ich mit Mac OS X arbeite, mit Windows habe ich das Tool bisher noch nicht getestet, von daher weiß ich nicht ob das Problem dort ebenfalls auftritt.

Meine Versuche das Problem zu lösen sind bisher sämtlich wenig glamourös gescheitert. Dazu zählten unter anderem:

  1. Festlegen des Source Folders auf einen absoluten (und nicht zum projekt relativen Pfad)
  2. Anlegen eines neuen Projekts (für den Fall dass die Standardprojekt-Einstellungen nicht mehr funktionieren)
  3. Einbinden von PHPUnit als eigenes Projekt und „verknüpfen“ des Testprojekts mit dem Projekt „PHPUnit“
  4. Die Tests sind sowohl mit der Entwickler- als auch der „normalen“ Version gelaufen – beide Versionen lieferten die gleichen ausbleibenden Erfolge
  5. Google mit vielfältigen Suchanfragen zu meinem Problem quälen – außer Lobeshymnen (zumeist von Entwicklern, die (den Screenshots nach) mit Windows arbeiten nichts gefunden

Bisher hoffe ich noch das Problem so beheben zu können, evtl. auch mit Hilfe des einen oder anderen Kommentars. Ansonsten würde ich im Moment noch auf einen Bug des Plugins in Verbindung mit Mac OS X. Solange das Problem jedoch noch nicht behoben ist PTI bisher leider für mich unbenutzbar

Über die Wahlen und ihre Folgen in Thüringen

„Was interessiert mich mein Geschwätz von gestern?“ Zumindest nach diesem Motto scheint Herr Matschie von der SPD in Thüringen zu verfahren. Wenn man den NachDenkSeiten glauben kann, hat es eine Aktion wie die, die Herr Matschie meint zur Wähler-Verarsche durchziehen zu müssen noch nie gegeben. Wie kommt jemand, der „erfolgreich“ am Projekt 18 – nur nicht für für die FDP sondern die SPD – gearbeitet hat dazu, für sich das Amt des Ministerpräsidenten als Bedingung für eine Koalition einzufordern? So viel Größenwahn und Wirklichkeitsverachtung in einer Person vereint zu sehen tut schon fast körperlich weh. Es ist ja nicht so, dass er vor den Wahlen das Ende der Ähra Althaus – oder viel mehr der CDU-Regierung in Thüringen gefordert und propagiert hätte … oder?

Jetzt gemäß dem Motto, wir wollten ja, aber „Die Linke“ hat sich gesperrt eine vollkommen irrsinnige Forderung als Grundlage für einen Regierungswechsel in Thüringen zu fordern ist prinzipiell nur genau zu einer Sache geeignet: Das Image der SPD als Verräterpartei (Google -> Suchwort „Verräterpartei“ -> „Auf gut Glück“) weiter stärken und möglichst viele Wahlberechtigte vor einem Kreuzchen am 27. September – und außnahmlos ALLEN folgenden Wahlen – bei einer anderen Partei oder gar nicht zu machen. Letzteres wird wohl leider eine der Hauptsächlichen Folgen sein. Schlussendlich ergibt sich eigentlich nur eines: Die SPD zu wählen ist nicht besser als gar nicht zu wählen, denn letztendlich ist alles was diese Partei in letzter Zeit getan hat darauf ausgerichtet ihre Macht zu erhalten – nicht mehr und nicht weniger. In dieser Form kann man der SPD eigentlich nur noch ihren Untergang wünschen – und dass dieser so schnell und (für die Bürger) schmerzlos wie möglich kommt.

Eigentlich kann man nur hoffen, dass das Gedächtnis (bezogen auf die Politik) der Deutschen sich diesmal nicht auf 4, bzw. 5 Jahre beschränkt. Leider schien das in den letzten Jahren ja so gewesen zu sein. Ich gebe durchaus zu, dass ich (immer noch) hoffe, dass „Die Linke“ ein Teil der Thüringer Regierung werden wird und diese Chance nutzt um zu zeigen, dass sie nicht nur in der Lage ist, Versprechungen zu machen sondern diese (anders als beispielsweise in Berlin) auch einzuhalten. Natürlich hat „Die Linke“ nicht die meisten Stimmen bei der Wahl bekommen. Doch die CDU soll (zumindest, wenn man daran glaubt, dass sich Prozente bei einer Wahl so deuten lassen) nach dem Wählerwillen auch nicht die von ihr propagierte Politik durchsetzen können. Aber genau das wird geschehen, wenn sich Matschie, gleich einer Dame aus dem ältesten Gewerbe der Welt der CDU gerade zu anbiedert um „endlich“ ins Regierungsbettchen zu kommen. Und natürlich wird er in diesem Zusammenspiel nicht auf den Posten des Thüringer Ministerpräsidenten bestehen. Bleibt also nur noch hoffen dass die (gewählte) eher linke Mehrheit im Thüringer Landtag ((SPD), Die Linke, Grüne) die Regierung übernehmen wird und damit den von Matschie propagierten Politikwechsel einleiten / vollziehen kann. Momentan bin ich aber aus den schon genannten Gründen sehr am Zweifeln, ob das wirklich passieren wird.

Um noch einmal kurz auf den Titel zurück zu kommen: Folgen der Wahlen wird es wohl keine geben – zumindest keine spürbaren – solange Herr Matschie so derart unwillig ist, eben diese zuzulassen. Und den schwarzen Peter hierfür den Linken in die Schuhe zu schieben versucht (Gemäß dem Motto: „Ihr hättet mich ja nur zum Ministerpräsidenten wählen müssen …“).

Auf der Suche nach einer funktionierenden SSL-Konfiguration

Nachdem ich mich bereits seit längerer Zeit darüber geärgert habe, dass die SSL-Zertifikate meines Servers ständig aus zwei Gründen abgelehnt werden, habe ich mich daran gesetzt zumindest einen dieser Gründe zu beseitigen. Der Grund, den ich nicht beseitigen werde ist, dass das Zertifikat von mir selbst signiert wurde. Da ich im Moment weder das Geld habe noch die Lust dazu verspüre, mir ein CA-Zertifikat zu kaufen, werde ich das auch zunächst mal nicht ändern. Der andere Grund bezieht sich auf den Websitenamen selbst. Dieser ist laut Fehlermeldung nämlich auch ungültig – stimmt leider, da bisher nur das Zertifikat ausgestellt für die Domain „bytwo.de“ verwendet wird.

Dazu sei gesagt, dass es sich bei meinem Webserver um einen lighty (lighttpd) in seiner aktuellen Version unter Debian Lenny handelt (Version: lighttpd-1.4.19). Leider habe ich bisher noch keinen Weg gefunden dieses Problem zu beheben. Klar – Zertifikate für unterschiedliche Domains einrichten ist kein Thema und auch schnell gemacht, ABER das ist auch nicht mein Problem, sondern die Tatsache, dass er scheinbar die Definition für die Zertifikate nicht anerkennt. Soll heißen ich habe eine globale Definition á la:

$SERVER["socket"] == "87.118.116.10:443" {
ssl.engine = "enable"
ssl.pemfile = "/pfad/zum/zertifikat.pem"

In der Host-Konfiguration (innerhalb des $SERVER[„socket“]-Blocks) lässt sich dieser Pfad allerdings nicht mehr überschreiben. Zumindest hat sich der Lighty generell verweigert, das entsprechende Zerfikat zu verwenden und stattdessen immer wieder das „Standard“-Zertifikat verwendet. Ich weiß nicht ob es sich hierbei um einen Bug im Lighty handelt oder ich einfach nur zu doof bin die Konfiguration richtig hinzubiegen und da ich aktuell an dieser Stelle fest hänge wäre ich über jedwede Hilfe bei diesem Problem sehr dankbar.