Until very recently, this website was powered by Drupal. Now although Drupal’s great in a whole raft of situations, there are times when either it’s overkill for something small, or just doesn’t fit into one’s workflow. I came to realise that both of these applied to this site, so when it came to re-developing, I decided to abandon Drupal 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 motivations behind the decision, what I did next and some of the challenges I faced along the way.
The Need for Re-development
There were several aspects that made re-developing my site something 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 acceptable. After weighing the pros and cons of a responsive vs a separate mobile site, I decided on the former — and the only way to do that would be to start the front end build again from scratch.
There isn’t really an out-of-the-box solution for gift certificates in Drupal Commerce; there’s no module (at time of writing) you can simply download, enable and forget about. Being Drupal, there are many ways to skin a cat, so to speak, so in this post I’m going to outline how I got them working on a site I built.
Of course, the way your gift certificates work may well differ from site-to-site; I had a way I wanted it to work, but your requirements might be subtly different, but hopefully whatever your requirements, some of what follows is of some use.
To outline, here’s what I wanted to achieve:
Gift certificates available as products, which a customer can purchase
A range of values (Â£5, Â£10, Â£20 etc) available
A product display page that differed from “conventional” products — there are less fields required, so the layout was likely to be different
I wanted a customer to be able to specify a recipient for the gift certificate
The customer needed to supply an email address for the recipient, so we can send it to them via email
I wanted the customer to be able to specify the recipient’s name, to personalise the email
The customer 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
There ought to be an optional text field to add a personal message
The gift certificate needed to be sent out via email when the order was completed, and paid for
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. For example, you may have a number of blocks throughout the site but once they have been placed in the correct region and the visibility correctly configured (which often isn’t the simplest of processes), you don’t want content managers to change those settings. You do, however, need to allow them to change the title as it appears to site visitors, and of course the content. This isn’t possible out-of-the-box; luckily, it’s not that hard to do. Inspired by kiamlaluno’s post on Drupal Answers along these lines, I’ve knocked up a simple module to make permissions granular enough for just a situation. It’s incredibly simple and somewhat limited, but it does enable to you to grant or deny access to each part of a block’s configuration, i.e.:
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. Rootcandy is a perennial favourite, and comes in three flavours; standard, fixed (i.e. a fixed width) and dark.
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**
Google helped to an extent; the problem, it seemed, cropped up with a number of installation profiles and it’s during the execution of hook_profile_modules() that it appears. The most common cause, it seemed, was to do with the JQuery UI module, and in particular the link to the library itself, which you have to download separately. I had no such problem, however — thanks to a couple of lines in my (Dush) make file it had already been downloaded, and removing JQuery Ui from the list of modules to install didn’t fix it. Nor did excluding date_api, another module with which this problem can occur. In the end I had to go through each of the modules I wanted my installation profile to enable for me — a lot of them — systematically in order to find the culprit. The culprit, it turns out, was robotstxt. Hope this is of some help to someone — I’ve wasted hours of today! (I should point out, by the way, that this probably isn’t the fault of the module in question!)
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:
drupal_execute has gone altogether from Drupal 7. Instead, you need simply replace any call to drupal_execute with the new function drupal_form_submit (see the documentation). Otherwise, everything (from the point of view of your syntax) remains the same. Don’t forget to use form_get_errors() to ensure that the form has validated.
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:
Since colour-coding may only be appropriate to certain vocabularies (e.g. categories) and not others (tags, perhaps). We need to provide the user with the option to specify which vocabularies are applicable.
The user needs to be able to specify a colour when adding or editing a term, where appropriate.
We need to provide a mechanism which allows the colour associated with a term to be stored, retrieved, and to be displayed.
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? Step forward Peek, which allows you to do just that. Simply designate a content type “peekable”, then depending on the settings per-content type, set your node as “peekable” too. You can then grant a “peek” — a window of time during which a specified user can, by following a special link, gain read-only access to that node. You can configure an expiry time, the length of time it’s valid for and opt to be notified when the content is accessed. It’s a great little module.
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. Here’s how. First, you’ll need to download Prowl from the App Store — at the time of writing it costs Â£1.79, or $2.99 in the US. Next up, you’ll need to create an account on the Prowl website. Then, you will need to generate an API key — you can create as many of these as you wish, and there’s no additional charge for doing so. As you can see from the screenshot below, the API Keys tab shows any existing keys, and the form at the bottom is used to create a new one — all you need is a note to remind yourself what it’s for. Enter something to do with the site you’re adding, e.g. “My Drupal Website” and hit Generate Key