Kategorie-Archiv: Technisches

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

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.

JavaHL und Mac OS X

Teilweise war es für mich ebenso ein Problem unter Mac OS X eclipse (eigentlich das subclipse-Plugin) zum Laufen zu bekommen, wie unter Windows. Dieses „Problem“ ergab sich daraus, dass ich jedes mal wieder aufs Neue die entsprechenden Installationsquellen suchen musste. Gut, das könnte man auch damit begründen, dass ich einfach nur zu faul war die entsprechenden Seiten zu bookmarken 😉 (ist auch teilweise richtig). Inzwischen habe ich jedoch einen schöneren Weg gefunden – er heißt: MacPorts.

Die nötigen Binaries um Mac Ports zu installieren bekommt ihr hier: macports.org

Neben dem durchaus angenehmen Vorteil, über diese Quelle einige weitere Portierungen für Mac OS X aus der Linux-Welt zu bekommen (zum Beispiel wget) kann man sich hierüber auch die nötigen Pakete zur „reibungsfreien“ Benutzung der JavaHL-Schnittstelle von subclipse installieren. Und zwar folgendermaßen:

sudo port install subversion subversion-javahlbindings

Nach Abschluss dieser Installation (und natürlich vorheriger Installation des subclipse-Plugins in eclipse) steht der Verwendung von JavaHL nun nichts mehr im Wege.