Skip to content

What is my IP address?

For a number of reasons it is nice to know your own IP-address. If you are behind a firewall or a NAT system, you usually only have a private IP-address and "someone else" on the internet needs to tell you your official IP-address.

Given what usually happens with free services - they are closed once in a while - and with freemium services - they change the business modell - I decided to run my own service. After all, it's not that complicated, and it integrates well into my own Dynamic DNS service.

Continue reading "What is my IP address?"

xPyrus community framework released by UniHelp e.V.

UniHelp e.V. - a registered student association in Magdeburg/Germany - announces the release of xPyrus, a framework for operating communities and document sharing platforms.

The framework is based on PHP 5 and PostgreSQL and has been running the students' community (a platform for exchanging study-related documents and connecting students) in Magdeburg since 2002.

The entire framework is released under the GNU Affero General Public License v3 at A unix-based server is required for installation and use of all features, however, a hosting service can be provided by UniHelp e.V. on request, especially for student organizations.

The press release can be found at:
UniHelp Blogs - Press release

Further information can be found at:
- Homepage of the framework:
- Reference application:
- Homepage of the publisher:

Manage Serendipity installations with Spartacus

I have to manage some Serendipity (s9y) installations. Only one of them is my personal blog, the others are customer installations, all on different servers. Apart from new serendipity versions there's also the problem with updated plugins. How can one know about available updates without opening each blog in a browser window, open administration, select "Configure Plugins" and check for new sidebar and event plugins?

Continue reading "Manage Serendipity installations with Spartacus"

Stupid open_basedir handling in PHP

I have an application which has to run on different webservers (or to be more specific on servers with a different directory layout). On one server the php files are in /usr/home, the next one is using /www, the third one /var/www and last but not least my laptop has the files in my home directory which is below /home.

No problem - or?

Since we want a bit security, we have open_basedir activated. Now the script has to check if a specific directory exists. I added this directory name to the open_basedir settings on all webservers. But surprise PHP tries to be intelligent. On servers where the specific directory does not exist, PHP removes the directory name from the open_basedir directory list (note: this cost another stat() call on startup).

You imagine what comes next? Now the is_dir() call on this server fails, because of an "open_basedir restriction in effect" error.


BOOLEAN datatype with PHP-compatible output

If you use pure PHP (no database abstraction layer) with PostgreSQL, you may run into the problem that your BOOLEAN columns are not recognized by PHP but the value is instead returned as a string. So any code like:

if (!$boolean)

always returns true because the 't' and 'f' are just strings in PHP.

Other programming languages like Perl, Python or Java and even the newer PHP PDO don't have this problem so it's clearly a PHP issue ... but i don't expect this one to be fixed, because this may break a lot existing applications. The column type information is available in the query result information so normally this should not be a big problem.

How to resolve this problem? There are some possibilities, one simple way would be to just use a SMALLINT instead a BOOLEAN but with the disadvantage that you loose the boolean input values. Another way is to create a new BOOLEAN type and change the output to something PHP-compatible. This new type is binary compatible with the existing BOOLEAN type so casts in either way are not a problem.

Note: i asked around, but it seems, there is no easy solution which does not require updates in the PHP or SQL code. Any workaround like explicit casts to integer are error-prone and you cannot easily find out, because your application will work, but in a wrong way.

Continue reading "BOOLEAN datatype with PHP-compatible output"

UBERWACH plugin for serendipity

Maybe you already noted the small surveillance camera in the menu list on the right side. Hopefully the icon is green, that would be good for you. If it's red your request comes from an ip-address known for being allocated by a german ministry or political party. Thats nice to know, isn't it?

More details about the icon and the project behind can be found at

If you are running a Serendipity blog and want to show this icon, i wrote a small plugin. You can get it from: Unpack the zip archive, copy the contained directory into your blog plugin directory and check the "Configure plugins" link in the admin menu. The new plugin should be available in the list for the sidebar plugins. Have fun!

PHP and version numbers

I just updated my local mirror of different documentations so i always have docs at hand, even if i'm working offline. So i went to the website and then to the docs. Now try to find out, for which versions documentation is available ...

The only vaguely available clue is the date the documentation was built. There is no information, which versions are included and which not. Also no link pointing to older docs, not even for the 5.x releases. You have to use the "one size fits all" archive. Oh, thats really great work ...

