Print-friendly version
Send to friend
PDFGoing cold turkey on theme settings
Drupal has come a long way since Acquia Marina leapt onto the scene in 2008 with an unprecedented number of theme settings. Many themes followed suit, and we were thrilled at the extra power and flexibility that these theme settings gave to Drupal users. These theme settings had come out of lots of time spent in the forums and on IRC, finding out what site builders were constantly running up against and wished they had an easy way to change. We constantly got feedback about how great they were in the Acquia themes, and how much our customers enjoyed them in our premium Drupal themes.
So why the heck are we getting rid of them?
At the risk of sounding like your mother, it’s for your (and Drupal’s) own good. The theme settings often conflicted with modules that wanted to alter the same content – i18n, Advanced Forum, Submitted By, and more. We had ended up with a big list of modules we had to check for before tinkering with the code, and this was causing all themes to need to be repeatedly updated when another module was causing issues.
Dealing with module-like code in the theme was no fun to maintain and upgrade, which meant less time to focus on making beautiful themes. And modules were doing what our theme settings were doing – better! For example, the nice-but-limited SEO features like customizing page titles and meta tags are easily eclipsed by functionality in modules by the same names and with a much better UI. Duplication of effort is bad, mmkay?
And why lock down these settings in a theme, when modules can be used with any theme? As much as we love providing features that tempt a bazillion people into using our themes, using modules to accomplish the same tasks means that people have more choice about their theme, and more good themes means more people using Drupal!
But what about the convenience of getting it all in one package?
A couple of years ago, this was a stronger selling point. But with the introduction of packaged Drupal distribution profiles, it is now easy to bundle modules and themes together. Watch for a Fusion Distro coming soon!
In order to make the transition easier for those relying on the features of our theme settings, we’ve compiled a list of modules that enable the same functionality. The Theme Settings module could use the eyes of reviewers on the upgrade patch in the queue so an official Drupal 6 version can be released.
The breadcrumbs visibility setting is the only one we got multiple complaints about removing, so that went back into Fusion. We also kept the search results settings, because these don’t have a module alternative.
The future with Skinr
Fusion still has a lot of theme settings, but most of these are actually new settings for layout and typography. If you’ve checked out Skinr, you’ll know that it mainly focuses on exposing block styles. When we were first envisioning a module to handle styles, the idea was for it to also do page level styles. That dream is finally coming true with Skinr 2.x, which introduces page styles based on path.
This, combined with conditional loading of CSS/JS files, means that most of Fusion’s theme settings will be moving to Skinr styles. This won’t be happening overnight, as we’re currently focused on the Drupal 7 port of Fusion, and the 2.x branch of Skinr is still stabilizing.
Drupal themes have been through an interesting journey as the platform has matured. It has always involved striking a balance between “features now” and “making sense for the future of the Drupal community”, and I hope that we have done a good job of both pushing the envelope, and pulling back when it looked like we were on the edge of a cliff :)
This site runs on the Fusion theme for Drupal
Fusion is a powerful Drupal theme framework, with point-and-click layouts & built in styles for blocks, Views, and other modules. Download a Fusion theme for an instant, easy to configure design, or harness the power of Fusion in your own subtheme for a totally custom look.
And it’s free!
Comments (8)
Thought provoking.
Very thought provoking. I personally have been working towards ways to implement theme settings into my own work lately. But this has made me consider taking stuff a different direction. I think leaving most functionality up to modules, and the look up to themes is the way to go.
Keep up the good work Top Notch.
Nice writeup,
Nice writeup, thanks.
Question:
is there some "workaround" in order to avoid those possible conflicts (and keep using theme settings)?
string overrides
Would you say that its theme settings in general the cause problems, or just the string overrides you use in the theme settings?
Because string overrides are only a tiny part of what you can do with theme settings :)
Both, but...
Both, but good point... the string overrides are a big part of it :) But the rest of the points still hold true for others.
This is all good news
I always spent some time removing all theme settings from a theme that I planed to modify for our projects.
But now that you will settle for a more reasonable set of theme settings, like the breadcrumb symbol, all your themes will be easier to maintain and to modify.
I am looking forward to test and use Skinr.
Thanks Stephanie.
String overrides
Theme settings themselves are a great feature for Drupal themes (and they've gotten even easier to implement with Drupal 7), and we'll continue to use them to provide unique functionality to our users.
Part of the issue--at least in Drupal 6--is that once you get to the theme layer, a lot of the content has already been rendered and arrays have been flattened. So you're often left with just strings to deal with. The good news is that Drupal 7 gives theme builders a lot more power to alter output before it's rendered, so coding theme settings is much more graceful.
The core of the issue, however, is less about what technique you use to implement a theme setting and more about what functionality you're implementing.
If you add a theme setting that duplicates functionality found in a module (e.g., page titles), then sooner or later someone is going to use that other module with your theme, and you'll have to make sure that your theme setting handles that overlap correctly. Does the module take precedence? Does the theme setting? Do you merge the effects of both?
Essentially, when you implement module-like functionality in a theme, you're obligated for your users' sake to follow and accommodate the effects of any modules that implement the same features.
When the theme setting provides functionality that can't be found elsewhere, then it's a win for the user and a low risk for conflict with other modules.
But when there are popular, feature-rich, and well-supported modules that do the same thing (and usually much better), it doesn't make sense to replicate that functionality in the theme layer, and then spend effort dealing with conflicts rather than improving themes.
Because of the sheer number of users and themes we support, it's important that we balance the advanced functionality of our themes with their ability to work as smoothly as possible with the vast majority of Drupal modules.
Given that, carefully choosing which theme settings to add is just one of the many things we're doing to help ensure that our customers continue to have a great experience using our themes.
Fantastic
This is great. The first thing I do with an overly complicated theme is immediately drop out all theme settings (I'm talking to you too, Zen). While these options are nice for some users, your reasoning is sound and as a more experienced developer, the fewer places for conflicting settings the better.
Thanks, Nate!
That means a lot coming from you :)
Post new comment