How I rebuilt my website on Drupal 7

I built my last website when Drupal 5 was still considered hot stuff and Drupal 6 was a mere dream – in other words, a long time ago. It did me very well, but I let it languish and age until it was unreasonable to work with any longer. This primarily occurred because I had not built it sustainably and it was much too cumbersome to make modifications. This time around I vowed to build in a sustainable fashion that would leave room for growth.

I am going to outline just how I did that! This post goes over my planning, how I broke up the functionality into discrete feature modules, and give you the code.

Scope and project plan

Regardless if it is for a client or a personal project, you always should think about the scope and outline a project plan. If I am going to rebuild my website from scratch, I should not just copy it blindly. In this project, I was fortunate to have prior experience to work from. What worked, and what did not? What was important?

I realized the most important aspect of my website is the blog. This is what allows me to engage with the community and is what brings in potential clients. People have demonstrated that they like to read about what I have learned, and will email me and talk to me at events.

The next important aspect of the website is my portfolio. This is not a crucial feature because no one looks at my portfolio except potential clients. My portfolio is only a priority if I need clients, and since I don’t need a client right now, completing the portfolio section is not urgent.

I had initially thought I could not possibly launch without a “home page” and then realized that a homepage is yet another feature of a website that has its own priority to weigh against the other features. My actual user base focuses on blog posts linked to from a RSS feed, and a rare few will go through the blog listing. No one actually cares about my homepage, so it is OK to design and build it out later!

Everything else is superfluous and would essentially be a waste of my time and energy to work on. Who has spare time and energy for personal projects? Almost no one, so we have to focus on what is important.

I sat down and started to design – but where do I start? Most people start on the homepage and grow out from there. Unfortunately, it can start to get awkward as you cram in necessary features in the other sections of the website. I fell into this trap with the design of my previous website which is the primary reason why it could not grow with me. I had let design trump function, and I should never do that again.

The first thing I designed was the blog page. If the the blog is the most important part of my website, it should function flawlessly for its purpose. I thought about what was important for reading blog posts and oriented my design around those priorities – easy to read text and minimal distractions.

I am doing this rebuild iteratively. I decided that I should design and build out each section one by one, and not design and build the entire website at once. How many times have our clients held up deployment because of something minor? Simply because it was not perfect? A website is virtually a living entity because it changes and matures over time. It is impossible to pop out a mature, adult website right off the bat!

Once I got my priorities all straightened out, I came to the conclusion that I should design the blog page, build out the blog feature and launch the results of this first iteration when it was complete. This saved me an enormous amount of time, and kept me motivated by providing small chunks to work on without becoming inundated by the entire scope.

Building the theme

Allowing form to follow function also allowed the theme to be more simple and straight forward. Past experience has shown me the theme is the most brittle part of the website because they are built without sustainability in mind. People often solve the problem they have in front of them without taking into account the possible situations that will occur in the future. This way of thinking is the most likely to cause the developer to get frustrated and say, “Argh! Lets just scrap it and build it from scratch.”

When choosing how to style things, focus on how that object will appear and function in other contexts. When styling a table, keep in mind how it works in the content of a post and as a management screen. First style the common denominators and then branch off to the specific contexts. The most frustrating thing for the entire dev team is a new section that is so broken it is barely readable because the themer built things without growth and change in mind. It is even worse when it happens to the maintainer and the original themer is no longer available!

This theme is built with Zen as the base theme. Using a base theme is crucial in ensuring sustainability. In much the same way that we like to use open source software because it has had hundreds of people vet its usefulness, base themes have grown over time with many use cases and modularity taken into account. It would be naive to think you could build a one-off theme that would rival the sustainability of a strong base theme.

This theme is almost entirely CSS. Zen provided me everything I needed, and if I did not know PHP, I could have easily lived with the edge cases it couldn’t give me out of the box. The instances where I did do some coding are as follows:

• Moved comments out of #content. I wanted comments to have more room and span both the content and sidebar columns, with the author information displaying like it was in the sidebar. This required first removing the comments from the node display in template_preprocess_node() and then make them available in the page template through template_preprocess_page(). The page.tpl.php template was then modified to be able to output the comments in the right spot.
• Customized the submitted text. Since I am the only blogger, it is unnecessary to always display my name. I could have removed the submitted text completely and replace it with custom output, but felt modifying the node and comment templates was less sustainable then implementing template_preprocess_node() and template_preprocess_comment()
• Moved $messages to appear above the page title. It looked awkward in the original position and since I already modified page.tpl.php for moving comments, I decided it was sustainable to make this minor change.

All of those changes are so minor that if worse comes to worse, they can be abandoned without damaging the integrity of the design. Since I used a base theme, it can be easily upgradable. In fact, I bet if I had done this in Drupal 6, I would have had little to no changes to make when porting it to Drupal 7 because Zen took care of the hard part and maintained their themer-interface through the upgrade.

