Drupal

Drupal 7’s block module can be a little limited in its permissions; “Administer Blocks” is a rather sweeping capability, and often it’s useful to be able to make it that bit more granular.

One of Drupal’s weaknesses, I feel, is that out-of-the-box usability for administrators is a little poor (the Drupal team themselves would probably agree with me, however this is something that’s now being addressed in a big way).

There are, however, plenty of ways to make the experience better through a set of Drupal modules which I’ll be covering in this post.

However before even thinking about modules, it’s important you have a good admin theme – and there are a few good options.

I’ve just spent hours trying to get an install profile to work, which was giving me this error:

Fatal error: Call to undefined function db_result() in [site_root]/includes/path.inc on line 54

As has been commented elsewhere, when you’re programmatically inserting data the most reliable way of doing so is often to simulate form submission – that way, any validation rules are applied and other modules have a chance to intercept the submission to do what they need to with the data.

This was achieved using the function drupal_execute:

One of the nice, lesser-known features of Drupal 7 is the ability to use additional databases and switch at ease. This might be useful for external databases, or if you have another database in an alternative format – perhaps you have an SQLite database that for performance reasons, you don’t wish to migrate. (Yes, Drupal 7 now supports SQLite!)

The configuration can be a little confusing at first, so let’s look at a settings.php file set up to use two databases: drupal on Localhost, and db2 situated at db.example.com.

In the first part, I looked at creating the database schema for a simple Drupal module designed to allow you to associate colours with taxonomy terms. In this second part, I’ll look at the administration aspects of the module.

In essence, what we need to do is as follows:

Drupal’s permissions system provides sufficient flexibility to create an Editor role or similar, enabling a site user to review or optionally edit content prior to publication. But what if you simply want to allow someone to view unpublished content on an ad-hoc basis – perhaps you wish to get a colleague to look over a new blog post, for example – without having to create a role, or you simply wish to restrict it to one particular item of (unpublished) content?

If you’ve looked after a Drupal website for any length of time you’ll know that you should regularly update modules, themes and most importantly the Drupal core as-and-when updates become available – security updates, at the very least. The Update Status module (now in core) is great for summarising what needs updating (if you haven’t enabled that module, you really should do), but if you really want to stay on top of those updates then there’s a fairly simple way in which you can get them sent to your iPhone (or indeed iPad) as a push notification.

With a few handy contributed modules, creating a mobile version of a Drupal website can be surprisingly painless. In this series of posts, I’ll run through one approach for doing so, using a few of those modules and themes.

There are numerous steps you should complete before launching a new website; cross-browser testing, checking for dead links, proof-reading. These are covered more than adequately elsewhere but in this article I’m going to look at a number of steps applicable specifically to launching a Drupal site. You may not agree with them all, but then none of the following are compulsory – these are just my personal recommendations.