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 , ,

If you liked this article you can add me to Twitter
  • by technophile 21/03/2011 at 23:01

    Thanks, James. I read that work on the Relation module is ongoing. It is clear that as at today the path this module will take is far from decided; I found a debate about how the information will be stored (and what the consequences will be). I think if I read some more of the issues listed against the module I’d find more of the lively debate ;-)

    Thanks especially for the link to http://angrylittletree.com/11/01/drupal-8-road-ahead. I found many of my impressions confirmed there. Good to find someone capable of seeing the road ahead as a worthy challenge; for now I must try to pick my way through whatever the current release provides.

  • by James Stewart 20/03/2011 at 17:52

    For declaring relationships between nodes you can use the reference module http://drupal.org/project/references I’ve not used it, but I used some of its ancestors relatively successfully. There are some architectural decisions to be made as to what your site needs to consider a node and what is a taxonomy term, but hopefully that’ll become apparent as you model things.

    There’s quite a bit you can do in terms of generating pages and positioning things using the views module to generate blocks. Those blocks can then be positioned using the general block administration or something like the context module http://drupal.org/project/context

    It’s a bit of a faff to get started, but not too bad once you’re in the flow of it.

    And then when you hit on something you want to be able to re-use across projects (or just manage in code rather than the database) you can use features http://drupal.org/project/features to compile the set of dependencies and write out your content types, contexts and views to a custom module.

    And if you want to go the whole hog and create an installation profile, which will give you a base setup with a few more niceties than off-the-shelf-drupal. I’ve not got any good documentation on that to hand, but a quick search turned up http://www.mc-kenna.com/drupal/2009/06/building-drupal-installation-profiles which may be helpful?

    There’s definitely still an identity crisis in the drupal world between framework and CMS (as touched on in http://angrylittletree.com/11/01/drupal-8-road-ahead ) and there’s still a dearth of good “you’re an experienced developer and want to get to grips with drupal best practices” documentation. But hopefully these links will help a bit!

comment Further investigation of Drupal 7

Trackbacks are disabled

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