Doch was passiert, wenn das Jahresende bereits zur Kalenderwoche des neuen Jahres gehört, wie etwa beim Jahreswechsel 2008 auf 2009:
>>> date("Y-W", strtotime("2008-12-31"))
'2008-01'

Stimmt nicht ganz, denn der 31.12.2008 liegt nicht in der ersten Kalenderwoche des Jahres 2008, sondern in der 1. KW 2009. Leider zeigte mir die PHP-Dokumentation keinen Hinweis auf das Problem – was daran lag, dass ich die deutsche Dokumentation hatte. In der englischen Beschreibung findet sich das Format “o” (“kleines Oh”), das die Jahreszahl nach der selben ISO-Norm wie die Kalenderwoche angibt.
>>> date("o-W", strtotime("2008-12-31"))
'2009-01'

Und siehe da, die Ausgabe ist nun wie erwartet. Das Format “o” wurde übrigens erst mit PHP 5.1.0 eingeführt.

The official solution for this problem is to empty the result set of a previous query using fetchAll(). If you have to process every row in a table, this method copies the entire table into a PHP array. This is fine for small tables. But in a recent project, there’s one table which is 8 GB large. I surely don’t want to copy this table into my memory …

Thanks to Ilia, there is a solution for this: Just tell the underlying MySQL driver to use buffered queries.

$dbh->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);

The downside of this approach is obvious: Our PDO-based database access is no longer portable as we now use a MySQL specific functionality. But as long as there is no other solutions for iterating over big tables and issuing a query for every row, I think this is the way to go.

The date string looks like this: 1/Jan/2007:08:03:50 +0100
Using phpa, the command line PHP tool, I got what I expected:
PHP 5.2.0 (cli) (???) [Darwin]
>>> print strtotime("1/Jan/2007:08:03:50 +0100");
1167635030

But in my PHP script, the very same command returns -1. After a lot of experiments, I found the problem. While my phpa tool uses PHP5, the script is invoked via php – which defaults to PHP 4.4.7. Obviously, the date format used in log files was added to strtotime() in PHP5:
macbook:~ sf$ php -r 'print phpversion()."\n"; print strtotime("01/Jan/2007:08:03:50 +0100")."\n";'
4.4.7
-1
macbook:~ sf$ php5 -r 'print phpversion()."\n"; print strtotime("01/Jan/2007:08:03:50 +0100")."\n";'
5.2.0
1167635030

So, be sure to check what PHP version you’re running, if you get into trouble with strtotime().

Beim genaueren Lesen der E-Mail aber überfiel mich ein milder Lachkrampf. 1&1 erklärt, dass sie zum 20. November 2007 die Unterstützung von PHP3 – in Worten: PHP DREI(!) – einstellen werden und man seine Scripte doch auf PHP4 umstellen möge. Sechs Wochen bevor die Weiterentwicklung von PHP4 gestoppt wird, empfiehlt Deutschlands größter Provider seinen Kunden, auf PHP4 umzustellen. Ich verstehe ja, dass Rückwärtskompatibilität für einen Massenprovider essentiell ist, aber dann sollten sie den Kunden doch wenigstens empfehlen, gleich auf PHP5 umzustellen. Auch wenn das erst seit gut drei Jahren verfügbar ist.

Das wirklich Schlimme an der Sache ist aber etwas anderes: Auf meinem 1&1-Server läuft ein Projekt, das ich 2002 gestartet habe und das natürlich in PHP3 programmiert wurde. Ich habe keine Ahnung, wie das Projekt die Umstellung verkraften wird – aber wir haben auch nicht die Zeit, das bis dahin zu ändern, befürchte ich. Also lassen wir uns mal überraschen.

Natürlich hab ich auch in meinem neuesten Projekt, das zum ersten Mal auch im Backend auf PHP setzt, intensiv die PHP-Variante create_function() benutzt. In etlichen array_filter()- oder array_reduce()-Konstrukten hab ich also ein create_function() eingesetzt.

Das faszinierende dabei: Alles funktioniert wie erwartet. Naja fast. Das Escapen von Variablen oder gar der Zugriff auf Klassenkonstanten ist ein Graus, aber irgendwie klappt’s fast immer. Bis ich ein Script schrieb und auf die 180.000 Einträge einer Tabelle losließ. Nach wenigen tausend Datensätzen ging dem Script schon der Speicher aus, wobei ich memory_limit eh schon auf 768 MB gesetzt hatte.

Eine detaillierte Analyse (ich hab halt Stück für Stück die einzelnen Funktionsaufrufe auskommentiert) zeigte, dass der Übeltäter eine Funktion war, in der zwei create_function()-Aufrufe steckten. Sobald ich diese durch den Aufruf zweier normaler Funktionen ersetzte, war das Memory Leak, das create_function() aufriss, gestopft. Seither benötigt das Script, selbst bei 100.000 Durchläufen, keine 5 MB.

Ganz offensichtlich gibt der PHP Garbage Collector den Speicher, der durch create_function() beansprucht wird, nicht zurück. Hängt wohl damit zusammen, dass PHP eine einmal erzeugte Funktion nicht überschreiben oder löschen kann. Wieder etwas mühsam gelernt; warum nur steht im PHP Manual kein Hinweis dazu? (Keine Widerrede: Die Warnungen im Diskussionsbereich zählen nicht!)

