Howto: FirePHP mit ZendFramework nutzen ♥

16. Februar 2010

Als ich FirePHP das erste mal gesehen hab, hab ich mich sofort verliebt :-)

Es ist genau das was ich schon immer für die Arbeit mit PHP gesucht hab. Ich habe eine Variable und möchte sehen was drin steht, mit FirePHP kommt das nicht mehr schlecht lesbar auf der Website raus, es landet direkt schön formatiert in meiner FireBug-Konsole :-) Fürs ZendFramework gibt es sogar einen Datenbank-Profiler.

Hier eine kurze Anleitung wie es sich mit ZendFramework verwenden lässt:

Als erstes braucht man die FirePHP-Extension. Sobald die installiert ist, landen alle Debug-Ausgaben von Seiten, die FirePHP nutzen in der Firebug-Konsole.

Im ZendFramework ist eigentlich schon alle vorhanden, was man braucht. FirePHP funktioniert nämlich ganz einfach mit Zend_Log.

In der Bootstrap.php der ZendFramework Application fügen wir eine neue Methode ein:

protected function _initDebug()
{
    if (APPLICATION_ENV == 'development')
    {
        // Firephp
        $logger = new Zend_Log();
        $writer = new Zend_Log_Writer_Firebug();
        $logger->addWriter($writer);

        Zend_Registry::set('logger', $logger);
    }
}

Da Zend_Log von sich aus die dump()-Methode von FireBug nicht unterstützt, habe ich Zend_Log ein bisschen extended:

class Mylib_Log extends Zend_Log
{
    const DUMP = 'DUMP';

    /**
    * bildet das Verhalten von FireBUG->dump() nach.
    * @param variable
    * @param variablenname optional
    */
    public function dump($var, $varname='')
    {
        $this->log($var, Mylib_Log::DUMP, (empty($varname) ? array() : array('firebugLabel' => $varname)));
    }
}

Damit ist es ganz einfach möglich Variablen zu dumpen und das ganze wird dann in FireBUG auch schön formatiert.
Damit können wir auch unsere _initDebug()-Methode noch ein bisschen verschönern:

protected function _initDebug()
{
    if (APPLICATION_ENV == 'development')
    {
        // Firephp, diesmal mit der eigenen Log-Klasse:
        $logger = new MyLib_Log();
        $writer = new Zend_Log_Writer_Firebug();
        $logger->addWriter($writer);

        Zend_Registry::set('logger', $logger);

        // gleich alle interessanten Werte ausgeben:
        $logger->dump($_POST, 'POST');
        $logger->dump($_GET,  'GET');
        $logger->dump($_SESSION, 'SESSION');
        $logger->dump($_COOKIE, 'COOKIE');
        $logger->dump($_SERVER, 'SERVER');
    }
}

Außerdem ist es ungemein hilfreich, wenn man im Controller nicht immer $logger = Zend_Registry::get(’logger’); schreiben muss, also erweitern wir noch unseren Controller wie folgt:

abstract class Mylib_Controller_Abstract extends Zend_Controller_Action
{
    protected $logger = null;

    public function init()
    {
        // logger
        $this->logger = Zend_Registry::get('logger');

        parent::init();
    }
}

Jetzt kann FireBUG endlich verwendet werden:

class IndexController extends Mylib_Controller_Abstract
{
    public function indexAction()
    {
        $this->logger->debug($this->db->query("SELECT * FROM tbl_users;")->fetchAll());
        $this->logger->log('Einfach mal geloggt...');
        $this->logger->info('Eine Information!');
        $this->logger->warn('Eine Warnung!');
        $this->logger->error('Oh nein, ein Fehler!');
        // $this->logger->dump(...); hab ich ja in der Bootstrap.php schon verwendet
    }
}

Viel Spass beim Ausprobieren!

W3C sagt: ampersands in der URL durch Semikolon ersetzen…

11. Februar 2010

& ist out, das Semikolon muss her!

Das werd ich mir demnächst mal genauer ansehen…
http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

Scheinbar unterstützt mein Apache das nicht, wär aber wirklich mal was Wert, wenn’s funktionieren würde…

Automatische Admin Backends mit dem Zend Framework?

