Clearly. I don't know what it has against me, but it hates me today. Really massively.

I simply copied the kubrick-theme under my own name so I could customize it without changing the Kubrick-theme itself. Funnily enough, it's now not using the phptemplate-engine anymore. Or more precisely: the entry in the system table (type='theme' and then for the page.tpl.php) doesn't point to phptemplate.engine, but to phptemplate - the .engine is missing. When I add it via update, it works exactly once. After that, this entry in the system table gets overwritten and .engine is gone and the template is broken. Of course, Kubrick doesn't do that. And of course, you can't find any information anywhere about where the heck the theme says which template engine should be used - and how this entry in the system table is created. No, simply grepping for phptemplate.engine doesn't help.

Ok, now it's clear to me that the engine creates the entries - at least after I took a closer look at the engine source. It searches for page.tpl.php and when it finds it, it connects it with the phptemplate.engine. But why would the engine enter its own name incorrectly? Especially since it does it correctly with Kubrick. I just unpacked that into the themes directory.

Alright, so let's keep investigating. A grep -r for INSERT in combination with system then finds the function system_obtain_theme_info in the system.module, where these statements are written. But how and where exactly something is done with it there - sorry, but you can't figure that out without longer study. Somehow the description attribute gets filled with a value that ends with .engine for the Kubrick-theme and doesn't for all others. Kubrick references the theme engine exactly and correctly, but an arbitrarily named copy of Kubrick with identical content references a theme engine without .engine in the name and doesn't work. Great. But renaming Kubrick works. Huh?

Ok, next approach. Rename my template to something else and rename Kubrick to my actually desired name. Complete confusion: my template doesn't work, but the now-kubrick-named one that didn't work before doesn't work either. Uh... So I renamed the Kubrick to something else. And tried my temporarily stored one. That works now. Under a name that isn't Kubrick. Huh? Shell game? Should I just rename the themes around until I eventually have a working one under the name I want and then call it done?

So I tried to resolve the shell game. Computers are deterministic machines after all, that should be possible. Ok, both templates (original Kubrick and my Hugo) renamed. To aa and bb. And which one works? The one called bb. Did the whole thing again, just this time swapped the roles. aa becomes bbb and bb becomes aaa. Which one works now? The one called "bbb". When two phptemplate.engine-based themes are installed in the system, only the last one found in the system at the time themes are being searched works. The others break.

So now I first have to figure out what's wrong with the old themes, why they can't be made to work. First approach: make a database dump and grep to see where all my friends show up. While doing that, I found what's up with the mysterious phptemplate without .engine: the corresponding entries contain a chr(0) instead of the period. Ascii-null. MySQL stores it, but PHP cuts it off on access. And for all the old templates, there are all these broken entries. Also, the engine remembered in the phptemplate extra_templates entry in the variable table which themes it had already seen.

Another clean room test: throw out the entries in the system table with type='theme' and description like 'themes/engine/phptemplate%'. Then it knows nothing more about the themes and their names. Then only have my desired template and activate it. And behold, it works right away. Then unpacked Kubrick. And it works. But after that, my own theme doesn't work anymore. As expected - Kubrick comes after hugo alphabetically. Delete Kubrick again and my own theme works again - after appropriate refresh.

So investigate where the heck this is happening and why. It only happens with the phptemplate.engine themes. The xtemplate.engine themes work without problems. Although it turns out they do it despite the bug - it affects them too. Because in system.module in system_theme_data (how I figured that out I'll spare the readers - it was just successive inserting of echo statements to see when and where things break) it gets destroyed in the last step - in the call to system_obtain_theme_info - on the files the description element. And that's what gets saved in the system table to reference the theme engine. Only the last theme of an engine keeps the correct entry, all others are broken.

Hmm. The basename call on line 336 is the only suspect - it basically only delivers the theme engine without the .engine suffix. But it shouldn't change the actual field, so I hadn't paid much attention to it before - the PHP documentation says nothing about side effects of this function. But when I comment out the entry, my theme works and Kubrick too - simultaneously. But the PHP manual says nothing about basename changing the original string.

So I wrote a small test script that just makes a basename call. Ugh. Yes, that's it - basename changes the original string, and it puts a chr(0) in place of the period. And behold, there's a bug report from 2002 about it - yes, I'm running an old PHP 4.1.2 version, since Debian Stable. The bug report has a workable solution for my problem - just put the variable in "" and work with string interpolation. And behold, problem solved. And make a note to remember: in 4.1.2 basename breaks the source variable.

And a programmer spends debugging time on crap like this (I mean the bug, not Drupal)

I could have learned a decent job. Whisky barrel keeper at Jack Daniels, for example...