Trillian: „Error logging into ICQ: Unknown code 27“

Wer derzeit Probleme mit dem Login bei ICQ hat, sollte beim IM Trillian mal die aim.dll austauschen.

Folgende Vorgehensweise:

  1. Neue aim.dll runterladen. Diese findet ihr hier.
  2. Trillian ausschalten
  3. Die dll aus dem Archiv auspacken.
  4. Die aim.dll in das plugin Verzeichnis von Trillian kopieren.
    Meist ist das sowas wie c:/programme/trillian/plugins
  5. Dort dann die alte mit der neuen aim.dll überschreiben.
  6. Trillian neu starten

Damit sollte die Fehlermeldung „Error logging into ICQ: Unknown code 27“ nicht mehr erscheinen.

Dynamischen Content mit jQuery an Events binden

Wow, was für ein komplizierter Titel, was?

Es geht um folgendes: Ich erstelle mit jQuery innerhalb eines Bereiches meiner Seite einen dynamischen Inhalt. Als Beispiel: Ich füge in einem Div ein paar Bilder ein, die ich via AJAX auf Knopfdruck lade.

HTML-Teil:

jQuery-Teil:

$(‚div#meinDiv‘).html(‚‚);

Diese Bilder sollen anschließend noch auf das Ereignis einen Klicks reagieren und dann einen neuen Dialog öffnen, wo es ein paar mehr Infos zu diesem Bild gibt … kann sich jeder was unter diesem Beispiel vorstellen? Okay!

Mein Problem war nun, dass ich mit einem simplen:

$(‚img.meineBilder‘).click(function()
{
console.log(‚*PING*‘);
});

Nicht an das gewünschte Ergebnis kam. Es geschah einfach gar nix 🙁

Nach langem stöbern im Netz nun endlich die Erlösung: Es geht doch, und zwar so (nachdem der dynamische Content eingefügt ist):
$(‚img.meineBilder‘).live(‚click‘, function()

{
console.log(‚*PING*‘);
});

Na also, geht doch …

json_encode wandelt Umlaute in null Werte um

Meine AJAX-Antwort enthält null-Daten. Nun, okay, nicht nur null-Daten, aber so ab und zu schon ein paar. Dumm nur, dass in der Abfrage, die hinter den Daten steht, eigentlich keine null-Reihen auftauchen; zumindest sehe ich an der passenden Stelle im phpMyAdmin sowas nicht. Woran liegt es nun?

Zum Ablauf meines AJAX-Requests:
1. Daten zum POST vorbereiten
2. Daten per jQuery.post zum Server POSTen
3. Daten werden auf dem Server verarbeitet, sprich, eine Abfrage an MySQL wird gestartet
4. Antwort wird per json_encode zurückgeschickt
5. Antwort wird per jQuery ausgewertet und angezeigt

Soweit, so gut. Nur in manchen Zeilen fehlen die Daten.
Okay, Firebug auf und den Request mal näher untersucht.
Meine POST Daten stimmen schon mal, also mal sehen, was der Server antwortet. Aha, in der Antwort liegen schon die null-Felder drin, also stimmt der php-Teil nicht.

Ein schnelles debug-printf auf dem Server kurz vor der Rückgabe zeigt mir an, dass die Abfrage und die Antwort stimmt. Na gut, dann habe ich den Fehler.

Die PHP-Funktion json_encode wandelt alle Strings mit Umlauten in null Daten um. In der Doku zu json_encode steht es ja auch:

Diese Funktion arbeitet nur mit UTF-8-kodierten Daten.

Ich muss also die Eingangsdaten der Funktion json_encode entsprechend UTF-8 konvertieren. Kein Problem, die Funktion utf8_encode hilft mir da weiter und siehe da: Nun funktioniert es wunderbar.

Wieder was gelernt.

PHP Scripte und die Rechtevergabe

Gestern hatte ich ein wirklich interessanten Fall. Ich sollte ein paar kleinere Fehler aus einer bestehenden – und laufenden – PHP-Datei ausmerzen. Gemacht, neue Datei hochgeladen und siehe da: „500 Internal Server Error“. Der absolute Supergau auf einem Live-System.
Die Lösung war dann doch seltsamer wie ich dachte und ist hier nach zu lesen: Techcrawler – PHP – PHP Scipte und die Rechte der Dateien

Zend und date … bitte nichts vergessen!

Das Zend Framework ist schon sehr lustig. Wir binden Zend mit Hilfe des Autoloaders in unser Projekt ein. Nun wollten wir auch mal einen Teil des Zend Frameworks benutzen – unsere Wahl fiel dabei auf Zend_Log – und was wir dabei so alles lustig in Zusammenhang mit date() erlebt haben – und auch wie wir dieses seltsame Verhalten dann behoben haben – findet ihr hier: Techcrawler – PHP – Zend Loader, date und ein komisches Problem dami.
Viel Spaß beim lesen …

Probleme mit Zend_Loader::autoload() ?

Ab dem Zend Framework 1.8 macht euch sicherlich der Aufruf von
Zend_Loader::registerAutoload()
große Probleme, denn ab dieser Version ist diese Fassung offiziell als „deprecated“, also veraltet, gekennzeichnet. Ein Versuch, eine Klasse aus dem Zend Framework so aufzurufen, wird in einem Scriptabbruch enden.
Die gute Nachricht: Es müssen nur wenige Zeilen in euren Scripten geändert werden, welche das sind, zeige ich euch hier: Techcrawler – PHP – Zend_Loader::autoload is deprecated

Wieder im Spiel

Ab dem ersten April stehe ich nun wieder – sehr zur allgemeinen Freude meiner kleinen Familie – wieder in Lohn und Brot. Bei einer “im kommen” befindlichen Firma im schönen Kerken (NRW) habe ich nun Platz in einem sehr freundlichen Team bekommen. Ich verstärke das Team nun mit meinem Fachwissen als ‘Anwendungsentwickler’.

Stressig ist es nur, dass ich nun bis Ende Juli erstmal jede Woche Sonntags einmal von Thüringen nach NRW muss und Donnerstags dann wieder zurück; jedes mal immerhin 480km pro Tour. Nur gut, dass ich bis dahin erstmal nur 4 Tage je Woche arbeiten muss – aber dafür halt 10 Stunden; ab September dann “normale” 5-Tage-Woche. So kann ich mich bis dahin erstmal Freitags auf meine Kinder freuen.