Drupal

We’re pretty busy.

The University is restructuring and so are the local research groups. This means we need to find a practical solution for producing a site for FPAS (our new faculty), for the School of Physics (our new chums in the new Faculty), and for 5 new research groups.

The current ECS research group websites are mostly database driven, and while they look quite different, they all have the same basic structure (news, people, publications, seminars, themes, projects). The Faculty and Physics site will initially just need ‘news’, with more dynamic content to follow.

And it all needs to be launched on August 1st. So the pressure is on!

Which CMS?

(CMS = Content Management System)

I had a good look around the University’s current CMS, Interwoven SitePublisher, and adding quick hookups to data sources involves firing up Eclipse and compiling Java connectors and that would also (probably) need to go through some kind of central approval process (although that’s just an assumption, but iSolutions have a lot of bureaucracy compared with our approach which can be more, er, relaxed.

The University is going to be using Sharepoint as a platform for many things, but the ECS webteam don’t really have any experience there, and again, getting code into it seems to require a huge stack of Windows-only software and it makes me tired and sad each time I try to get to grips with it.

Early Days in Drupal

I’ve never used Drupal before, but it’s a very well regarded PHP based CMS so decided to have a look. My first impression was that it seemed quite limited. Site publisher allows you to add pre-defined components to a page, so once set up it has some flexibility that Drupal doesn’t. Drupal just has a set of data fields for each type of page. You can extend your own and even add new renderers for types of field, and new types of field, but I couldn’t see how to do something rich. What I want is something a bit like the ‘compound’ field in EPrints, where you have a field containing a list of values, and each value is made up of several sub-fields. eg. Name, Email, Homepage. I think that can be done in Drupal using one node/page per item and then making a page which is a view of these, but I’ve not got to views yet.

What is really nice is that you can, for each page type, just create a php template that takes the fields data and prints the central content of the page. What is more confusing is when I want to get the actual values of the fields, eg. to use in a function call. Drupal passes values and sets and lists of values around as a PHP datastructure or object which is a bit confusing to me. I know I can pass it to a function called render(..) and that’ll return HTML, but I can’t find documentation (yet) for the other things you might want to do with it so I’m just poking around inside it which feels like I’m doing the Wrong Thing.

Modules

Drupal is a bit overwhelming and while very documented, the documentation doesn’t make it easy to get the basic concepts explained. The other thing you need to learn is that you will need to install additional modules. The key ones I’ve needed so far are ‘Frontpage’ which allows you to over-ride the default frontpage (which shows a list of recently added or updated pages, which is not what I want for our sites), Wysiwyg which allows you to use any of nearly a different javascript editors. You can also enable and disable the core modules. I found it useful to disable ‘comments’ module entirely and to enable ‘php filter’ which lets an supre user drop raw <?php tags into an HTML field and have them evaluate.

Oh, and the “Zen” template is a great idea, it’s a theme designed for subclassing. Took me a little while to get to grips with the concept but now I have it makes it easy to produce a set of on-brand University templates. yay.

Blocks

Blocks are page elements which appear on many pages. Some are auto-created by modules or the system, others you can create yourself. You can either say which pages (or page types) they appear on. I’d prefer it if some blocks could be selected by the person editing a page, but it’s set up the other way around. Blocks appear in page ‘regions’ which are defined in the page template (which is a template “above” the node template). The content of the page is one of the things that appears in a region, as is menus and login boxes.

I don’t think we’ll use blocks much, but I could be wrong.

Menus

There are several menus by default, Main, Secondary, Navigation and one other. The Main menu seems to be intended as the site “tabs” or similar, and navigation the detailed nitty gritty menu going down to all content. I’m just using navigation for our stuff. What’s weird is that “Add Content” is an option in this menu and when you add a new page type, it appears as a sub option under “add content”, but is only seen if you’re logged into the site. In my test site I’ve moved or disabled the “add content” menu item and it seems to add new “add page type XXX” menu options to the wrong place. My suggestion; leave it the hell alone, it knows what it’s doing. The menus render as just <ul><li>… HTML with lots of handy class tags to aid rendering.

CSS Support

Man, do they not skimp here. All lists have lots of handy class tags like ‘first’, ‘last’, ‘odd’,’even’, plus classes for their specific field types, field names etc. Really uses CSS to good effect. It’s what I was aiming for when we produced the EPrints 3 CSS, but really really well thought out. Might up bandwidth a bit, but that’s a very small price to pay.

Security and Accounts

I considered hooking up the login system to the University Accounts, but ran into some issues. First of all, LDAP is still a bit of a black art to me. There’s a lot of options in the Drupal LDAP module, but that’s no real excuse. A far bigger issue is that university passwords really should go over HTTPS, and that’s tricky for multiple sites on one server. Drupal doesn’t seem to have an easy way to have multiple sites log in via a single  https server. The other option would be to serve the pages over https with either a broken cert or a *.soton.ac.uk if someone would let me have such a cert.

For our sites, logging in is only for editing content, so I figure we just make local accounts. It’s not perfect, but it limits the risk. There’s a small risk of someone gaining access to the site by sniffing a password, but most editing will happen from inside our network so I think the risk is acceptable. Having someone’s real university password sniffed would be hightly unacceptable.

Database Intergration

As I said earlier, I’ve got data we want to show dynamically. There’s two cases.

Dynamic content in a page: For example including the latest few news items on the homepage. This can be handled either just by dropping <?php into the page and doing it old school, or if it’s to go in the sidebars, maybe I could make some blocks to do this.

Dynamic site areas: For example the projects section would consist of a list of projects, plus a page for each project. One Drupal approach is to create nodes from the data, but I kind of hate that idea. I’m veering towards creating a custom page type for such areas with minimal data. eg. just page title and ‘research group id’ then using that value in a custom template to do the heavy lifting, and have the project pages being /projects?id=123 – not pretty but it gets us started. Later I can do something clever either in the apache config to alias /projects/(.*) to /projects/?id=$1 or maybe Drupal has a way.

Deploying a new site

This is looking slightly worrying as it’s not as turn-key as I would like to get a new site set up using my templates. There’s a growing checklist of things to do to get the site ready, and they are almost all via the web interface. I can see a few options;

1. Accept the fact it’s a pain and do it the long way (soooo not our style)
2. Create a exemplar site and mirror the tables when deploying a new site
3. Investigate ‘drush’ a tool which lets you poke drupal from the command line.

I suspect the examplar is the way to go, but drush may be handy for some stuff too.

Linked Open Data

Rather than build our sites from SQL databases, I want to have a goal of having them entirely running off Open Data (possibly with caches). The aim is that all the data used in the site will be open, but the open data itself will be used to build the sites. We’ll probably compromise here and there, but it’s a good goal. Dave Challis has been quietly preparing for this for some time. Also it gives me a bit of an excuse to do some Open Data work (which I’ve been missing) while following my orders to focus on faculty websites *grin*.

Drupal for All

What I’m hoping is that we can provide the faculty (and maybe other members of the university) with an easy way to get a content-managed site set up very quickly and already using the university branding. The aim would be to complement the more formal CMS service offered by the central university. Currently the options are absolute freedom (you install it, good luck!) or the very restrictive service from the center. I think it may be useful to offer a middle ground where people want a little bit more freedom, and the ability to do the odd cool hacky thing, but for the most part just want to throw pages onto the web without having to learn much.

Why not Joomla (or CMS-X or CMS-Y)?

Because I was looking for something to fill a set of requirements. Drupal filled them so I stopped looking.