It's a Drupal site... it's good if you actually know Drupal

I'm working on a Drupal 7 project right now where the site was built by another company. This isn't the first time I've “inherited” a project, and I'm sure it won't be the last. Before this project, my other experiences with taking over existing Drupal sites weren't terrible. Yeah, there were issues with the sites and things could have been better architected but, on the whole, I could jump in and figure out how things were glued together and fix issues or make improvements as needed without too much head-scratching.

This project, on the other hand, might send me to the doctor due to deep wounds in my scalp! Ugh. And, unfortunately, I pretty much saw it coming. The folks who built this Drupal 7 site weren't Drupal developers at all. They were Ruby developers. I don't know anything about Ruby but, I do know if I was asked to build a complex site with Ruby on Rails, I would graciously decline the request and, ideally, point the would-have-been client to a better fit.

Unfortunately, the Ruby development company didn't do such a thing and decided to build this Drupal 7 site... making them unhappy (they built such a strange beast and then their client left them), making their ex-client unhappy, and ultimately making every developer who has to touch the site unhappy too. I keep trying to find out how certain things were implemented and thinking... “WTF, why did they do that?” Or... “It would have been so much simpler if they had done xyz instead.” And, so forth.

Which got me thinking...

There aren't a lot of resources I've come across that give tips and strategy on application or site architecture in Drupal. You can find tons of “how tos” on Views or Panels or Drush, but what about discussions of when to use or not use Panels or what content should be in a block versus a node versus a Panel pane or what type of navigation mechanism best serves your site audience.

So, for now, I'm going to sketch out some buckets of things I think of when I'm architecting a new Drupal site. Please leave a comment if you have more ideas or you have good resources for Drupal site/application architecture.

Content is still king and queen...

Content is the reason for a website. Before Drupal 7, content was synonymous with nodes. In Drupal 7, things have been abstracted and content now includes all “entities” such as core entities (nodes, users, comments, and taxonomy terms) and custom “entities” (Commerce products, Organic Groups memberships). And, you can also add content via the configuration of blocks, views (e.g. headers / footers), panel panes, etc..

Knowing where to put your content is a big part of the application architecture in Drupal. Some things will be obvious (user fields should belong to user entities) but some might not be so straightforward such as an address that might be applicable to several pages. In the latter case, the “best” method (or methods) for storing the address information depends entirely on the short and long term use of that content. Just because it is easy to throw something in a block and enable it on a page doesn't mean that is the best solution to the problem.

It is important to think carefully about what type of content you have and how it maps to Drupal's entities and components. Think about how content might be reused across the site or consumed in other ways (email, feeds, search, etc.).

To Panel or not to Panel...

Site structure is another big Drupal architecture item. There are several different approaches to handling the structure and layout of a Drupal site. You can go for out-of-the-box “simplicity” and stick with the core block administration. This would be fine for a very simple site where the layout is the same across the whole site. But, once you need more flexibility, then you'd be better off choosing a different option such as Panels (and friends), custom theme templates, Context+Spaces+Display Suite, etc.

There are always trade-offs when choosing one strategy over another but there tends to be two camps:

• I love Panels
• I hate Panels

I happen to fall into the first camp so I haven't ever even played around with Spaces. It would be good to read some intelligent and thoughtful discussions comparing these strategies. I'm sure there are some out there (leave a comment!).

Cross your fingers and press the deploy button...

I wish there was a good, simple, reliable “deploy” button in Drupal. Maybe some day... For now, we have several technologies that we need to consider when thinking about deploying our site from development to staging and from staging to production. Remember that we need to consider deploying both “configuration” and “content.” One way to handle content would be to allow editing on the production site but set up revisioning and workflow logic that makes sense for the site. If you want to edit content on the staging server and then publish that out to the production site, hats off to you if you get that working well (and leave a comment! :).

For the some of configuration pieces, we can use fun tools like Features, Apps, Drush, rsync, Jenkins, Hostmaster/Aegir, etc. Again, there are trade-offs as usual. No doubt your system administrator will have a strong preference on what technologies to use (or not use). Some times the client won't have a preference or sys admin and you will get to decide what to do, and other times there will be little room for creativity.

It's not just the pretty stuff...

One other application architecture bucket is theming. Do you need a mobile-friendly theme, a responsive theme, or an adaptive theme? These all mean different things. Do you want to work on a grid system? Do you want to build a theme from scratch, use a base theme, or take an existing theme and modify it?

Zen is a popular base theme but is very bloated. Some themers like the flexibility available with verbose themes like Zen while others prefer to build themes from scratch so they have minimal markup. This is another area where there are definite “camps” of themers though the number of camps is probably pretty large...

Of course there are more...

I've just touched upon some of the things that I think about before developing a new Drupal site. There are many more things too!

• Use of taxonomy terms and categorization
• Navigation structure at different levels of the site
• On-site search engine optimization
• Language needs and internationalization

What do you think about?

Leave a comment :)