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

• delete from variable where name='cron_semaphore';
• clear caches
• run cron from the web page

That seems to do the trick.

Now cron runs OK fom drush or web.

To remove static blocks and replace with as custom block.

Implement hook_block specifying the default visibility and so on

Create an update hook that deletes the old blocks and boxes (I've specified the ID as I know they won't change on my site).

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.

Frustratingly the latest version of RedHat provides PHP 5.1 and this is the second time I've run into the problem with a client who uses RedHat and understandably wants to stick to the standard packages.

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.

Negative testing 

Drupal only seems to test the positive path, that is that given the right inputs you get the right results and apart from security nothing else matters.

The result of this is that incorrect inputs result in silent failures that can be very hard to debug.

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.

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.

Most tests for Drupal are integration tests not unit tests.

That is to say that they test a bunch of components together - not each bit separately.

This is because Drupal components (modules or functions) are not well encapsulated, global variables are used, data is cached within functions,  passed via the database etc. 

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.

Much of the functionality is only really available through the application, you can do things pretty easily by pointing and clicking, but try and automate part of this and you have to step through code, find form handlers, copy-paste parts of the functions and work out what parameters are required.

The example I found most recently was creating a translated version of a page.

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.

This causes problems with Drupal as module install and update hooks may need to create tables which don't yet exist on live.

My solution which assumes you have .my.cnf set up to provide login locally is below.