Generic template layer for Drupal

Drupal's theme system, while incredibly customizable, is very
developer-oriented and being
acquainted with Drupal internals, is an implicit requirement. This creates very high barriers for
new non-technical users to take place in the project , but more
importantly .. it leads to a lot of cookie cutter sites, which in turn make
Drupal look like a less capable solution than it actually is. There is a need for a generic template layer,
that allows designers to make use of Drupal's excellent themeability , while not being subjected to the complexity of Drupal iteself.

I have written two articles about it for Drupal.org. The first article Open discussion on Drupal's themeing capabilities and templating engines. covered the problems with Drupal themes as they currently were. It's a justification piece for the next article, Technical discussion on Drupal themeing.. The second article is far more technical in nature, and discussed a high level architectural change for solving the problems encountered currently. This post contains an update on the progress towards this goal, aswell as a discussion of the nuts and bolts of the new system.

An issue has been created on the Drupal issue tracker, that contains the first patch against Drupal HEAD.

Overview of requirements.

Template layer :

Bring templates and themes down to the same conceptual level, where
the template contained in templates/myphptemplate is the same as
templates/chameleon. ie : get rid of xtemplate and phptemplate as
'themes' , and bring the 'engines' into Drupal core, while allowing
additional template engines such as smarty and PHPTal to be easily plugged in and used. This allows newbies to change what their site looks like, without needing to know how the new look is being accomplished. This also makes installation and copying of new templates a lot simpler.

Style layer :

Similiar to moveabletype's implementation of templates/styles , and
the capabilities of the chameleon theme in core. All templates should
allow configurable/ overrideable stylesheets. These should ideally be
editable from within the browser.

Centralized configuration :

Define, and maintain a base set of configurable options for all
templates that allows for enough flexibility as possible without
resorting to modifying files. Examples of this are a user's logo , and
toggleable settings such as site name/ site slogan. A great deal of
this is also helped by the template layer, whereby you only have one
setting to define what your site looks like.. not four seperate ones (as
is currently the case)

Copyability :

Allow templates (of any type) to be copied simply, and easily..
without requiring the user to modify any of the files in the template.

Extendability:

Allow templates to be used to extend the system, aswell as allowing
additional theme system logic to be be defined if needed.

Template and style layers

To make the template system work, I needed to create standard filenames for certain files, which in turn allow copying and extendability.

1. A template is defined as a template.php file, contained in a template directory. ie: templates/pushbutton/template.php
2. The template name is defined by the directory in which the template.php file was found. ie: templates/pushbutton/template.php is the pushbutton template
3. template.php initializes the template engine it requires to work. In the above example, the template.php file would only contain engine_init("xtemplate");
4. The first thing you notice when comparing phptemplate, and xtemplate (or whichever template based theme you care to inspect) , is that each template engine has two logical parts. Firstly, gathering all the information required to populate the template, and secondly .. pushing the information into the correct slots on the template, and then returning the output (if any.).. I have moved all the code that is shared between template engines into includes/template.inc
5. An engine is defined as a enginename.engine file, contained in it's own directory, usually under templates/engines. ie: templates/engines/xtemplate/xtemplate.engine contains all the xtemplate specific code needed to generate a page aswell as any additional libraries it needs to accomplish it's job. They are modular and can be dropped in to add extra engines.
6. Although it's not hardset, I have renamed xtemplate.xtmpl to page.xtmpl, and intend on keeping all other templates the same.. ie: page.tpl.php for phptemplate, and page.tal for phptal etc.
7. A style is defined as a style.css file in a subdirectory of a template. ie: templates/chameleon/marvin/style.css is the location of the style for marvin
8. Every template needs atleast one style, usually called default. This was done to simplify the selection process even more.

Centralized configuration

I actually need some more input on this category. The current patch only has the template selector because i wasn't sure which configuration settings to include in the default set. Defining the default configurable options is one part, which is followed by making all the templates respect the settings. A good indication of what needs to be configured is available on the feature matrix from my previous post. (although probably out of date)

1. A theme selection consists of a combination of a template, and a style. ie: chameleon/marvin and pushbutton/custom both are valid style selections.
2. A single theme selector was created that drops four of the current selectors into one single setting, that needs to be modified. It accomplishes this by doing a search for style.css files, which in turn allow you to select the template/style combination.
3. A default set of settings to be supported by all templates needs to be defined in modules/system.module.
4. These settings are defined on three levels, namely for the whole site, for the template and for each of the styles. Unless other settings have been defined, the system inherits from the level above it.
6. Additional settings for templates, can be defined in a file called settings.php contained in the template directory.

Copyability

Templates by their very nature are copyable, and the standardized naming convention greatly enhances that ability, however .. current Drupal themes are inherently uncopyable, and the greatest concessions were made to achieve this copyability.

For some background, to make a copy of chameleon at the moment, requires you to copy the directory .. and then go through the directory and rename the .theme, and the .css files to the new name, and then popping open the .theme file and doing a global search replace for chameleon with your new name. This is a bit much for newbies, and is just annoying for most users. You'll see why I decided on the following.

1. The file structure as defined in the 'Template and style layers' section remains consistent.
2. All additional theme_ functions are defined in the template.php file, so there is no need for a page.theme file, or similiar.
3. The first command in a theme() based template is to initialize the theme.engine, which acts as a compatibility layer. ie: engine_init("theme");
4. To stop the user from needing to change the contents of the copied template, the themename_hook functions were replaces with template_hook functions .. this however had some consequences.
   • The current theme selection screen includes all of the themes it can find, to get access to the hook_help of each of them. This would cause namespace clashes in the new configuration .. on top of which , xtemplates or phptemplates would also need to have a _help hook defined. I have decided to deprecate the help hook for themes, as it is just being used to display a single line of text on the selection screen, and is a source for a few different problems. I do not currently have a way to retrieve a description for the templates/styles .. but I feel that displaying a thumbnail is a friendlier solution
   • Currently, all enabled themes are loaded into memory , every page load, so as to build the menu from the themes that have a hook_settings implementation defined. The template system operates on the principal that only one template is loaded into memory at a time, especially with the template_ prefix for functions. So as mentioned above, an additional settings.php file, which implements a template_settings() function. This file will be loaded only when you are configuring that template. If it were defined in template.php, the template being configured could clash with the currently enabled template.

Extendibility

This is the area that requires the greatest work still, although the template engine has been designed with this in mind. What makes this an interesting section is because extendibility is different for different engines, although my refactoring of phptemplate will bring it more in line with xtemplate. I am not handling this as my primary deliverable right now, but the intent is to allow users to attach extra hooks to the templates of their choosing. Currently theme function can be used in the template.php file without any reprecussions .. but ideally there needs to be a way to only use templates.