Warning message

The service having id "facebook_widget" is missing, reactivate its module or save again the list of services.

Drupal

The trouble with WGET... is stopping those pesky output files

I think I must have been plagued for about 5 years with the age old issue of WGET requests creating unnecessary and unwanted empty files following a WGET request. WGET is tool for retrieving files via http, https and ftp via a command line interface.

I use WGET extensively for running cron jobs across the various blogs and websites running on my server. Each time the cron job is run, an empty file, i.e. cron.php is created. If a cron.php file already exists, it creates another cron.php 1, cron.php 2, cron.php 3 etc.

You can imagine after just a few days having hundreds of these breeding like wildfire.

Stupidly, rather than fixing the problem, I created a solution. To run another cron task which periodically deletes the cron files, 

rm /Users/jonathan/cron.*

This kind of works, but then I started using WGET for a whole heap of other tasks, and yes, the output files mounted up.

Half term holidays affords me the space to find these solutions, and it's a simple one.

When structuring a WGET request, simply add

--delete-after

to the request, i.e.

wget --delete-after http://www.southwoodfordnhw.info/cron.php

Works perfectly and as described. Relief at last.

Painless Drupal v6.0 Upgrade

Drupal logoAs every software developer knows, especially ones like me who obey the 'hack it and run' rule, it's quite unusual for software to 'just work' out of the box. Tonight was a surprising exception as I took the brave decision to upgrade the Drupal software which powers this blog site.

Some people might ask why?  Well, for a whole heap of reasons really.

  1. I was receiving an increasing number of spam messages which were somehow getting past the CAPTCHA mechanism that I have in place. I suspect some security loophole had been discovered in v5.1 which was then exploited.
  2. If you want to explore and play with pushing software to its limits or seeing what else is possible, often you need to be running the latest version of the software to access the compatible modules and plugins.
  3. I've learnt from previous experiences of not upgrading software versions that quite often you can get 'left behind' with future upgrade paths. This one is a real gotcha as you start to regret having not applied the last 3 upgrade scripts. As you spit through gritted teeth, you begin a long night of incremental software upgrading through each version, i.e 3 --> 4, 4 --> 5, 5 --> 6 etc. It's a miserable experience.
  4. Not upgrading your Drupal installation is like not finishing the tiling in the kitchen - you won't get the full user experience of all the features and when you prepare to move house, you kick yourself indefinitely for not having finished it sooner.

Rather delightfully, the upgrade to v6.0 was straightforward and painless. Drupal coders write a fantastic migration script - well done guys.

I do wish you could solve some of the issues with having to re-apply customisations to 'themes' however. I'm now wise to this headache and despite my inner most desires, refrain from making too many customisations. On the other hand, the template files haven't changed much between versions and I'm getting pretty good at predicting where line 503 is in a 2000 line template file and making the odd code edit. Thanks guys.

Some of the really nice features of v6.0 includes:

  • automatic checking of module updates.
  • better versioning control for compatible modules.
  • AJAX drag and drop feature for arranging 'block' and menu order (at last!)
  • custom notifications for any Drupal event - this could be really useful.
  • support for OpenID, ready for when single-sign on gets sorted (pig flies overhead)

and finally, finally!!!

  • a fix for broken or chopped HTML in comment posts.

 Hurrah! So it's a pretty worthwhile upgrade. Back to the tiling then.... 

 

Usability again... this time, with tagging content

Tom Smith accurately points out the usability gaff in being able to tag content 'on the fly' when creating the page using most blog or content management tools. This blog is powered by Drupal, Tom is right...

And here's the rub. Tools like WordPress require you to create a category BEFORE you have created the item you want to add that category too. This is so backward. It'??s a simple usability error. Most web-based software does this and it is such an obvious gaff.

With it being such a source of frustration, I tend not to bother and forget.

It can't be that hard to make a little pop-up window that submits tags to the database as you write the content... else, why doesn't someone just modify the form to create a space to add new tags as you submit the page... easy?

Categories:

Subscribe to RSS - Drupal