Jetzt habe ich also ein Script, dessen Speicherbedarf sich in Grenzen hält, der Code aber ist durch den Verzicht auf create_function() deutlich hässlicher und weniger wartbar geworden. Elegante Programmierung und PHP passen wohl immer noch nicht zusammen.

The really painful part of dealing with encodings is when you have text files (or database entries) where the encoding is mixed. Now, in theory, there is no such thing as a “mixed encoding”: A given text is either encoded in UTF-8 or in Latin1 – or in any other encoding, but there is no such thing as “mixing”. In practice however, there can be several situations where you get text which partly is encoded in UTF-8 and partly in Latin1. Today, for example, I started to upgrade an old blog from WordPress 1.5 to the most recent version 2.2.1. During this process I looked at the various trackbacks and learned that they were sometimes encoded in UTF-8 and sometimes in Latin1.

To sanitize those 700+ trackbacks I wrote a little PHP class called Latin1UTF8. The class has two methods: mixed_to_latin1($text) and mixed_to_utf8($text), which do what their names say. Just give them some text which may contain characters encoded in UTF-8 and/or Latin1 and you’ll get back a sanitized version.

macbook:~/Documents/source/php/utf8 sf$ /Applications/MAMP/bin/php5/bin/php Latin1UTF8.php
Original: Fischerländer. Fischerländer.
Latin1: Fischerländer. Fischerländer.
UTF-8: Fischerländer. Fischerländer.


Please be aware that there is no error checking! UTF-8 characters which can not be displayed in Latin1 will return garbage. While Latin1UTF8 may give the impression that the garbage in – garbage out rule is no longer appropriate, be sure to give reasonable data to my little class or you’ll get some surprises.

When writing code I really like to have some kind of fast feedback system, like the Smalltalk workspace or the Python IDLE shell. For Perl development I have created a graphical Perl shell for that purpose.

Because I now have to do more and more work with PHP, I’ve been looking for a similiar tool and came across phpa, “an interactive command line shell for PHP” from David Phillips. Unfortunately phpa needs readline which isn’t available on Mac OS X and Windows. (No, of course readline is available, but you have to compile PHP yourself to use it.)

So, I re-worked David’s PHP shell and removed all the fancy readline stuff. Without readline support the shell isn’t as useful as it could be, but at least it now runs on Mac OS X and I think it will also run on Windows systems. This interactive php shell without readline support I call phpa-norl – where the norl part obviously stands for “no readline” support.

Installation

Download the PHP shell file phpa-norl and start it with php phpa-norl.

To mimic the readline support, there is a simple history function in phpa-norl. Entering a single ‘h’ lists the twenty last commands you executed. Appending a number to ‘h’, executes the command with that number in the history list. ‘h0′ for example always re-executes your last command. You can also enter a multi-line statement. If the last character on your input line is a ‘#’, than phpa-norl assumes that there will follow additional code on a new line. To leave the PHP shell, just enter a simple ‘q’ and phpa-norl will exit.

In Windows, I use a phpa.bat file containing just a single line:

php c:\php\phpa.php

Saving this phpa.bat in a directory within your PATH, you can invoke the shell simply by:

phpa

PHP shell usage

Here is a typical phpa-norl session:

macbook:~ sf$ ./phpa-norl
PHP 5.2.0 (cli) (???) [Darwin]
>>> $a=array(17,899,324,234)
>>> $b=array(288,900,1212,2323)
>>> $c=array_merge($a,$b)
>>> sort($c,SORT_NUMERIC)
true
>>> print_r($c)
Array
(
    [0] => 17
    [1] => 234
    [2] => 288
    [3] => 324
    [4] => 899
    [5] => 900
    [6] => 1212
    [7] => 2323
)
>>> $a[]=199
>>> h
History:
[5] => $a=array(17,899,324,234)
[4] => $b=array(288,900,1212,2323)
[3] => $c=array_merge($a,$b)
[2] => sort($c,SORT_NUMERIC)
[1] => print_r($c)
[0] => $a[]=199
>>> h3
>>> $c=array_merge($a,$b)
>>> h
History:
[5] => $a=array(17,899,324,234)
[4] => $b=array(288,900,1212,2323)
[3] => sort($c,SORT_NUMERIC)
[2] => print_r($c)
[1] => $a[]=199
[0] => $c=array_merge($a,$b)
>>> h3
>>> sort($c,SORT_NUMERIC)
true
>>> h
History:
[5] => $a=array(17,899,324,234)
[4] => $b=array(288,900,1212,2323)
[3] => print_r($c)
[2] => $a[]=199
[1] => $c=array_merge($a,$b)
[0] => sort($c,SORT_NUMERIC)
>>> h3
>>> print_r($c)
Array
(
    [0] => 17
    [1] => 199
    [2] => 234
    [3] => 288
    [4] => 324
    [5] => 899
    [6] => 900
    [7] => 1212
    [8] => 2323
)
>>>

Update:
Since PHP 5.1 there is (at last!) a built-in interactive mode as Johannes Schlüter shows in his blog, but this interactive mode needs readline support which isn’t part of the official Windows or Mac OS X builds. phpa-norl addresses anyone who doesn’t like to compile PHP.

Update:
Licence: phpa-norl is, like the original phpa, public domain. Feel free to do with it whatever you want.