I asked Pepino about it recently, so I put my Deep Link Finder Script online. It's a simple Python script. Should run on Python 2.2 and up, possibly even Python 2.1 (but that hasn't been tested). The script is configured in the source code (I've added comments for it) and then simply called with multiple logfiles as parameters. It extracts from Apache Combined Logs which sites deep link to specified file types (configurable, some image types are set by default) and how often. It outputs an HTML fragment that you can add headers and footers to in order to put it online - for example, that's how my Zeitgeist page for deep links is created. The other pages have similarly structured scripts, except they collect search terms and general referrers instead.
I take a look at the deep linker list now and then, and if someone shows up there who deep links quite a lot and isn't an aggregator or news service, they get shown a corresponding replacement image. But really only those sites. It bothers me too when my feed reader suggests I'm an image thief or traffic robber.
Hotel Falckenstein: Make me the Ackermann - and with what? With reason! Making these top rip-off artists also honorary professors for economics at Frankfurt's Goethe University is simply just an audacity.
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 file loading describes the order in which WordPress loads which PHP files to produce a blog page. Quite interesting if you're planning to change files - it provides an initial guide to where you might find things. However, what also stands out: given that WordPress actually produces quite lean pages, WordPress itself already has quite a bit of bloat.
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.
wp-style-switcher is a simple CSS switcher for WordPress that works without JavaScript or similar.
