Nodestream: a distribution for news sites

Reviewing a Drupal distribution that provides a good starting base for newspaper websites.

Photo of Salvador Molina Moreno
Mon, 2011-10-10 10:47By salva

Recently I have been involved in a website project for a large media company. While living in Spain (where I am from), I used to be editor and editor-in-chief for a top videogames magazine, so although I joined Code Enigma when the project had already started, I was lucky enough to have some experience and knowledge in the sector that helped me to understand the site structure and our goals.

There are many new things that are standard in the media sector, always requested by the majority of clients. When you usually work on these kind of projects and have to face similar problems from one project to another, the next natural step, as an engineer, is to try to find a re-usable solution. 

So, what is Nodestream?

In the search of these reusable components, I was asked to check out the NodeStream Installation Profile, contributed to the drupal.org community by the nodeone guys, who present it as a platform that “simplifies the editorial board's workday by means of a smooth work flow for editors and writers”. In essence, the NodeStream distribution offers a good base on which to build a website that aims to provide a stream of content in the way that large magazines and newspapers do. One of the main features that it provides out of the box is the possibility to set up landing pages for different sections or topics that a website may cover. This is done with the use of panels, but has almost no impact for the end user, since he doesn't have to deal directly with the panels UI.

One of the things I liked most of the nodestream distribution, was the content type that comes pre-packaged for articles - the most common stories or posts on the site. While it's nothing complicated, it comes configured with sensible defaults, and gives the user the chance to enable additional options for it easily. These options are basically new fields that will be attached to articles, like byline fields, webforms, polls or even 'facts' (you know, those small pieces of data that appear in a block embedded in the story). All of these are set up as different content types, and can either be created when editing an article or referenced if they are already stored in the database from before (for those of you who know it, this is achieved through the node relationships module).

Apart from the article content type, which seems to me quite complete, there are also other content types perfect for “drop & go”, like the Contributor or the Image content types. Every contributor node has fields for name, photo, description, email and a reference to the Drupal user that is attached to. On the image content type, there's also a field for a small caption, as well as a “Credit” field, so that the Contributor that has taken the picture can be referenced easily. The same applies to other content types (like articles), so displaying the information of the user that is generating content, is just a matter of referencing it, and the system does the rest. The following image shows how an article is displayed when the fields are completed (image, facts, poll, related articles and contributor in this case):

Obviously, all of the above may vary from one site to another, and each client will have its own requirements. The great news is that all the functionality comes pre-packaged through the use of the features module, making it easy to change anything and package it again for a specific project. For those who don't know, the features module is a tool for Drupal developers and site-builders, that allows to export certain elements of a website (nodes, imagecache presets, views, blocks, permissions, etc.) into code, so that they can be later imported to other websites, without having to worry about the database or having to make changes from the UI of a new site, to match the configuration of another site.

If there's something else as remarkable as the content types provided by default, it's probably the possibility to arrange content in different ways within the different site sections. The basic idea is that the user has different regions available for the different site sections that vary in width. With that in mind, each piece of content can be promoted to a specific region (in one or more sections), depending on the importance that we want to give the article. Once we have different articles in regions, it's possible to edit their positioning in an easy way, with options such as reordering them, changing the layout in which they are presented, or indenting ones within others (quite useful when several articles cover different aspects of the same new, and there's a main one that has the most important info). This is best understood by viewing the video demo available at nodestream.org.

Promoting content

One thing that stood out for me initially, was the fact that the nodestream distribution doesn't directly assign article nodes to regions on the different sections of the site. It does in a sense, “virtually”, since it is not the article that gets sent to a landing page, but a reference to it. Basically, what is being inserted in each region is a “promo” that contains a reference to the article that we want to see promoted. The good news for the end users is that by default, they don't have to care about this “middle-layer” between the articles and the site sections; nodestream takes care of this by automagically creating a new promo when a new article gets saved, and assigning it to the regions we selected when creating the article. So, the creation of promos out of the regular workflow is always available if we want to set up new promos for articles that are already promoted in a section of the site, but want to be also in a different section, and in a different way.

Although I didn't like this in the first contact (why would I need two nodes - an article and a promo - each time I created one article?), it now makes much more sense to me, since directly assigning articles to sections and regions is fine when all your regions look the same and you want the article to be in the same region, but not when you may want it to be in, for example, the sidebar and with a small thumbnail for the sports section, and in the main column, with a huge picture, for the front page. The possibility of having different layouts comes also as a feature, making use of the dynamic formatters module, so can be extended with extra custom layouts. The next image shows a region with 3 articles assigned. The layout selected shows 1 main article, and the other 2 in a small grid.

Nodestream is not the definitive tool for setting up newspaper-like sites. It has some UX problems that are not specially fun to come across when you are working, but these are caused by the contributed modules used for it rather than by the distribution itself. Yet, they're still minor bits that lie on developers hands to be fixed (after all, we enjoy working... from time to time). Overall, it is just what their authors say it is, a platform for building distributions, built with scalability and reuse in mind.

Personally, I understand it as a distribution itself, rather than a platform for building distributions, but despite conceptual differences, it's clear what it does. While I used the D6 version of Nodestream, there's also a D7 version, though. I had some problems with it and decided to focus only on the D6 version, since some of the features available in it are not yet in Drupal 7. Anyway, I encourage you to go and give it a try, you may like it, and it may save you some time. Just bear in mind that the Drupal 6 version is incompatible with PHP 5.3. You can find out more about Nodestream at the following links:

More about Features: