The drush script which provides command line access to drupal functionality emits an error message when run as a cron job

tput: No value for $TERM and no -T specified

I’ve just run into the drupal cron problem again

Cron fails and the error log says

Attempting to re-run cron while it is already running.

To remove static blocks and replace with as custom block.

Implement hook_block specifying the default visibility and so on

Drupal has a fairly easy to meet set of requirements http://drupal.org/node/502452

But Drupal projects are free to set their own rules in this area and Drush has used functions only available in PHP 5.2 - as far as I can see this is just the json functions.

Drupal has a lot of great strengths and some weaknesses

The following are the key areas of Drupal that (as a programmer) I would like to see improved.

Drupal is a very flexible CMS which can be extended to provide the functionality needed for may different types of website.

I’ve worked on a few projects where I was brought in for my Drupal expertise, but in the end felt that Drupal wasn’t a good solution in these particular circumstances. So I’ve been pondering what sorts of projects is Drupal best suited to.

I’ve been working in the CMS arena for 10 years, and the whole time I’ve been expecting one or more “industry standard” CMS’s to come along, but instead we’ve seen thousands of competing products with almost every web agency claiming to have CMS product.

While development costs have come down a long way due to greater experience and code re-use they still haven’t come down anywhere close to the level that people are used to from purchasing shrink-wrapped mass market software.

Clients have been getting fed up of high costs and vendor lock-in.

In this context I’ve seen many clients specifying Drupal as a requirement when putting projects out to tender – in the hope of saving cost and avoiding lock in.

I was originally excited about the embrace that Drupal seemed to have given to testing.

However after spending some time with it I’ve concluded that Drupal really isn’t very test friendly.

I’ve been using Drupal for a couple of years now, and know my way around it pretty well.

One of my biggest frustrations though is that it doesn’t really have an API.

When developing Drupal one often needs to pull recent copies of the live database into the dev environment.

Loading a dump into the dev database will update any existing tables, add any new ones - but it won’t remove tables from the dev environment that re not in live.