Further investigation of Drupal 7

My object in trying out Drupal 7 is pretty straightforward. I would like to have a platform for creating web sites at absolutely the minimal cost and within those sites give clients the greatest opportunity to create and curate their own content.

My test case is to build the most lightweight system imaginable for promoting events. It doesn’t bother me too much if there are some fields that seem rather specialised, because an event is a specialised kind of content, but the intention is to accommodate a wide range of events from, say, one-offs like a music recital or a two-day conference to repeating items like a theatre production. The events all need to be presented in the same way. By that I mean that it should be possible to fill out the information required in the same way whatever the event. We know that some events will have things like a speaker or a producer and others might have a musical ensemble, but it’s not a great idea if there are separate boxes for all those things (composer, speaker, director…) because it can get very tedious for the user adding the information to find the right one and to be confident it is correct.

So far

I haven’t yet found outcroppings of the stick-little-bits-of-php-in-a-database approach I remember from Drupal 4 (or was it 5?) back in 2006. I am not sad.

It is possible to use Drupal’s GUI to set up customisations of data and structure, but to modify the display of such information seems to require work on templates for the overall page and/or the subcomponents within pages. It is probably possible to use stylesheets to make quite considerable changes to the appearance of every page on a site, but for finer grain or to show and hide information within only certain areas will require template php files.

User-generated content lives in Nodes or Comments; clearly Comments are for comments so realistically a Node is the atomic unit for all user-generated content.

You can have as many specialised Nodes as you wish, and specify subsidiary content fields that are unique to one Node type or shared between different types of Node across an installation. I don’t really know whether Sites within an installation would share the specialised Nodes and have no insight into the workings of multiple Sites within one installation.

You can’t put a Node inside a Node, so you can’t have subsidiary content (for example, you cannot make a person Node and attach it as a child or property of an event Node).

You can use taxonomy to take often-repeated information (say, the room names in a building) and make it available as easy-to-insert fields attached to Nodes. Taxonomy is implemented as any number of Vocabularies containing Terms, and the Terms can have any number of fields attached to them. The obvious field is the set of words that make up the term, but there is also a description field by default and you can add more. But it doesn’t feel like Terms are a reasonable place to put things that will differ every time, like people’s names. Instead, Terms feel like proper nouns for concepts. And creating a Term in a Vocabulary has to be done before a Node that will need to reference the Term is created.

Next steps

There are probably hacks around these restrictions but they’ll negate the benefit of using a regularised, strightjacketed system such as Drupal is. Despite that, it certainly feels as if a little more prodding is justified because I can see that by accepting a compromise or two in the absolute beauty of the data structures I might have a reliable system in a matter of hours rather than days or weeks.

And did I mention that you can write tests for your own Drupal module code? That surely merits a look sooner rather than later.

Published on 19/03/2011 at 22:50 by Technophile, tags , ,

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn