I've spent a lot of time lately working with the Omega theme, and really trying to get features lined out that I've had planned for some time now. I spoke on many of those desired features during my presentation at DrupalCamp Montreal, and wanted to be able to really get some of those important features integrated prior to DrupalCampNYC coming up in December when I might have the chance to speak again on the Omega theme.

I recently had a quick blog entry on what those feature plans for Omega would be for my own purposes, and to document those features outside of my presentation. I created issues in the issue queue for Omega at Drupal.org, and then posted information on those here. The list of features that I had planned for the theme that relate to this post were:

• Custom Layout Configuration based on node->type (#614412)
• Custom Layout Configuration based  on path (#614416)
• Custom Layout Configuration based on Context (#614422)
• Priority levels for layout overrides (#614438)
• Saving "Grid Templates" (#614440)

After some serious contemplation, and some time spent in Photoshop wireframing the interface to manage these features, it became "clear" to me that what I was wanting to do would be essentially impossible on the theme layer, and would need to be moved out to a module in order to incorporate these features.

The main issue was being able to store & manipulate copies of the theme settings variables in a way that would allow for the most flexibility. As I already have a huge amount of nested fieldsets in the theme-settings.php file in the Omega theme, and still have a ton more to integrate to allow for "full" 960.gs grid management, I really saw no way to cleanly incorporate a ton of addtional code to compensate for node types, contexts & path groups that wouldn't blow up the current theme settings system, and bring Drupal to a grinding halt.

So I spent a day or two of contemplating how to appropriately integrate these features into my theme, a new module was born, called Delta. The Delta Theme Settings API (full name still in flux) is set to handle the things listed above that I want to incorporate to the theme level. The best part of spending some serious time thinking about a proper implementation was that I was able to line out some ideas that actually will make the Delta module valid and useful for ANY theme that uses theme-settings.php to add any functionality to the theme layer.

What is the Delta module?

Delta by definition: (Greek letters in mathmatics)

• a finite difference
• a difference operator
• a symmetric difference
• the difference or change in a given variable

Okay, that's all well and good, but what does some greek crap have to do with the module itself, and how it can help Drupal theming?

Essentially, the Delta module incorporates a few simple concepts regarding overriding the theme settings for a given theme, and provides an interface to manage those overrides. There are 3 main features to the module:

• Overrides
• Theme Settings "Templates"
• Preprocess work to use these overrides in Drupal when conditions are met.

Overrides

The concept of overrides is quite simple. An override is similar to how the context module handles things. An override is a set of conditions to query when loading a page in Drupal that will determine if there is a custom set of theme settings we want to use for that page rather than the default.

An override is essentially a named element with a weight which will allow for priority sorting, a theme, which will tell the system that the override applies to that theme, and then a theme settings template to apply to that override. The conditions that can be queried are the node type of the page, a context that is currently active, or a group of paths that will also trigger the override.

The override management page(s) will look like the following screenshot. Each actively enabled theme will have a page of overrides that apply to that theme. You may have themes enabled where the Delta module does NOT apply, and that will filter the sub-tabs to only present you with options for those themes you wish to manipulate.

This table of overrides is using the Drupal table drag JS to allow quickly reording the overrides. The order of these overrides as they appear on the page is the order in which they would be prioritized when overriding theme settings. If two overrides applied to the same node type, the one that is higher on the list would take priority.

The add override page currently looks like this, and integrates AHAH to provide a list of available templates after selecting the theme which an override applies to:

Theme Settings "Templates"

The theme settings "templates" are where the power of the overrides come in. Each "template" only applies to a single theme, as it needs to reference the currently available theme settings available for that theme. The theme settings template will be essentially a copy of the theme settings available for the theme which can be configured and saved separately. This would allow using different options based on where an override is found to be true and implemented.

The interface for this is still unset, and is on my plate for this week to finish up. The way this needed to be implemented, this module will require the Popups API in order to save/edit these templates in a modal window for usability and to avoid having to click around in many situations to get to a configuration page.

Preprocess integration

This is the final piece of the module which will be the last integration after all of the backend management of overrides and templates are situated.

Here, in preprocess functionality, the Delta module will determine when and where overrides are present, and essentially intercept the default theme settings in the system, and overwrite them with what is available from the Detla API. I have yet to investigate how this information is currently being stored, and/or if it's called on every page, or is cached in the system.

There are still lots of things to figure out on how to make this completely bulletproof, and useful to others besides myself, but I know this functionality has the possiblity to gain some momentum from hard core themers that would be able to leverage the power of this to its full potential.

Final Thoughts

I still have a lot to work out and integrate into the Delta module to make it as good as the concept seems right now. One thing that is important for this is the ability to have exportables of all the settings, and hooks to integreate those in similar ways that we export views, imagecache presets, etc.

Stay tuned for more information as I get more code written for the Delta module, and announce an alpha release soon! I'll be very interested in having some testers that are willing to bang the hell out of the module on some various themes to see how it works outside of my own testing ground.