Website Re-Development

Posted 11th August 2013

Until very recently, this web­site was pow­ered by Dru­pal. Now although Drupal’s great in a whole raft of sit­u­a­tions, there are times when either it’s overkill for some­thing small, or just doesn’t fit into one’s work­flow. I came to realise that both of these applied to this site, so when it came to re-​developing, I decided to aban­don Dru­pal for the site altogether.

In the end, I decided to rebuild the site using Jekyll, along with a few other tools along the way.

This post explains the moti­va­tions behind the deci­sion, what I did next and some of the chal­lenges I faced along the way.

The Need for Re-​development

There were sev­eral aspects that made re-​developing my site some­thing of a priority.

First, it wasn’t mobile-​friendly. I may have been able to get away with that some years ago when I first drafted the site, but now that’s just not accept­able. After weigh­ing the pros and cons of a respon­sive vs a sep­a­rate mobile site, I decided on the for­mer — and the only way to do that would be to start the front end build again from scratch.

Gift Certificates in Drupal Commerce

Posted 4th May 2013

There isn’t really an out-​of-​the-​box solu­tion for gift cer­tifi­cates in Dru­pal Com­merce; there’s no mod­ule (at time of writ­ing) you can sim­ply down­load, enable and for­get about. Being Dru­pal, there are many ways to skin a cat, so to speak, so in this post I’m going to out­line how I got them work­ing on a site I built.

Of course, the way your gift cer­tifi­cates work may well dif­fer from site-​to-​site; I had a way I wanted it to work, but your require­ments might be sub­tly dif­fer­ent, but hope­fully what­ever your require­ments, some of what fol­lows is of some use.

To out­line, here’s what I wanted to achieve:

  1. Gift cer­tifi­cates avail­able as prod­ucts, which a cus­tomer can purchase
  2. A range of val­ues (£5, £10, £20 etc) available
  3. A prod­uct dis­play page that dif­fered from “con­ven­tional” prod­ucts — there are less fields required, so the lay­out was likely to be different
  4. I wanted a cus­tomer to be able to spec­ify a recip­i­ent for the gift certificate
  5. The cus­tomer needed to sup­ply an email address for the recip­i­ent, so we can send it to them via email
  6. I wanted the cus­tomer to be able to spec­ify the recipient’s name, to per­son­alise the email
  7. The cus­tomer ought to be able to enter their name as they wished it to appear on the email; the billing name on the order might well be too formal
  8. There ought to be an optional text field to add a per­sonal message
  9. The gift cer­tifi­cate needed to be sent out via email when the order was com­pleted, and paid for

Extending Drupal 7 Block Permissions

Posted 4th September 2011

Dru­pal 7’s block mod­ule can be a lit­tle lim­ited in its per­mis­sions; “Admin­is­ter Blocks” is a rather sweep­ing capa­bil­ity, and often it’s use­ful to be able to make it that bit more gran­u­lar. For exam­ple, you may have a num­ber of blocks through­out the site but once they have been placed in the cor­rect region and the vis­i­bil­ity cor­rectly con­fig­ured (which often isn’t the sim­plest of processes), you don’t want con­tent man­agers to change those set­tings. You do, how­ever, need to allow them to change the title as it appears to site vis­i­tors, and of course the con­tent. This isn’t pos­si­ble out-​of-​the-​box; luck­ily, it’s not that hard to do. Inspired by kiamlaluno’s post on Dru­pal Answers along these lines, I’ve knocked up a sim­ple mod­ule to make per­mis­sions gran­u­lar enough for just a sit­u­a­tion. It’s incred­i­bly sim­ple and some­what lim­ited, but it does enable to you to grant or deny access to each part of a block’s con­fig­u­ra­tion, i.e.:

Seven Useful Drupal Modules to Enhance Usability for Administrators

Posted 24th August 2011

One of Drupal’s weak­nesses, I feel, is that out-​of-​the-​box usabil­ity for admin­is­tra­tors is a lit­tle poor (the Dru­pal team them­selves would prob­a­bly agree with me, how­ever this is some­thing that’s now being addressed in a big way). There are, how­ever, plenty of ways to make the expe­ri­ence bet­ter through a set of Dru­pal mod­ules which I’ll be cov­er­ing in this post. How­ever before even think­ing about mod­ules, it’s impor­tant you have a good admin theme — and there are a few good options. Root­candy is a peren­nial favourite, and comes in three flavours; stan­dard, fixed (i.e. a fixed width) and dark.

The Rootcandy admin theme for Drupal
The Root­candy admin theme for Drupal

Drupal 6 Install Profile Fail: Call to undefined function db_result() in path.inc

Posted 23rd August 2011

I’ve just spent hours try­ing to get an install pro­file to work, which was giv­ing me this error:

**Fatal error: Call to undefined function db\_result() in [site\_root]/includes/path.inc on line 54** 

Google helped to an extent; the prob­lem, it seemed, cropped up with a num­ber of instal­la­tion pro­files and it’s dur­ing the exe­cu­tion of hook_profile_modules() that it appears. The most com­mon cause, it seemed, was to do with the JQuery UI mod­ule, and in par­tic­u­lar the link to the library itself, which you have to down­load sep­a­rately. I had no such prob­lem, how­ever — thanks to a cou­ple of lines in my (Dush) make file it had already been down­loaded, and remov­ing JQuery Ui from the list of mod­ules to install didn’t fix it. Nor did exclud­ing date_api, another mod­ule with which this prob­lem can occur. In the end I had to go through each of the mod­ules I wanted my instal­la­tion pro­file to enable for me — a lot of them — sys­tem­at­i­cally in order to find the cul­prit. The cul­prit, it turns out, was robot­stxt. Hope this is of some help to some­one — I’ve wasted hours of today! (I should point out, by the way, that this prob­a­bly isn’t the fault of the mod­ule in question!)

