This topic as seem to come up again after I recently blogged about it a month or two ago. My original post at the time was more of a personal rant of things I had noticed since spending tons of hours working on my Omega base theme for Drupal. However, in the most recent topics, several things have sparked this discussion again, and I felt like it would be a good time to possibly clarify and expand upon my view of the situation, and how possibly to rectify it, and help others understand a more common set of guidelines to follow to create a "good" theme for Drupal.

The issue being brought up is the same, but the viewpoint differs on the very fundamentals of where this issue stems from. There are two sides to the story, and what is causing this issue:

• CVS/Revision Control is too confusing for designers/themers
  • Morten (morten.dk) takes the side, or initial opinion that the issue is CVS, and a long thread can be seen here.
• Creating a "generic" theme to apply to many or all use cases is much more complex, or outside of most client specific use cases
  • My original post can be found here from back in July
  • Todd, from Four Kitchens has a new post available here that very accurate expands on the complexity of the situation, and why it has NOTHING to do with CVS being too hard for Drupal designers & themers to use.

The goal of this article...

I really want to simply reiterate the point I made a few months back in a bit more clear terms as this topic/issue/argument has come up now in the community. I will touch briefly on both sides, but am unable to make a truly impartial post on the subject as I do lean very heavily to the side of the second argument.

Argument #1: CVS is stoopid, and I don't want to learn it badly enough to contribute

The simple fact is that CVS, which is the current version control used for Drupal.org is hard to use. It is hard for designers, and themers without a large PHP/coder background, but it's still tough and a sore point for even some long time developers (myself included).

Morten's main points are that CVS is a horrible pain, probably similar to "It burns when I pee". I can completely understand his point, and it IS a valid point. However, this to me just does not seem like it is the main, or even a primary reason why themes dont get submitted to drupal.org.

Argument #2: CVS might be stoopid, but the issue is theme complexity & use cases since Drupal is such a vast platform

This point of view is absolutely where I stand, and stand highly in agreement with Todd on the topic. The fact is that Drupal is such a complex system with an absolutely endless number of potential use cases, implementations, and contributed modules that properly designing a theme to handle all of it is near impossible at best.

Let's think for a minute about Wordpress. (Scary I know) While many of us Drupal developers/designers love to beat up on Wordpress, and I do it all the time until I offend someone, and then I go back and say "Yes, you are right, Wordpress is quite nice, I know it's easy to use and pretty". Wordpress is in fact a fabulous blogging platform... Let me say that again. A BLOGGING PLATFORM. If you only need to put together a blog, and your client doesn't have the need in additional phases to roll out new advanced feature sets, then Wordpress might be a great option. (Shit I can't believe I just plugged Wordpress)

When designing and theming for Wordpress, which it's been years now since I have, but the idea is still the same, you have one main content column, with your river of news, or single post pages, and you have 1 or maybe 2 sidebars. The content in the main zone is pretty much all the same, and the sidebar just populated by a group of widgets that print out some simple code. There's not much variation on what the final output is going to be. Simple content, and a sidebar or two. With that in mind, it is VERY easy to put together a knockout design, and theme it up for Wordpress and still have it work on many multiple Wordpress sites quickly and out of the box with minimal if any customization.

Drupal on the other hand is a much more complex, diverse system. We have a bazillion modules contributed by the community that provide functionality and markup that ranges from quite simple to insane.

When going into a design phase for a Drupal project, regardless if it's a personal blog/portfolio/etc, or a complicated client project, we have a feature list that needs to be implemented well beyond the just "Add some content" style of a blog. We rely on a large set of modules (Views, CCK, Panels, etc) in order to get what we need accomplised on the functionality side. When creating those Photoshop/Illustrator comps for the site, none of that is taken into account. There may be some styles for various layouts, various content types & pages, even for data tables provided by Views, and an array of additional use cases for that client.

Each of these different types of implied functiionality requires a very specific set of theming or CSS to accomplish something that may have been represented in a design, and THAT is where the major theme dilemma comes in.

I usually redesign and retheme my blog every 3-6 months at most, simply for growing tired of the theme, or eventually finding shortcomings that cause me to rather start from scratch and take my site a bit different direction both visually and on the functionality side as well. Yet each time I venture back into Photoshop to put together the most beautiful thing I've ever seen at the time, I think that on this iteration I will release the theme, and it will be perfect, and people will love it and use it on a ton of sites. But no matter what I do, after 40 hours or so of intense theming though I get to that point where my theme is now way to specific for my use case to ever be used easily out of the box on another site.

The only way a theme can EVER be a "great" theme is to take into account when creating .tpl.php files and CSS definitions the flexibility it will need. This is not as simple as throwing together a 6 hour wordpress theme, but requires thinking of commonly used modules and data that may be represented at some point and thinking ahead enough to theme that out well.

I've realized this more and more again after working on my Omega theme, which is ONLY a base theme for 960gs that takes in lots of great features from popular themes in the Drupal community. I've put in 100-200 hours already on it, and still have yet to commit a "stable" release as I'm at the point now where I'm attempting to use my base theme on multiple projects, testing the capabilities of the sub-theming system, and trying to ensure that it WILL work for everyone. I've spent truly a ton of time playing with it in sub-themes so that I can try to set up the base theme, and it's grid customization awesomeness so that it can truly apply to every use case, and be the ultimate starting point for theming, and be able to provide insanely rapid prototypes for a project.

Where to find the real solution

I think that we will absolutely not solve this problem until there is more documentation on theming from the experts on what 5, 10, or 20 pieces are involved in getting a theme "perfected" to work for many use cases, and be sutiable for mutliple sites, styles, etc.

I hope personally to be further down this road myself quite soon, as I've started learning how to theme out any and all views much quicker so that even if I haven't thought of every implementation, I've at least covered the basics so that any new views content will take on the appropriate look & feel out of the box. Yet no matter how much ANYONE plans for a theme to be "perfect" there will ALWAYS be some functionality, or some contributed module that provides markup we were not expecting, and need some customization to look proper in the site. This applies for new and experienced designer/themers alike.

References on the topic

• http://drupal.org/node/289117
• http://morten.dk/blog/cvs-haiku
• http://fourkitchens.com/blog/2009/09/30/why-drupalorg-lacks-good-themes
• http://himerus.com/node/152