Developing the blog

Firstly, deployment is very important, and leaving all your configuration settings in the database is not conducive to sustainable deployment practices. Luckily, leaps and bounds have been made to improve this process by using the Features module.

Storing all your custom configuration in one huge feature module will make it difficult to maintain in the future. You, and the you you will become in 18 months, need to be able to jump directly to where you need to make your modification. The more stuff you have to sift through makes it more difficult to find things, understand how things relate to each other, and see dependencies.

With that in mind, I built my blog as a discrete feature module. Everything that holds together the blog is located in one place. Using the Features module, I was able to build out and export to code the vast majority of the functionality I desired without resorting to coding. The only things I had to write code for were the following:

• Change the title of the tag cloud block provided by Tagadelic
• Add a “continue” link to the very end of the paragraph of teasers, without a line break

Just as it was with the theme, these changes are minor and can be abandoned if they become tedious to maintain during an upgrade.

Out of the box, Drupal 7 allowed me to create a blog content type, with an optional summary, file attachments and free tagging of content. I had to use the Link module to provide the related links fields.

I wanted the attached files, links and terms to display in the sidebar. In core, I was able to control what displayed on the node page and hide those fields from outputting on the node. I then used the Views module to create blocks that display field data based on which node is currently displayed.

All blocks are set using the Context module instead of using the native block management. Context allows you to associate blocks with features (using the ‘tag’ field when creating a context) and then export that configuration along with your feature module.

The listing page is provided by the view, which is configured to add a link to the secondary menu. Using views context, I was able to support listings with the paths ‘blog/[yyyy]’ and ‘blog/[yyyy]/[mm]’ and even change the title depending upon what dates you are viewing. See an example year, and example month.

Recent comments and popular posts blocks that appear on the blog listing’s sidebar were easily created by views, and the tag cloud was provided by the Tagadelic module.

I created a new role specifically for this feature and attached all related permissions to that role. This furthers the goal to create a discrete feature by isolating even the permissions.

A simple management screen was added via Views as a local task to the main blog listing page that is accessible only to bloggers. It displays all blog posts created by the viewer, and allows them to find published and unpublished posts, sort through their content, and view comments and hit counts at a glance.

In my last website, I had used the Workflow module to provide a draft, embargo, published and unpublished states to blog posts. In the interest of building out iteratively, I left that feature out and will just use the ‘published’ flag provided by Drupal core.

All of this functionality is completely encapsulated in one module. In the future, I can take it out and replace it with another blogging module without getting entangled by my other custom code!

Contributing my code

I contributed all of the non-specific functionality I created in this iteration, and will continue to do so in the future.

• Blogging
  Provides all of the blogging functionality described above.
• Blogger profile
  Allows bloggers to provide summaries and bios about themselves, and the summaries automatically appear on the sidebar of blog posts they create.
• Markdown-based format
  An extremely simple module that configures a ‘markdown’ filter format, with restrict HTML, code filter, converting URLs to links, typogrify, and markdown filter.
• environment_readonly module for the Environment project
  Automatically creates a readonly state and allows you to configure which roles should be affected by this state, and which permissions should be revoked when in a readonly state.

Whenever I built out something that could be generalized, I made that functionality its own feature module. As I was configuring my filter formats yet again I decided I should spin it off into its own feature module so I can use it on another site I build in the future. And then I realized, “If I can reuse something, so could someone else!”

Wrapping up the details

Of course, the blog and theme is not the only thing I had to build out here! One advantage of choosing to build out a small feature first is that it forced me to set up the base configuration options that all of the rest of the features will build upon.

The other things I had to add were:

• Set up the site wide contact form
• Mollom to filter out spammer comments so I can allow anonymous commenters. I really hate capatcha’s so I like that it first analyses the comment’s text.
• Pathauto to automatically set my blog posts’ paths as ‘blog/[yyyy]/[mm]/title’
• Extlink to alert readers when a link will lead them to another website
• IE 6 No More because this is my own personal website and I don’t have to support IE6 if I don’t want to
• Masquerade to allow me to flip back and forth between user1 and my personal account. Just like you should not use the administrator account on your personal computer, you also shouldn’t use user1 for day-to-day use!
• Redirect because since this is a rebuild, I wanted to make sure I could maintain my old paths
• Environment to set up development, readonly and production states for the website

I was amazed at how long it took me to build out this first iteration. I am a very experienced Drupal developer, and encountered nothing confusing about using Drupal 7. And yet, it took me 40 to 50 hours of work from the initial installation to deploying it live. This experience has confirmed for me that although everything may seem straight forward and simple, but the devil is in the details.