Canberra: +61 2 6162 8300Contact OPC
You are here
Home ›OPC IT Web Development Articles
by: James Sinclair
on: 20 Mar 2011
The Features module is something of an enigma. Some Drupal developers get really excited about it, but it can be hard to understand why. Installing the Features module adds no new functionality to your site. From a visitor’s perspective, the module does not allow your site to do anything that it couldn’t do before you installed it. So what, exactly, is the Features module for?
Why use Features?
The Features module does one simple thing. It allows you to take site configuration settings and store them as in a file as a sort of mini-module1. This might not seem like such a revolutionary thing, but Drupal developers get really excited about this. The reason is that storing configuration in code allows you to do two very important things:
Re-use configuration settings; and
Add configuration settings to version control.
Allow me to explain why these are such a big deal…
Re-using configuration settings
One of the most attractive features of Drupal is that by installing modules and using the administration menus, you can build a sophisticated website without writing a single line of...
by: James Sinclair
on: 15 Mar 2011
What is Drush?
Drush is a tool that allows you to perform common Drupal tasks from the command line. According to the Drush project page:
Drush is a command line shell and scipting rinterface for Drupal, a veritable Swiss Army knife designed to make life easier for those of us who spend some of our working hours hacking away at the command prompt.
To give a quick example, I can use Drush to enable a module by opening a command line and typing:
# cd /path/to/drupal/
# drush en views
Why use Drush?
So, why would you use Drush when Drupal already provides such nice user interfaces (especially with D7)? There are two main reasons I use Drush: speed, and scripting.
Speed
Using a command line tool to do common tasks is generally faster than using the web-based interface. This is very well demonstrated by the Development Seed video: Drush: More Beer, Less Effort. If you don’t have time to go watch that however, I’ll provide a quick ...
by: James Sinclair
on: 09 Feb 2011
The WYSIWYG module for Drupal is great for consistently managing WYSIWYG editors. At OPC we primarily use it with CKEditor. Now, the makers of CKEditor, CKSource, provide a very nice file browser called CKFinder (and although it’s not free, it’s probably worth the license fee). Unfortunately, until very recently you could not use the WYSYIWYG version of CKEditor with CKFinder, without following a rather complicated installation process.
As suggested by sun, we’ve created a WYSIWYG/CKEditor/CKFinder bridge module for Drupal 61. It should make the process of installing CKFinder slightly easier (although, unfortunately not completely automated). You can download (or fork) the source from Github:
It’s very rough, and needs lots more testing, so please try it out and let us know how it...
by: James Sinclair
on: 22 Nov 2010
I had thought using sub-themes was standard practice in the Drupal world, but I keep coming across sites where someone has taken a Drupal contrib theme, and hacked it to suit their purposes. If you’re thinking about hacking a contrib theme, I recommend you stop and have a good hard think before you do so. It may save future-you a lot of work.
OK. I know. We’ve all done it. Either we didn’t know Drupal had a sub-theme feature, or it just seemed like too much work at the time when we only wanted to tweak a few colours here and there. But after inheriting a few of these projects now, I can tell you that it’s really not a good long-term strategy. A sub-theme is a much better approach.
The beauty of using a sub-theme, is that instead of directly changing the contrib theme’s files, you just override the bits that you need to. This is especially handy if you only need to change a few CSS rules and the odd image. Using this approach, when the hard-working Drupal security team finds a vulnerability in the base theme, you can just download the update to the base theme, check that everything looks OK, and carry on your merry...
by: James Sinclair
on: 05 Nov 2010
I wrote previously about using Drush and Git to deploy Drupal websites from development to production, and that all works fine if you have a single-site Drupal install, but what if you have a multi-site setup? Leaving aside for the moment how you partition your version control repository, the main issue with deploying Drupal multisites is that they are name-based. That is, you typically create a multisite Drupal install by making a new subfolder in the sites folder that has the same name as the hostname of your subsite. For example, if you have a Drupal site hosted at www.example.com and you want to create subsite for mysubsite.example.com using the same Drupal instance, you create a folder in the sites directory called mysubsite.example.com. The trouble with this is, your development server usually has a completely different hostname from your production server.
The easiest way to get around this is to use a symbolic link. So, if you have a development server with the hostnames example.local and...
by: James Sinclair
on: 01 Nov 2010
A quick note on how to disable CSS caching with Drush.
While I’m developing a theme, I usually leave CSS caching off so I can make changes and see the result straight away. Once the site is deployed however, I usually pull back an exact copy of the production website before I do any maintenance, including the settings from the database (for small sites without sensitive data anyway). This includes the settings that turn on CSS and page caching. So it typically happens that I will start updating the sites’ CSS, notice that my changes weren’t showing up, and quickly work out that CSS caching was still turned on.
I eventually got sick of having to log into the site, navigate to the performance page, turn CSS caching off, wait for the page to refresh… and so on, before I could see the CSS changes. So, I worked out how to do it from the command line:
drush vset preprocess_css 0 --yes
And if you just want to clear the CSS cache for one shot:
drush cc css+js
I hope that comes in handy for someone.
by: James Sinclair
on: 16 Sep 2010
A good software engineer will tell you that you really should use some kind of version control when developing your software, and good Drupal developers will tell you that Drush is fantastic for downloading module updates and general maintenance of your Drupal install. But how do you make your Drush and Version Control play nicely together? This article looks at using Drush together with Git to manage updates to your production Drupal site. This builds on Simon Hobbs’ extremely helpful article on setting up Drush Aliases. It also assumes that you’ve set up Git on both your development and production servers1, and have set up SSH keys2 to make life easier.
Introduction
Two of the most valuable lessons I ever learned as a web developer, I picked up at a Web Directions South workshop. The lessons were:
- Only ever make updates to your production sever...
