More on Drupal

What I also noticed while tinkering with Drupal: unlike WordPress, the database model is quite complex. WordPress is pretty straightforward - just a few tables with data in them, most of it quite straightforward. If you want to change something, you can always fiddle with it at the SQL level and write import scripts, repair scripts, etc. Everything is always calculated on the fly - counters, lists, etc.

Drupal, on the other hand, uses quite elaborate caching mechanisms in the database. Things from the filesystem are also cached. This means that with small scripts you have more work to do, because you have to account for much more - at least remove the cache so it gets reconstructed. Also, the data model is much more denormalized. That's certainly good from a design perspective - but for small scripts it's more cumbersome, since you have to handle more places.

This is now not a judgment, just an observation - both have advantages and disadvantages. The advantages of the Drupal approach seem to show up in performance, which seems to be somewhat better than WordPress not only because of the somewhat cleaner PHP structure (though I don't have hard numbers on that - first I need a workable import script for my posts to work with the same approaches).

What I also noticed: PostgreSQL support in Drupal (yes, I finally got it running!) is definitely behind that of MySQL. In some cases there are error messages with PostgreSQL that don't occur with MySQL. For example, there were problems with password changes because a non-existent field was being accessed. Or in the overview of sources subscribed to in the newsreader there was a message because a non-aggregated field of a complex SELECT was not listed as a grouping field. Or on first access, where no value was specified for the uid field in the sessions table, even though it was declared as NOT NULL. PostgreSQL is definitely more picky than the card file. With PostgreSQL you'll definitely have to modify the PHP code. I'll see - once I'm done, maybe I'll prepare a patch that fixes these issues. So far they're just minor things, but they can certainly be a hurdle for non-programmers. Some of them are certainly based on the somewhat older versions from Debian Stable (for example, the PgSQL API in PHP is named quite differently in newer versions than in 4.1.2).

Wordpress to Drupal Migration Script

Wordpress to Drupal Migration Script - but it currently seems to only be able to migrate from flat file to flat file - you may need to first set up a proper database as the target.

Update: well, the script really only transfers the posts. No post slugs (so no URL preservation), no categories, nothing. You might be able to use it if you only had a very simple WP blog, but otherwise it's pretty bare-bones. And with large blogs it crashes after a while with an error - the available memory is exhausted. This is because PHP uses the CGI settings when run from the command line - and the memory limit is restricted there too. On top of that, it has no duplicate detection, so it cheerfully imports everything again on the second run.

Sounds like I'd probably need to write my own solution if I wanted to try this seriously.

Don't reset existing password on request, prevent DoS password reset abuse | drupal.org

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.

Yep, Drupal is going to drive me crazy

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...

Some projects want to drive me insane

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...

drupal.org

I'm currently playing around with Drupal a bit. First impression: wow! Extremely powerful, extremely many features. Though possibly too many features. But what I like right away is the very clean interface with quite logical menu structure, and how all extensions automatically hook into these menus. I also like the solution with templates and themes: themes can be divided into templates or stylesheets. This allows you to change the general system, but also just choose variants of a system. The default theme is table-based, but there's another CSS-based one to choose from. I can't really say yet how XHTML compatibility looks. Also good is the support for MySQL and PostgreSQL - I normally prefer the latter. You can also make weblogs with it, as well as static articles, entire books, stories with discussion forums similar to Slashdot or Kuro5hin and much more. However, what stands out right away is that the tools in the individual content areas are somewhat sparse - tools that specifically target weblogs often seem more complete. Specifically things like Trackback, Pingback, update pings or similar have to be installed afterwards or at least reconfigured - the standard only pings drupal.org itself for the distributed login mechanism. Also such elementary things as simple categories (more complex categories - even hierarchical - do exist, but elsewhere) for blog entries require some searching. RSS feeds are automatically created, but on some pages (for example the homepage) they first have to be linked (in user blogs the link is automatic though). Otherwise they are only contained as alternate links, but not necessarily visible to users. Overall, the whole system clearly aims to design and build entire websites with entire groups of users. However, the distributed login mechanism is really cool: users from participating systems can log into other participating systems with user@host and the login is automatically passed to the home system. Login with always the same password, but with distributed authorization. Very nice! Overall, a lot of value is placed on user management - it almost has Zope dimensions with its permission groups and the ability to create symbolic permission groups for individual activities. Less cool are the many missing metadata. There's actually hardly any metadata on content. Author, date, status - but that's more or less it (of course besides title and text, those are self-evident). Content organization is also left to the user - though there are helper tools that make creating navigation easier. However, many metadata topics (such as categories) can apparently be solved using taxonomies - these are groupings of content. The description of this is somewhat unintuitive, the topic is quite complex. Taxonomies are groupings of keywords on a topic. So I don't assign posts to categories, but rather assign keywords to posts and then organize the keywords into categories. While this provides mountains of metadata, it's far more complex than the normal blog categories you're used to.

Great again are all the content status and content versioning functionalities. All changes are logged. All changes to content are versioned. You can go back to older content and thus, for example, fix errors (or remove garbage from rogue users).

The whole system is extensible, but I suspect (haven't checked it yet, but given the range of functionality it's a likely guess) that creating plugins and filters is more involved than with small solutions like WordPress. But that's in the nature of things.

Another potential disadvantage is the unavailability of a ready-made German translation. While there are other sites working with Drupal in German, apparently no one releases the complete translation tables for download - at least I haven't found anything, neither at drupal.org itself nor on Google.

Where would I classify Drupal? Clearly in the CMS category - that's where systems like Typo3, Mambo Open Source, Plone and similar systems shine. However, it beats discussion-oriented CMSs like Scoop or Squishdot by a mile - as well as simple blog CMSs. For a simple blog system it's clearly overkill. For a complete site it seems very usable.

Here's the original article.

Releases | drupal.org - Download page for Drupal modules