10. Februar 2010

Könnte ich auch gebrauchen… http://www.oelerich.org/?p=215 :-)

Wenn man jetzt noch Zeit hätte… *träum*

Wie klein kann ein Blog sein?

10. Februar 2010

… und dann auch noch funktionieren?

phpgangsta.de hat dazu aufgerufen den kleinsten Blog der Welt zu schreiben (er soll also möglichst wenig bytes an Code haben).

Was dabei rausgekommen ist, kann man eigentlich garnicht mehr als Blog bezeichnen, bzw. ist nicht mehr wirklich einsetzbar. Ich habe auch angefangen was zu basteln, hab aber bei 300 bytes aufgehört, weil es ab da kein wirklich verwendbarer Blog mehr war. Oli hat es dabei bis auf 167 Byte bzw mit Unix Befehlen sogar auf 148 Byte gebracht: http://www.oelerich.org/?p=220.

Ist echt verrückt, was bei PHP so alles möglich und zulässig ist, wenn man versucht unsauberen Code zu bauen um möglichst wenig Zeichen zu brauchen, damit etwas funktionert! Produktiv einsetzen kann man das ergebinis dann aber nicht…

colored grep in the console ♥

27. Januar 2010

here is how it works: add the following lines to the .bashrc file  in your home-directory or the global /etc/bash.bashrc

alias grep=’grep –color=auto’
alias fgrep=’fgrep –color=auto’
alias egrep=’egrep –color=auto’

do websites need to look exactly the same in every browser?

17. Dezember 2009

Die Antwort auf diese Frage ist ganz einfach:

http://dowebsitesneedtolookexactlythesameineverybrowser.com/ ;-)

Wenn dein Postgrey abschmiert…

11. Dezember 2009

… und im Log folgendes zu finden ist:
Dec 11 12:24:53 morin postgrey[4684]: fatal: ERROR: can't create DB environment: No such file or directory
Dann hilft folgende Lösung von benjamin.sonntag.fr :

I found that the greylisting database in /var/lib/postgrey was corrupted. When I strace postgrey start script with strace -f /etc/init.d/postgrey start I saw misc error messages such as “__db.001: no such file or directory”.

After searching the Internet, I found a guy who had the same error and simply destroyed its greylisting berkeley database (sniff, my db ? dead ?). But I didn’t want to loose mine, so I do the following :

# check that db4.3 tools are installed
# (use your version and package manager for this step)
apt-get install db4.3-util
# dump the current databases :
cd /var/lib/postgrey
db4.3_dump -p postgrey.db >/var/tmp/postgrey.db
db4.3_dump -p postgrey_clients.db >/var/tmp/postgrey_clients.db
# Kill everybody
killall -15 postgrey
# (this killall said logically "no process killed")
# destroy the pid file and all the database files
# to start with fresh entries
rm /var/run/postgrey.pid
rm /var/lib/postgrey/* -f
# start postgrey :
/etc/init.d/postgrey start
# here postgrey is up and running, (with an emtpy db of course)
# So we stop it :
/etc/init.d/postgrey stop
# and restore the db from the dump :
db4.3_load -f /var/tmp/postgrey_clients.db postgrey_clients.db
db4.3_load -f /var/tmp/postgrey.db postgrey.db
# that's all, just restart postgrey :
/etc/init.d/postgrey start

Here it is. I hope you’ll find this tip useful. See you soon.

Warum Webentwicklung so kompliziert ist….

9. Dezember 2009
Alexander Windbichler von Anexia.at zeigt hier einmal ganz anschaulich, was an Webentwicklung eigentlich so kompliziert ist.

Alexander Windbichler von Anexia.at zeigt hier einmal ganz anschaulich, was an Webentwicklung eigentlich so kompliziert ist.

Auch sehr sinnvoll angebrachtes Schild…

6. Dezember 2009

"Liebe Besucher der Grünanlage:" (im Hintergrund nur dreckige Kiesfläche)

Das nenn ich mal Abschreckung…

25. November 2009

Private Parking
So ein Schild brauch ich auch :-)

Auf dem Blog gibts noch mehr solch interessante Schilder, wie z.B. “Please do not empty your dog here:-D