monline

(...) Modern Linux distro's, say Ubuntu (8.10) comes with a default PHP configuration of session.gc_probability = 0. This means that in general, session GC will never run(!). There is a unix cron job that runs every half hour and checks for old sessions to delete (see more at /etc/cron.d/php5) but this is done only if you're using the standard "files" as your session handler (check out the directive of session.save_handler on your machine to learn what php default sessions handler is but make sure to check that your application doesn't overwrite this), so for Drupal users using plain Debian/Ubuntu, stock LAMP packages and stock Drupal applications, this means that the PHP garbage collection, despite your best intentions, will also never run. (...)

It's quite simple. Here's the code snippet based on the current version of the 6.x pathauto module. You can run it eg. via the devel module.

This blog post helped me a lot ... probably it'd have taken a few hours to figure out why mysql_connect() dies with a "No such file or directory" error. I had a feeling (while I was reading the readme in the Mac installer of the currently available MySQL server, which got obviously outdated years ago) that there're problems to be expected with the MySQL install.

"The purpose of Spamicide is to prevent spam submission to any form on your Drupal web site. Spamicide adds an input field to each form then hides it with css, when spam bots fill in the field the form is discarded. The field, and matching .css file, are named in such a way as to not let on that it is a spam defeating device, and can be set by admins to almost anything they like(machine readable please). If logging is set, the log will show if and when a particular form has been compromised, and the admin can change the form's field name (and corresponding .css file) to something else."

Calling the cron.php of a Drupal site is fairly easy. You just have to put something similiar into your server's /etc/crontab:
Or you can place this wget call in a file in /etc/cron.hourly.

However on a server with quite some Drupal sites (and possibly a number of virtualhosts) the maintenance of these cron.php calls in your crontab becomes very annoying (and it is prone to errors). On a busy development server Drupal sites come and go every day. So why not do these calls automatically? The attached script does just that.

I just had an idea. I know: what a rarity!
It'd be nice if the field API of the coming Drupal release (v7) would support adding fields to taxonomy. I'll explain why ...

I had a small problem with upgrading the CCK module during the transition from Drupal 5 to Drupal 6. I use the Link module to have a link field (the field name is "url") in a custom content type (named "link"). However after the upgrade whenever I added or updated a node of this content type, the value of the url field was empty. In the Drupal log I saw errors like this:

There's already a picasa module for Drupal, but if you just want a random photo block and not the complete integration stuff (custom node type and nodes for all the photos), then you might find my module more attractive. Its use is pretty straightforward, set up the block as you'd do with any other block. The Picasa Web Albums user id can be specified in the blocks configuration page (along with a couple of other options).

It can be a little bit tricky (or at least I've not found a clear description on this topic in the Apache docs) to tell where the mod_rewrite module of Apache 2.2.x is going to look for a file if you use a condition. I've had a hard time to get this clear and maybe sharing my experience will benefit others.

The Google Webmasters Tools reports several title issues in the "Content Analysis" section for Drupal-based sites. This due to the fact that the Drupal paging mechanism does not alter the title of the page, thus all pages within the same content list (eg. taxonomy list or the default node listing at /node or any pageable views) share the same title. You can of course alter your code if you consider this an issue as well. You could eg. create a custom module, hook into the page rendering mechanism somewhere really at the end of the process (and also set your module's weight to some huge value) and overwrite the title of the page (eg. by adding some "(page #k of n)" text to the end of the title) if the pager is being used.