Wenn ein Consultant programmiert ...

So etwas kommt dabei heraus, wenn ein Consultant sich am programmieren versucht:

----- cut -----

function ValidateLink($link) {



// später:


----- cut -----

Das man selbstdefinierte Funktionen auch ohne Umwege aufrufen kann, ist bis in diese Ebene noch nicht durchgedrungen, oder? Von solchen Konstrukten fanden sich (neben anderen Abscheulichkeiten) Hunderte Stellen im Code.

PHP und assoziative Arrays

Und wieder ein Grund zum Lästern: Es ist ja nicht so, das in PHP ein Array gleich einem Array behandelt wird, zumindest nicht, wenn das Array in der Session gespeichert wird. In diesem Fall muss sich der Key des Arrays an die Vorgaben für Variablennamen halten ... ansonsten wird das Array kommentarlos gelöscht, sobald das Script abgearbeitet ist. Wohlgemerkt, zur Laufzeit kann man auf jeden beliebigen Key zugreifen, die Daten werden erst beim Speichern gelöscht.

Warum? Eine weitere Krankheit aus der Zeit, als beliebige Daten noch global in den Namensraum eingeblendet wurden.

Es ist wohl an der Zeit, damit mal aufzuräumen oder das ganze zumindest konfigurierbar zu gestalten.

Rasmus Lerdorf is praising PHP ...

Rasmus Lerdorf, the creator of PHP, tells us (here), that the web is broken and "we" had damaged it. But there would be PHP, which can fix all the issues. Ok, let's see, what Rasmus has to tell us.

"You don't know that you have to filter user input" ... ohm, which programming language was it, who made the user input from web available in the global namespace without further action? Which programming language was it, who triggered myriads of bugs in any kind of webapplication because of this "feature" in the past, the present and even in the future although the register_globals option is disabled in recent php versions? It is clear, that no beginner knows about filtering of user input, if PHP makes any input available without further checking.

"The Web is pretty much broken, we can all go home now" ... oh, and who broke the web? Which programming language cannot accept points in variable names in the web input and instead does rewrite every point to a underscore? No way and no intention to fix such a horrible behaviour in current releases. Look here for more details, the part about "Dots in incoming variable names". Surely this happened because of the ugly register_globals "feature", but variables like $_REQUEST are a good place to hold the original input name.

"PHP5 includes all manner of functionality to help developers filter requests, to help prevent the broken Web." ... so it took 5 major releases and 11 years to create a software with adequate functionality? Beside this, the documentation part about "User Submitted Data" in the security section does ask you (the developer) 5 questions about the security of your program, but there is no further explanation, how PHP may help you to secure your application. No links, almost no comments, nothing. You have to go and learn the answers somewhere else.

"If you can fit your problem into what MySQL can handle it's very fast," Lerdorf said. "You can gain quite a bit of performance." ... of course, if i need a filesystem with a more structured access method than fopen/fread/fwrite/fclose, Mysql comes into my mind. If i need a real SQL database which stores my critical business data, than a standard Mysql is not an answer. If Rasmus talks about performance, he surely does not mean performance and integrity of your data. Or could you tell my, why PHP does not even support transactions in the feature-rich set of database functions?

If you switch from the standard (My)Isam tables to tables with transactions (like Innodb) to gain some safety for your data, then your performance advantage is gone and the timing results are comparable with the Postgresql database which is blamed here by Rasmus. But of course, full ACID support is available in the latter.

I could continue speaking about the problems PHP brought to the web, the security holes PHP brought to the average developer and administrator, the uneloquent approaches PHP brought with quick and dirty solutions and the excuses Rasmus brought to defend real problems out there, but the list could run almost endless.

PHP does not need Transactions

Just stumbled about a curiosity: there are 82 functions in the current PostgreSQL part of PHP. Functions like pg_select(), which takes from you the burden of writing a "SELECT ... FROM tablename" or pg_delete(), pg_insert() and pg_update() which all does, what do you expect: select, delete, insert or update and make the error checking. There are even 7 different functions for getting your results back into PHP.

But there is no function for starting, committing or rolling back a transaction. It seems, the message about the usefulness of transaction has yet not reached the PHP developers. Not that i'm surprised, the standard PHP/MySQL user seems to have no need for transactions ...