Tags:

• Drupal

An ongoing discussion on drupal.org about theming problems brings up the question of a pluggable theming system.

This does however invoke the oft-stated problem of "Well as a contrib maintainer, does that mean I have to provide a theme implementation of all possible engines?" I understand the concern.

I think one solution to this is to have some sort of delegation layer as part of the rendering process:

• Core can ship with a default theming engine (PHPTemplate, likely).
• Module maintainers are already supporting PHPTemplate, so they can continue to do so.
• For a particular site, a themer can implement an alternative engine. If this is the case, a delegator can register alternative implementations of theme functions the themer wishes to supply.

Where it goes from here is less clear -- Ideally themers could contribute the templates back to the contrib module's codebase. Here's my pie-in-the-sky idealism: when downloading a contrib module, you'd get to specify theme options to ship with your download to limit the codebase size (or drush could detect automatically).

So, by default, you'd get this from d.o:

mymodule/
  mymodule.module
  mymodule.info
  mymodule.admin.inc
  theme/
    phptemplate/
      mymodule.theme.inc
      mymodule-template.tpl.php

If implementing Smarty, you would receive this assuming the maintainer has provided it:

mymodule/
  mymodule.module
  mymodule.info
  mymodule.admin.inc
  theme/
    smarty/
      mymodule.theme.inc
      mymodule-template.tpl

If not provided, you'd just get the default, but nothing is preventing you from adding the smarty dir and posting back a patch.

This would be similar to how the jQueryUI themes work -- you get a package customized to your visual preferences. Obviously, this is a task and question for d.o infrastructure, but something to consider.

Just an idea at this stage. But perhaps a way forward to give themers flexibility. ■