How we did it in Drupal, Pt. 1 of X - The Data Structure
I wrote before about the new 34th Street Magazine website being in Alpha.
This is the first post of a series on what we did to Drupal to make it behave the way we want it to, how we implemented different features and to ask for feedback and advice on how to do future features.
To start out understanding Drupal, it’s important to understand that Drupal was designed and the developer’s focus is largely on creating flexible websites for communities, NOT for publishing or blogging. For instance, there isn’t a natural distinction between readers and administrators among the user roles. (Adding content is at node/add/* not admin/*) A lot of the work involved in setting up a site on Drupal is to work around the default values and settings and make it behave the way you want to.
Part of the joy of using Wordpress is that it’s defined for a very specific purpose and all the development work that goes into it is designed to make it easier to blog. With Wordpress, it takes very little work to go from a default install to writing your first post.
That’s not true for Drupal. No one would use Drupal with only its core functionality and the default settings. But with a little work, it becomes much, much more powerful and better suited for publishing a news website than Wordpress.
The problem I’m still struggling with now is how to import data into Drupal’s database. The database structure is quite complex compared to our current site, or a Wordpress site, but luckily the Content Construction Kit abstracts all of that when the site is being built. And that’s the topic of today’s post.
Nodes, Users and Custom Content Types!
Everything in our system is a node. Stories. Slideshows. Sections. Authors. Issues.
The CCK module lets us define all the different information each node needs and tie authors to articles and articles to sections and issues with node reference fields. Each content type is themed separately with a different template and the different ways that piece of content can be viewed are defined by a set of boolean PHP variables.
Our site uses the following CCK content types.
- Article - One article of the magazine. Articles have headlines, sub-headlines, date, image, related file and other fields defined in CCK. Articles also have node reference fields to identify who the authors of the article and what section the article is in.
- Issue - One issue of the magazine, corresponds to the print issue. An issue is a collection of node reference fields that point to different articles. Certain fields of the issue are mapped to different slots on the front page of the site.
- Photo Gallery - For photo essays or instances in which the image is the primary focus of the story. Behaves like an article in every other way.
- Author - Everybody who writes a story is an author node. These are not related to users in the system at all, as not every writer will have an account on the website and not every one with an account on the website will be a writer. It also means that we don't have to worry about deleting user accounts after writers graduate or leave. And while we haven't done it yet, it would let us create author profiles so our writers can each have a portfolio page that's more than just a listing of articles.
- Section - A section of the website, these are done as nodes instead of as a taxonomy term for largely the same reasons as authors are.
- Overheard at Penn - Overheard at Penn is a series of short snippets of overheard conversation. This is a very basic content type with just a single text field.
- PDF Version - A PDF of the print edition of the website. Created using the File Field module.
- Page - A simple static page.
- Newsletter Issue - The Simplenews module allows for the creation of newsletters. This content type creates a newsletter with a node reference to the issue to be sent, and generates e-mails. It's also integrated into the user accounts system, so everyone who is registered to receive the newsletter also has an account on the website to comment or for any user generated content areas we might decide to create in the future. Theming newsletters and HTML emails was an incredible pain in the butt, but that's the subject of another post.
At the database level
When creating fields and content types, this is all you see. Pick data types and title them. For the most part, the rest of the process is completely opaque. To learn more about the database structure of CCK, there’s documentation in greater detail here.
There are several tables that store data for CCK fields.
- node - This table stores the unique nid of the node, and what type it is.
- node_revisions - This table stores the body content of the node, as well as data about which user created it, when it was revised and what's in the teaser.
- content_type_[type] - If a content type has fields that are only used by that content type, this table contains the values of that field.
- content_field_[field] - Contains the values of that field.
Theming
A lot of the heavy lifting in Drupal is done at the theming layer. Luckily Zen makes it all much easier. That’s what I’ll be writing about next time. Some of the other upcoming posts will address how we handle images (Imagecache and CCK), how we theme our newsletters and how we handle multimedia.
What did you think of this post? Got more questions about our Drupal install? Leave a comment. The new website is at http://beta.34st.com, poke around and leave us some feedback!