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.

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.

For the last few months I’ve been working on a project that is part website and part data processing.

In theory the website is the bulk of the project, but in practice processing the data has taken a disproportionate amount of resources.

Data exchange with another organisation is always tricky - and in this case we have incoming data that doesn’t conform to specification, business rules that change, and a daily data import to run.

The code I’ve been working on has been through a couple of versions, and now I have in mind a third

When developing a website it’s important to test it in as many different web browsers as possible.

If a client has a problem viewing the page there’s little point saying “but it works on my machine”

I have found that the differences between different versions of firefox to be small enough that testing in one version is sufficient.

I’ve recently been working with AJAX and SOAP which both result in multiple sessions running concurrently.

For example if you have an AJAX progress bar for a large file upload one session is uploading the file while a series of shorter sessions check on progress and update the bar.

How to track both parts of this cleanly has had me scratching my head a bit - but the solution is fiendishly simple.

Any complex website that needs updating has to be tested without affecting the users of the live site.

The challenge then is how to replicate the changes made on your test site on the live site.

If all the changes are in code then version control systems such as svn and cvs solve this problem very neatly.

But with a CMS such as Drupal some changes are inevitably required in the database.

Managing these changes without affecting the site content can be tricky.

I’ve just spent ages trying to find out why I couldn’t add some default views to drupal

I’d set up my views, exported them added them to a module in a hook_views_default_views() function…

and nothing happened.