Drupalizing a web project

I've been asked by students in the four-week Drupal course I'm doing to share some thoughts on how to interpet web projects in Drupal terms. I first thought I should make a screencast about it, but then I realized that written text is probably much better. (It came as a surprise to me, but not everything has to be screencasted.)

When using Drupal for web projects, you will save yourself a lot of work by following what's sometimes called the Drupal way. I usually describe this in the following way:

  • Use community-provided resources as much as possible. Contribute as much of your work as possible back to the community.
  • Rely on the big, stable and widely used module frameworks (plus core) as much as possible.
  • When these framework modules aren't enough, try to patch them to make them fill your needs.
  • When patching isn't enough, try to write extension and plugin modules for these frameworks.
  • When extending these frameworks isn't enough, try to some the needs by writing modules of enough quality to be contributed to drupal.org.
  • Only as last resort, do small hacks and custom code that are used on this site only.

What does this mean, in practice? When trying to sketch out a web project for Drupal, I usually do it this way.

Step 0: Try to understand the project

Before starting to map anything out in Drupal terms, I sit down and think about the project. More important than getting any technology working is to understand the needs of the client. Important first step is to read any description or specification that the client has provided, but you also need to talk directly to the client. Often more than once.

It is difficult to overestimate how important it is to think about the project as a whole. Sometimes this leads to the conclusion that it shouldn't be implemented in Drupal. Sometimes the conclusion is that the specification and the actual needs of the client are too far apart to start sketching any technology solutions. Often it leads to identifying a number of critical spots. Or identifying tasks that will be difficult to implement, and take as much time as the rest of the development put together.

This text, however, will not focus on these matters. It assumes that you have good understanding of what you want to build with Drupal, and want to move on to sketching out a Drupal solution for the project.

Step 1: Map out content types and entities

When actually starting to analyze the project in Drupa terms, my first step is to identify content types and other entities for the site. You will probably find a number of content types waiting in line to be written down, and you will probably have a number of more tricky cases. Should this thing be taxonomy terms, or content types? Should we have several user account profiles? Should this information be a field on another entity, or should it actually be an entity of its own?

The answers to these questions, ultimately, lie in what you will make work. On more complex projects you can expect to hit one or two dead ends, no matter on how hard you try to think ahead. Keeping these questions in mind will hopefully help you minimize the dead ends:

  • How to you need to control access?
  • How should the information be reused and accessed across the site?
  • How should content/entities/information be related to each other?

At this point I also try to sketch out fields that should be used on entities. The by far most important field type are the reference fields (or, when applicable, relation managed by the Relation module) – other fields can be changed later on without you having to rework your map.

Step 2: User and access

My next step is often to look at the user groups for the site, and what tasks they should be able to do (or prehibited from doing). It doesn't make sense to actually create permisions at this stage, but knowing what tasks should be available to (for example) site editors will guide some decisions about what modules and technologies to use. If an editor should be able to add just about any content to just about any sidebar, you need to think about how this can be done in a safe way.

At this stage I also think about what kind of access modules are relevant for the site. Is Content Access enough? Do I need ACL as well? Is this a good case for Organic groups? (Managing customized content access is not a part of this course, though.)

Step 3: Views and accessible data

My next step is often to look at what different views are needed on the site. Many of these lists are often more or less trivial to create in Views, but there are usually a few lists dynamic that require quite a bit of thinking. What data is necessary to create this list? How can Views access that data? Is there a risk of getting duplicates in the list, or creating really heavy queries?

In almost all cases, even very tricky lists can be accomplished by using contextual filters in Views and using Page manager to pull together the data necessary to populate the contextual filter. Prototyping these lists right away can save you quite a bit of time – sometimes you assume that the data will be easily accessible through Page manager's contexts, and it turns out that you really should change the direction of a reference field, or change a text field into a term reference.

Step 4: Describing Rules tasks

Most sites have a number of custom actions and functions that editors or site visitors should be able to perform easily. Often times, this can be done using Rules and Views Bulk Operations (or just Rules if the actions should be done without any user interface). The most difficult part to analyze here is the same as with Views: Is all the necessary data available?

Some examples of custom functionality that can be managed with Rules + VBO are:

  • Scheduling items to appear on the front page or at other places.
  • Allowing users to subscribe to comments or content updates.
  • Adding selected users to lists of different sorts.
  • Automatically tag content with terms selected in a clearly specified way.
  • Automatically create relations between content, in a clearly specified way.

Some functionality is too big or specialized to be managed by Rules in any sensible way – such as e-commerce sites. These cases are not discussed here.

Step 5: Taking care of the leftovers

Interpreting a web project in Drupal terms is like laying a grid over the project (or using a cookie cutter on a piece of dough) – you will have things sticking out that doesn't really fit the pattern. Not all data may be captured as entities and fields. Not all data may be fetched with Views. Not all actions may be done with Rules.

These non-conformant parts must be analyzed and taken care of. I try to do this in the following ways, most preferred on top:

  • By writing extensions and plugins to the existing modules. If it makes sense, this new functionality should be provided as a patch to the main modules, or to modules extending them. If nothing else, the new functionality should be a full or sandboxed project on drupal.org – just to make the code publically accessible.
  • By discussing with the client and suggesting slightly different functionality that would give (almost) the same end user service and would be much easier to implement.
  • By doing custom tweaks and hacks – for example by using complex form alters or preprocess functions. As always, it is good to ask if the necessary data is avaialble, and if the code may become heavy to run.

Note that none of these steps are actually implemented at this stage (apart from discussing with the client) – this sketching is only to make it plausible that the functionality can be implemented later on.

Other analysis

There are some aspects of project analysis that are not covered in this course, but are important when doing real-world projects. The more Drupal (or web development) experience you have, the easier it becomes to spot additional aspects. Some of the more common ones are:

  • Performance and scalability. While some sites have greater need for performance (page load time) and scalability (surviving many visitors), these are aspects that should be considered in all web projects. Some important questions are (1) are there any particularly heavy operations on the site, (2) how does the front page perform, (3) how many logged in users are expected and (4) what potential difficulties are there for caching?
  • Localization and internationalization. Building sites in a non-English language is usually no problems, but doing fully multi-lingual sites means that you have an extra dimension to consider in just about any part of the sketch you're making for the website. Gábor Hojtsy has written an excellent series about managing multilingual Drupal 7 sites.
  • Migrating data. Taking care of legacy data is a project in itself. My best advice on this is to start as early as possible, work as closely as possible with someone who knows the source data well, and never set a fixed value of how much time the migration work will take. Also, use the Migrate module.
  • Integration. Most sites nowadays want to interact with data on other sites. In the simples form that means continously importing (and possibly updating) data from an external source, but it is often more useful to be able to fetch live data from other places without having to making it internal. For the former the Feeds module may be useful, and for the latter Views might be awesome.

Some example projects

In this courese you should build your own Drupal site, implementing a number of the techniques included in tutorials and exercises. I am convinced that you will learn the most if you have your own idea of what you want to build, but the list below may be useful as inspiration or fallback if you don't come up with any idea of reasonable size.

  • A multi-user blog.
  • A photo gallery.
  • A forum or simpler community site.
  • A presentation of a company where staff is divided between several departments or offices.