Slightly Technical

In the heat of the moment, it seems that the further in I go the less I like the experience of learning Drupal 7.

A Drupal fundamental is to treat every piece of content as an instance of a single basic type (a Node – although apparently Entity is the new term :-S ). Having established the fundamental, Drupal adds nuance by making the Node an abstraction, providing specialised versions as the containers users will actually fill with content, and allowing users to create their own similarly specialised Nodes to store content that has different qualities.

Given the emphasis on standardisation at Node level rather than any lower, and the fact that real-world examples of Nodes can have arbitrary amounts of arbitrarily-named subsidiary data attached to them, it is essential to be able to look for data in each Node in a standardised and abstracted way. Otherwise the rationale for the overarching system disappears.

In practice it seems as if public modules have introduced increasingly complex Node types to perform specialised tasks in total isolation from one another. These modules have hard-coded subsidiary fields referenced directly by the functions that manipulate the data in the fields. Ironic given that all are supposed to derive from a common parent which provides the bulk of their functionality. I don’t want to do that: instead I want to enhance what any type of node can do if a user has put certain information into certain fields for that node.

I am having a lot of trouble using the Fields API to find out quickly and cleanly which fields are attached to nodes as I load them and from that to discover the content of each field in each node. This ought to be extremely simple for implementation developers. The alternative, which is to list and access fields by reading the array of data that belongs to each Node, is low-level, complex and hence inappropriate as much as inconvenient. It’s miles away from the sophistication I find in the functions which are in the API, and I can’t help feeling I am missing something very obvious.

There is some documentation, but it gets more opaque the closer I get to the tasks I want to be able to achieve and I feel that I’m working against the grain of the system. To make things worse, there is a depressingly incoherent tutorial in the API documentation which seems to capture the general lack of clarity about Fields. All in all, a little downbeat today.

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.