Drupal 7: drupal_execute has Gone, Say Hello to drupal_form_submit

Posted 17th August 2011

As has been com­mented else­where, when you’re pro­gram­mat­i­cally insert­ing data the most reli­able way of doing so is often to sim­u­late form sub­mis­sion — that way, any val­i­da­tion rules are applied and other mod­ules have a chance to inter­cept the sub­mis­sion to do what they need to with the data. This was achieved using the func­tion drupal_execute:

$form_state = array();
$form_state['values'] = array();
$form_state['values']['field1'] = $value1;
$form_state['values']['field2'] = $value2;
drupal_execute('your_form_id', $form_state);

How­ever,

drupal_execute has gone alto­gether from Dru­pal 7. Instead, you need sim­ply replace any call to drupal_execute with the new func­tion drupal_form_submit (see the doc­u­men­ta­tion). Oth­er­wise, every­thing (from the point of view of your syn­tax) remains the same. Don’t for­get to use form_get_errors() to ensure that the form has validated.

Using an Additional Database in Drupal 7

Posted 16th August 2011

One of the nice, lesser-​known fea­tures of Dru­pal 7 is the abil­ity to use addi­tional data­bases and switch at ease. This might be use­ful for exter­nal data­bases, or if you have another data­base in an alter­na­tive for­mat — per­haps you have an SQLite data­base that for per­for­mance rea­sons, you don’t wish to migrate. (Yes, Dru­pal 7 now sup­ports SQLite!) The con­fig­u­ra­tion can be a lit­tle con­fus­ing at first, so let’s look at a settings.php file set up to use two data­bases: drupal on Localhost, and db2 sit­u­ated at db.example.com.

$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'drupal',
      'username' => 'username',
      'password' => 'password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
  'external' => 
  array (
    'default' => 
    array (
      'database' => 'db1',
      'username' => 'username2',
      'password' => 'password2',
      'host' => 'db.example.com',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

Taxonomy Colour: Drupal Module Development Tutorial (Part Two)

Posted 4th July 2011

In the first part, I looked at cre­at­ing the data­base schema for a sim­ple Dru­pal mod­ule designed to allow you to asso­ciate colours with tax­on­omy terms. In this sec­ond part, I’ll look at the admin­is­tra­tion aspects of the mod­ule. In essence, what we need to do is as follows:

  • Since colour-​coding may only be appro­pri­ate to cer­tain vocab­u­lar­ies (e.g. cat­e­gories) and not oth­ers (tags, per­haps). We need to pro­vide the user with the option to spec­ify which vocab­u­lar­ies are applicable.
  • The user needs to be able to spec­ify a colour when adding or edit­ing a term, where appropriate.
  • We need to pro­vide a mech­a­nism which allows the colour asso­ci­ated with a term to be stored, retrieved, and to be displayed.

Granting Ad-hoc Access to Drupal Content (Nodes)

Posted 16th June 2011

Drupal’s per­mis­sions sys­tem pro­vides suf­fi­cient flex­i­bil­ity to cre­ate an Edi­tor role or sim­i­lar, enabling a site user to review or option­ally edit con­tent prior to pub­li­ca­tion. But what if you sim­ply want to allow some­one to view unpub­lished con­tent on an ad-​hoc basis — per­haps you wish to get a col­league to look over a new blog post, for exam­ple — with­out hav­ing to cre­ate a role, or you sim­ply wish to restrict it to one par­tic­u­lar item of (unpub­lished) con­tent? Step for­ward Peek, which allows you to do just that. Sim­ply des­ig­nate a con­tent type “peek­able”, then depend­ing on the set­tings per-​content type, set your node as “peek­able” too. You can then grant a “peek” — a win­dow of time dur­ing which a spec­i­fied user can, by fol­low­ing a spe­cial link, gain read-​only access to that node. You can con­fig­ure an expiry time, the length of time it’s valid for and opt to be noti­fied when the con­tent is accessed. It’s a great lit­tle module.

Drupal Module Updates via iPhone Push Notifications

Posted 12th June 2011

If you’ve looked after a Dru­pal web­site for any length of time you’ll know that you should reg­u­larly update mod­ules, themes and most impor­tantly the Dru­pal core as-​and-​when updates become avail­able — secu­rity updates, at the very least. The Update Sta­tus mod­ule (now in core) is great for sum­maris­ing what needs updat­ing (if you haven’t enabled that mod­ule, you really should do), but if you really want to stay on top of those updates then there’s a fairly sim­ple way in which you can get them sent to your iPhone (or indeed iPad) as a push noti­fi­ca­tion. Here’s how. First, you’ll need to down­load Prowl from the App Store — at the time of writ­ing it costs £1.79, or $2.99 in the US. Next up, you’ll need to cre­ate an account on the Prowl web­site. Then, you will need to gen­er­ate an API key — you can cre­ate as many of these as you wish, and there’s no addi­tional charge for doing so. As you can see from the screen­shot below, the API Keys tab shows any exist­ing keys, and the form at the bot­tom is used to cre­ate a new one — all you need is a note to remind your­self what it’s for. Enter some­thing to do with the site you’re adding, e.g. “My Dru­pal Web­site” and hit Gen­er­ate Key