It's been a long time coming but we finally launched a new website.

Websites like these are a dangerous thing for a software house.  The temptation is great indeed to go out and build something from scratch that perfectly meets your needs.  But that invariably turns into a quagmire.  Although we could have thrown something together using any number of frameworks, invariably six months from now we'd want to tweak something and we'd have to start hacking at it.  Fast forward a year or two and nobody wants to touch it.

This time around we decided to use Drupal.  We've used it a bunch in the past, as a matter of fact, our last website used Drupal too, but things have changed quite a bit in the Drupal world in the past few years.  Before, we would hack on Drupal and it's templates a while to get things looking ok, but invariably our product pages, blogs etc, would end up with custom formatting because Drupal couldn't easily store our data in a logical fielded form.

That has changed dramatically with the powerful combination of the CCK, Views and Contemplate modules.

As an example, let's look at one of our product pages.  Each product contains some logical fields, say:

• Title
• Description
• Screenshots 1-4
• Captions 1-4
• Store URL

In the old Drupal, and indeed in the vast majority of CMS systems, you would probably create a generic page for the product.  If you were especially careful, you would then put each of those fields in it's own DIV so that you could later change the style and layout of the page.

This works reasonably well, but has a few big drawbacks.

1. Adding content is a pain.  At best it is a clone of an existing node, then carefully inserting your values in the appropriate DIVs.  This is not only obnoxious but error prone.
2. You can only change the layout so much.  Although almost anything is possible using CSS, some things are just not possible.  Want to change the order of your fields entirely, or insert a new DIV?  You'll have to go edit each and every one of those pages you created.
3. Adding non text fields, such as images or videos, is burdensome.  Even using a good editor such as fck, you have no validation of the sizes of the images or ability to customize those images as they come in.

In short, using plain pages with markup when you really have structured fields you are trying to render is a hack, and one that quickly catches up to you once you have a non-trivial amount of content.

CCK solves this by letting you create new content types in Drupal.  For this website, we have a specific type (or 'class' if you will) for an iPhone product.  That type contains the appropriate fields, and when add new iPhone pages simply by creating a new node of that type.  This is what you might call the 'Model' for our content.

To render these content-types, we use the Contemplate module, which allows for custom teaser and body templates per content-type.  This is simply a php template where we merge our CSS markup with our actual content.  You can think of this as the 'View' for our content.

Lastly, we use the Views module in order to create custom views of our data.  You can think of these are SQL views, or stored queries into our content.  A view defines a set of nodes, filtered by content-type or any other criteria, filtered and sorted as we wish.  These are in turn included on pages or create new pages entirely.  An example is our iPhone page, which is simply a query of all our published iPhone nodes.  This can roughly be thought of as the 'Controller' for our content.

Using these three modules (and lots of others for the other bits) our new website is both incredibly easy to maintain and ready to evolve as we do.  Changing the layout is done in a single place for each content-type, and one change is reflected across all instances of that node type.

Of course things are still new, so perhaps we will find some flaws in this system, but so far so good!  We'll make sure to keep you updated with any challenges we come across.