Chief economist lectures Germans - oh yes, when the henchmen of the money bags complain it's analysis and supposedly constructive criticism. What comes out in the end - which is what matters, as we've all known since Kohl - is just garbage. But what else would you expect from the chief economist of one of the biggest rip-off companies (let's remember: they just planned to lay off a few thousand employees despite record profits - which will surely be great for the economy) anyway.
Film industry mobilizes against "piracy clause" - when I look at all this whining, I lose the desire to watch films anyway. I hardly go to the cinema anymore since there are only megaplexes left, where you feel about as comfortable as in a train station hall. And DVDs - sorry, but what am I supposed to do with films that torture me in my home cinema with 15 minutes of advertising for other film garbage I don't want - and if I wanted it, I would have gotten it long ago anyway.
Instead of actually thinking about how to respond sensibly to modern technology, the film industry prefers to think about how to further cement an outdated business model. And it cries out for help from the state. What a load of nonsense.
Don't reset existing password on request, prevent DoS password reset abuse - well, I noticed exactly this problem too and couldn't believe that someone actually built something like that into a CMS. In Drupal, you can change the password for a user - any user at all. The new password is then sent to that user by email. So you can't gain illegal access through this, unless you can intercept the user's emails (which shouldn't normally be the case). But you can lock out an admin: simply set up a job that resets the admin's password every minute. And then use this forced absence of the admin to completely spam the Drupal site, for example.
That's really an embarrassing oversight. Unfortunately, it's made far too often and far too frequently. So if you operate Drupal, the patch is recommended (be careful, the author submitted two patches, the first one was still buggy). It installed without any problems and at least fixes the admin lockout. Of course, you still get annoying emails in the process.
Kai is ranting about Firefox - IDN - 0 Info - 0 Transparency - and he's right with his rant. You're used to this security secrecy from commercial providers, but with open-source projects it annoys me every single time as well. When will people finally understand that only early disclosure gives users a chance to protect themselves? Keeping bugs secret is based on the absurd assumption that you're the first to notice this bug. Which is simply silly: a blackhat who notices this bug will certainly not broadcast it but instead exploit this bug for as long as possible. And so only those benefit from keeping it secret for too long - the ones we shouldn't be helping anyway.
User security needs to be the focus of security considerations - and specifically the informed user who is capable of turning information into meaningful action. The uninformed user doesn't care anyway, they click on everything. But a sysadmin who knows about a problem can at least contribute through educating their own users so that they maybe act more cautiously for a certain period of time. An uninformed sysadmin doesn't even have a trace of a chance to do that.
The university has built a greenhouse for research on genetically modified plants. I can't really say I'm particularly thrilled about it being in the neighborhood. Not necessarily because of the greenhouse itself — but where there's a greenhouse, eventually someone wants to conduct field trials.
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...
or at least that's what one could think. Today's program: Drupal 4.5.2. Nice package, I especially like it because there's now also Kubrick as a theme for Drupal and because it's quite powerful while still being reasonably manageable. But every time I deal with it again after a longer break, I fall into the same pitfalls: for example, enabling translations. It's great that translations exist. But when there's not even the slightest hint on the website about what you need to do, you end up feeling pretty stupid. Ok, yes, you just have to activate the locale.module. But where on earth is that documented? In the x-th hierarchy of the administration menu. Equally annoying: a database connection for PostgreSQL is included. Unfortunately, it's only usable from PHP 4.3 onwards - older versions aren't supported, even though Drupal runs from 4.1. After I've edited everything to use the old function names, it still doesn't work: apparently a default value was missing for the uid column in the sessions table. After I set that, PHP hung when accessing the site. Ok, fine, use MySQL instead (but I don't like MySQL...). Alright, now I'm in, I also have Kubrick as the layout and German translations. Ok, part of the system in German - but there are tons of missing strings. So I know what I'll be doing again soon. Great. Just as great as the default value for the file directory, which is simply "files". Which doesn't work if you want to allow users to upload images, because then "files" and "pictures" get concatenated without a /. And no, the / can't be before "pictures", it has to be after "files". And that with Kubrick the menu in the right column obviously has to be selected as "links" when activating blocks - I probably don't need to mention that separately. And the fact that the manual is anything but up to date - sorry, but that's just ridiculous. It still talks about directory structures in places that don't even exist anymore. No, the settings aren't in sites/default/settings.php - they're in includes/conf.php.
Ugh. This is such a nice project. And the whole system is really powerful and stable. But the documentation is really a joke. Sometimes I get the feeling that people aren't documenting Drupal at all, but something else entirely.
Still, it's nice, so I won't complain too loudly. Others don't really do much better either. Still - it could be so nice if the reference to the online manual would actually help instead of confuse...
Rat der EU ignoriert Forderung des Parlaments - well, that was almost to be expected. Why bother with democracy, it only slows things down anyway ...
Spreeblick explains the music industry to us: Sweety Records
In "On the GPL" Isotopp writes about the GPL and what is actually in it and how one can understand it. A pretty good explanation, I think. Should be recommended reading for anyone who believes the nonsense that Microsoft, SCO and some others spread about the GPL.