[Editor's note: In the 8 years since this was written, all but a few of the links have rotted. To preserve the original sense of what is/isn't meant to be linked, these dead links have been changed to "example.com" rather than completely removed.]

I am in the process of designing a new approach to the themeing system currently employed by Drupal. But first I feel I might need to explain a bit about the approach I am leaning towards. If you are interested in Drupal themeing, I would greatly appreciate if you read the entire post, as I would like as much input about what I am planning, as to better try to help Drupal designers. This is a rather in depth post, but contains some insights into the new system I am currently developing.

I feel that most of what we consider a 'Drupal theme' at this stage, is too complex, and too rigid a framework for most web designers attempting to work with our platform. I propose we rethink the theme system as it currently stands to be a more generic templating system. Specifically , most of cruft in themes can be attributed to completely separate configuration settings and capabilities for each. This leaves us with a set of themes which are incompatible and different from each other, and if a designer wants a feature only another theme supports .. he is left with the choice of porting the feature to his current theme (not that easy for non programmers), or rebuilding his work on the new theme. The designer might even be faced with judgment calls regarding which set of features he would rather have.

I have been involved in Drupal themeing for quite some time, and one of my first in depth Drupal mini-projects was the phptal based theme chameleon (not to be mistaken for the new lightweight theme in Drupal core, Dries liked the name and used it for the new style based theme). As such , I have been thinking about the nature of Drupal themes for more than a year now. I have seen the system grow remarkably more robust in the lately, but there is still a lot of work that needs to be done to make it truly world class and very importantly .. designer friendly. Phptal was incredibly powerful, but had some performance issues (actually..because of it's architecture, it's likely to be a much better option come PHP5). Also.. due to the general nature of Drupal at the stage (it was printing , instead of returning, all theme() functions) it proved to be unpractical at the time.

The second part of the story takes place about *ponders* three months ago when I was contracted to do some modifications to marvin_2k (namely turning it into a hybrid layout. ie: tables for basic layout css for the rest). The theme was recently modified to use an incredibly simple pure php template library, which can be seen on cvs.drupal.org.

Also recently, the Drupal default theme xtemplate, had been given a secondary template, namely Pushbutton that could be used if desired(this template is great btw, kudos to megagrunt) , and the theme itself allows you to switch between templates. I personally feel that we are now more than one level too deep into the hierarchy .. in menu terms .. 'admin->configuration->themes->xtemplate'.

Nevertheless , my initial modification of marvin_2k led me to copy most of the template switching / setting code from xtemplate verbosely (This code is publicly available in the form of the PHPTemplate theme for Drupal 4.4.0) This made me uneasy about the fact that I was being forced to do this due to the structure of the code. In an attempt to try and minimize the duplication of effort, i spent an evening working on a new theme I called 'templates'.

The nature of my 'templates' work is as follows. A single theme, that is able to load any type of template, provided it has support for it. I accomplished this by separating all the cruft (ie: configuration screen, basic formatting of data (ie: the format of the date/username) and features like the avatar support new in 4.4.0) into the templates.theme , and then loading another 'glue library' for whichever template engine of my choosing. The extension of the template file you are attempting to load would act as the template engine glue library you would use. So, you would name your phptal template main.phptal , and that would force engines/phptal.inc to be loaded and used to process the actual displaying of the contents of the theme.

I actually progressed to the point of having xtemplate and the marvin_2k pure php templates natively supported, and a large amount of the work for smarty and phptal templates up and running before I realized the fundamental problem with the approach was that templates were still a few levels too deep, and the entire thing didnt make sense from a usability point of view. I then proceeded to make a pure PHPTemplate theme, (which is a branch of the original marvin_2k , but especially now is virtually indistinguishable apart from the mark up generated. The new version I will discuss in a moment will be out shortly, I am still implementing a lot of my intended functionality.). Since then I have been radically re-architecting the theme itself, to be as friendly to the user and designer as possible.

But once again, I ran into the familiar problem I had found before. Any templating system implemented in the form of a theme is just several layers too deep, and isn't allowed by the rigid nature of the theme api to fully shine through.
My proposition then is to build a generic template engine layer , and do most of the stuff that a .theme is currently handling, directly within the api. By creating a method for Drupal to generically load templates, we give access to a lot of designers who might only have experience with a certain api.

Personally I would like to target at least the following engines :

Pure phptemplates
Arguably the fastest and most robust method of doing templates. Sadly it is considered bad practice to force designers to use at least a little bit of php to accomplish their work, hence the abundance of template engines. This theme was created in the spirit of this discussion regarding the nature of templating engines. PHP also allows developers to use pull methodology.
PHPTal
Other than pure php, PHPTal is the only templating engine I would actively recommend to anyone. It is a php reimplementation of Zope Page Templates, and one of the distinguishing features of this engine, is that is uses the xml namespace mechanism to embed the template attributes directly into the static html document that the designer works on. I found an actual template I was using from during my chameleon development days. That is the actual template fed into the engine, however Drupal was not that theme friendly at the time. I have also converted already running websites to PHPTal+Drupal in about 20 minutes by simply taking the generated html and tagging it. The major drawback however is performance. If any template engine is ever to be called designer friendly however, PHPTal should actually be the only one on the list.(imnsho *g*)
XTemplate
The current Drupal template system of choice, and it should be supported for legacy reasons. An isotemplate (ie: single template file) API without conditional/recursive logic in the template.
Smarty
An incredibly popular and widely used templating engine, supporting it would be an incredible boon to the many users who prefer it above all others. There is a Smarty capable theme for the 4.2 era which could be used as a base for a glue library. It is an Isotemplate engine which has conditional logic and much more in the template language.

The back-end then would allow you to use all of these engines interchangeably. The idea would be that each of template engines would need to ship with at least one default template, that conforms to all of the features available in all templates. It might even be an idea to deliver exactly the same theme for all engines by default. Lowering the barrier of entry for designers wanting to work with what they feel comfortable with, and making it easy for new engines to be supported by developers.

Now, you may ask .. what about the current themes? Using the phptemplate system, it is easy to adapt any current (non template engine) themes to their own equivalent templates. A tricky part in all this is being able to override other functions (ie: theme("table") etc). There might need to be a supplemental php file within the template directory (completely optional for 99% of cases). We need to carefully consider what functionality we might be losing if we go this way. One benefit is that we have a single set up supported functions for all templates. All templates will be required to have both left and right columns , primary navigation customization, breadcrumbs and more. Luckily the nightmare of pre-4.4.0 themes not being able to switch to left, right or 3-column layouts without modification are behind us , but it still is nowhere near as centralized as it could be.

PHPTemplate

I am giving this a section of it's own , not because it is my baby, but because I am implementing a lot of the functionality now that I would like to be a central part of Drupal, available to all theme designers wherever. I am still not finished with the current development cycle, hence no release of the new theme. Several people have however made some nifty sites in just the last week or two using some demo code i have been selectively sharing for comments. (i have even gotten several patches back *g*)

Template selection

example screenshot

Template selection has been completely rewritten to allow contextual information for each of the templates. To make it as easy as possible to design new templates, instead of using the usual Drupal .template format, with _template hooks and the like. Information is configured via a simple text file. This allows users to copy the default template to a new directory , and make that template their own simply by changing the details in template.txt.

Each template can have a 'screenshot.png' and a 'screenshot_th.png' file which gives a small preview picture. This takes most of the guess work involved out of trying out a bunch of themes. Other Drupal core contributers might not agree with my belief that this is more user-friendly than simply displaying the name and description (as with theme selection).At the moment, one of the fields I have is 'Author', but objections have been raised regarding this. I am of the personal opinion (especially after some recent forum threads) that attributing layouts to designers will make more people eager to design templates for the contrib directory. Currently theme designers are practically invisible.

General template settings

example screenshot

When designing a new template or theme, there are certain things which will very likely be tweaked / modified by the site administrator. I have looked through other themes to see what configuration options they have, and put together a setting screen to avoid anyone having to modify a template unless it is specifically required. This would ideally be separated into a admin/templates/settings screen or the like, as these settings would form the master list of supported features a template would need to conform to.

An example of the configurability I am trying to reach would be the logo. If you do not specify an alternate logo, the theme/phptemplate/templatename/logo.png file is used. I further want to allow users to upload their logo via fileapi. Being able to display custom messages on the front page, and configurable navigation (currently only primary navigation, apart from drupal.org .. i do not know if there are many other practical implementations of it. at least I have always found it superfluous).

I will also try to see the practicality of one of the more often requested template hacks, namely selecting which node types to display the date/posted by information on. Designers should not have to modify the template to allow something as simple as this to happen

Approach to stylesheets

One of the interesting (and not widely known) parts of the Marvin_2k theme, was it's practice of using a 'custom.css' file , if such a file existed. The idea behind this was people should be allowed to create their own overriding css rules, without needing to modify the theme itself, thus making future upgrades a nightmare.

I am building functionality into the templates settings to modify the contents of custom.css if it is writable. This will hopefully allow wholesale customization for anyone who has a Drupal site. If your logo is higher than the space attributed for the header, you can add additional positional css to make it fit, once again .. without modifying the original template, or having to mess with the files in the directory.

The new default template for the theme is designed to be a 'clean slate' for css designers to work on. Even though marvin_2k has some of the best markup generated by any Drupal theme, most of the time spent customizing it is disabling the look and feel of the default theme. This attempts to cut that time down to a minimum, and allows us to document the classes/id's and the like of the default template for template designers.

I hope to approach the stylesheet problem in such a manner as to make stylesheets the most practical solution to almost all of the customization that needs to be done , and ONLY if a change to html generated is absolutely required would they need to make their own template. What , prey tell , is the practicality in this you may ask? Well .. it's simple. Default will be maintained directly with the template engine, and as such will almost never lag behind with any improvements. Creating your own template when it is not completely necessary complicates the upgrade path and makes maintaining the site more work than it could be.

I have actually got a more extensive approach to handling stylesheets in mind for the future, but I do not want this discussion to revolve around that, but I am adamant that one of the basic requirements for a contributed template would be supporting custom styles.

Some people might feel that CSS only design is not the right tool for this job, but the system allows them to create their own templates. In any case CSSZenGarden is a shining example of the power of CSS.

Push/Pull Hybrid

Drupal uses a 'push method' of populating the template. Basically, Drupal (the engine) decides what the theme/template needs to display and the template generally does as expected. Many people have noted that MoveableType uses Pull methodology, where the template contains certain tags that 'pull' the data required from the engine. Because you are using pure php to write your templates, and are not limited to the basic {values} of , for example Xtemplate, you have a lot more freedom as a site designer.

The simplest example would wanting to add a random quote (as generated by the quotes module to the footer of your site. To accomplish this in xtemplate you would need to modify the template by adding a quote block, and {quote} variable. You would then need to modify the xtemplate.theme file to 'push' the quote into the template. The resulting change might leave your xtemplate theme incompatible with other xtemplates (because they lack the quote block)

To accomplish this in PHPTemplate you would simply need to add

<?php
print quotes_get_quote(); ?>
to the required place in your template.

This feature is used in the mobile template for PHPTemplate

Examples

Regrettably I don't feel very comfortable releasing the theme to the public at large yet, but there have been several sites launched on the beta code of the new version

Oasis Magazine
The reason I started using Drupal. I finally am able to run the site I want to be running thanks to the new theme. Apart from a modification to the node template (adding the cactus image), it is completely done with modifications to the css of the original marvin_2k. It still has some semblance (the main nav css rollover for instance) , but I feel it has been customized successfully.
Oasis Magazine - Mobile Edition
The most pertinent example to why being able to 'Pull' is useful. Mobile is a much simplified template I wrote that cuts down as much unnecessary content as possible, to allow mobile devices to read the content, without having to try to keep up with the real site. The mobile version of Oasis is accomplished by a few lines of code in the oasismag.com.php configuration file. These lines set the template to mobile, and the base_url to mobile.oasismag.com, should the request come from mobile.oasismag.com. Furthermore, I have purposefully not printed the blocks found on the normal Oasis (they are passed to the template, but completely ignored) , and use pull methodology to print only the user login / navigation screens , depending on the user's logged in status. This is a very simple modification to a template that has a very real benefit. I plan to ship mobile by default with PHPTemplate, so more Drupal sites will hopefully be made more accessible for mobile devices.
Daemon.co.za
My personal home page, and one of the first sites to use PHPTemplate. Originally based on Xtemplate Tableless circa Drupal 4.2, I decided to port the stylesheets to the default template, and as such exists almost completely in a few css files and a new logo.png. Currently it is a separate template because the default template was in flux when I was doing this.
Partyfashion.net
The first public phptemplate site I am aware of. It was created by Ber Kessels a few days ago. It features a unique method of 3 column display, I am unsure however whether it is done using css or actual html modification was involved. Best you ask him
Chiquechick.com
A site based mostly on 'default' , that was customized in a few minutes (according to Ber, about 20 or so) to use a custom logo image, and adjusting the stylesheet to take that into account. This is an example of the site that could be configured without leaving your web browser, directly from the template configuration screen's ability to modify custom.css.
Default template- screenshot
A small screenshot of the default look and feel. It isn't finished yet (almost though) , but I hope that it will be used as the basis for many sites. Like I said , it's as clean as It is , to make it a canvas for the designer.
Bluemarine and Pushbuton template screenshots
In order to benchmark/compare xtemplate to phptemplate, I took 30 or so minutes to convert the default templates to the new theme. This should give us a better idea of the actual performance of the theme, plus .. it might allow people who have developed XTemplate based themes to switch if they so desire

Believe it or not, the examples are simply the first results of using php as a templating engine, One of the major problems at the moment is that phptemplate doesn't do isotemplates, and there are a few file_exists() checks and other things that need to be optimized a way

There are several actions I am expecting from this post (if it doesn't get completely ignored that is), firstly.. Dries or Unconed are going to complain about some inane spelling or grammatical error .. or even better .. Drupal not being Capitalized... somewhere. I've learned to live with that.

Secondly, I expect quite a few people to have the reaction of 'i can make themes fine'. I can understand the view of those people, since I have gotten the hang of Drupal themeing over the last 18 months myself. I am however not your typical designer who wants to use Drupal but lacks the knowledge to make it work. What I want to do is lower the bar , to allow designers to come to grips with the capabilities of Drupal easier. The Install system is only one part of this, but it's an important start.

Lastly , I expect that people who would benefit from such a system would welcome, and have meaningful input into what I am proposing here. If you have an opinion, or there is something you feel would add to this proposal, please reply. Everyone's voice will be heard at the very least.

The implementation details at this point aren't the most important, I am however confident I could get it all up and running .. but a change this vast is going to need more than just my spare cycles and eyeballs. Especially considering the amount of time I will be spending on finishing the install system in the next few weeks. I can already understand however that the configuration and and actual running of the template system will need to be separated, and the configuration only be loaded when strictly required. It should be possible to improve memory usage and execution speed doing this. Also, Dries doesn't want to make things too complex, which is exactly right. Anything that gets proposed needs to be discussed and designed in such a way as to allow for the system to be as simple as possible, but no simpler. It is a design concern, I do assure you.

Sincere apologies for the severe length of this manifesto. There simply wasn't much I could leave out while still painting the whole picture, and the phptemplate section (as i said) is to demonstrate some of the concepts I would like integrated. Even if no one ever uses it, and it gets locked out of core. I fully intend PHPTemplate to be the last theme I ever need, but I really hope it will be useful for others.

Comments

I do not think I would call Drupal's theme system "rigid." It seems to be one of the most flexible systems I have used in a CMS yet.

Even after your long post I am not quite sure what you are proposing. Do you want to replace the entire theme system with something else? Or write a new template system which sits on top of the current theme system?

After having this dicussion on the mailing list for 4.4 development, I know that most of the community is not fond of the idea of having a standard template syntax. We talked about this quite a lot.

Anyway, I will need more details about what you actually want to do before I could comment on it.

I don't want to endorse a standard template syntax (wether it be php , phptal or any of the other options). I want to allow drupal to easily use template engines in general. I want to attempt to simplify the theme interface by centralizing as many of the configuration settings as possible.

I want us to bring templates up in the heirarchy to be on the same level as themes. I want Drupal users to be able to design new sites quickly and effectively , without having to worry about what different themes capabilities are, but being assured of a minimum amount of configurability across the board.

The theme system has a great amount of power that still needs to be available to advanced users, but should not be forced upon newbies. I do however see a conflict with 'themes' as they stand now. Would they conform to the guidelines? How would we manage them?

I want us to put together a system that has the same power as we have now, but which simplifies the process for the average user. If at all possible I want to enable almost anyone to have their own personal site without requiring them to spend a week learning about drupal hooks, and theme() functions. That functionality is very important, but the most commonly themed functions (block, blocks, page, node , comment .. i don't think i am missing any.). Would be more adequately handled by a templating engine. And in this case, not a specific engine , just a layer with which the user can choose which engine he prefers to use.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

Ah ok.

So basically you want to re-work the default theme functions so that they call a new Template API?

This Template API would provide a layer of abstraction from the actual template engine used, and allow developers to implement the template engine in different ways.

Also if you leave the theme functions inplace, then developers will also be able to ignore the Template API completly if they want, and simply override the default functions as we do now. This way you can maintain compatibility with regular 4.4 themes.

If that is your idea then it is pretty good.

But you will have to endorse a template syntax if you do this. Because the if the Template API is intergrated into the theme system, it will require a default template engine to work. Much like the current theme system needs default theme functions to work.

Although I am all for keeping the more specialized theme_ functions php only, the ideal situation would be to somehow allow overriding templates to be defined for theme_ functions.

I mentioned possibly still needing an extra (and optional) php file within the template directory , if neccesary

so if there is any 'default' engine in my opinion, it's php.

Also, I am loath to maintain compatibility with 4.4 themes, because it will lead to immense user confusion aswell as all kind of possible catastrophies. My approach will hopefully make templates the only top level themeing system, with styles being the customization layer on top of templates. I still need to ponder what would be the best way to maintain the extra functionality via extra hooks that themes in their current state offer.

any ideas / thoughts will be welcome

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

Can't you just modify current theme functions so that they call your Template API, and use your centrialized settings?

If you do this it will cause little disruption to the current system and maintain compatability with 4.4 themes (by not changeing the basic structure of the theme system).

You can support template developers with your system without sarcificing the current theme system. Then people, like myself, who want to make a theme that has maximum control can do so. Template developers can use your system.

Basically your template API could be the default system, but it could still be overridden by custom themes.

Themes themselves need to be rethought. What if you run your site on a smarty based template, and then you find yourself wanting to.. override .. i dunno theme_user_list.

What will you do then? Reimplement the entire template in PHP? The way I currently see it, (unless I figure out a generic way to this across template engines) , is that you can have supplementary theme logic, in the same way you can have custom css. This would be a .php or a .inc file inside the inside the template directory.

Thus you should be able to build theme_ functions in addition to your template.

I have pondered perhaps enabling the template engine to load themehook.templatetype. So you would create a user_list.phptal or user_list.tpl.php in your template directory. And then tell the template engine about it (instead of using file_exists , which would slow things down drastically).

This is almost a realistic Idea ,were it not for the fact that xtemplate has no flow controlling logic, so you can't just dump the variables into the template and make it look after itself, you will need to build the glue library to be smart enough to look for blocks , and fill them . parse them / the whole regmarole.

What functionality does a theme offer you right now that a template based layout (for argument's, sake.. it's a php template where you have complete freedom) , with overriding theme logic wouldn't be able to? I am afraid of maintaining compatibility with drupal 4.4 themes because it would mean there are 2 different, and possibly incompatible methods of doing things. It's like saying modules can be drupal like module_function style, or be objects.

Once you have settings centralized out of themes, most non-template based themes are just a hollow shell of html. Template based themes are actually the basis of the glue libraries.

Please, inform me about what your requirements would be for the template / theme system to be a practical 'replacement' to the current system.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

As a non--programmer, I definitely support the idea of making the templates more designer friendly as possible and less php intensive as possible.
I beleive this is the idea behind the templates. Seperating the design from code, right?

I love Drupal by the way. It is so powerful and so flexible. Making the template stuff easier for designers so that everyone running Drupal does not have to stick with the default themes would be a great enhancement.

Thanks guys for all the great work.
KC

KC

My Sites:
phoenixnewhomes.net
thelittlebig.com

But on the other hand, I also want to make the default themes configurable enough that even novice users can customize their sites without too much difficulty.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

that sounds great. :) one of the common contents i've seen is that newbies that don't have much design skills have trouble making changes to their themes. usually these comments are made in comparison to MT or Blogger.

Every time I install a new Drupal site I:
- make a copy of either chameleon or xtemplate (mainly chameleon these days)
- hack the template file to add in support for avatars, menus (navigation.module)
- various other PHP-level template changes
- hack CSS to achieve look and feel

From adrian's write up, it seems that I could accomplish most things through configuration options *while still having the full power of PHP if needed*. I think this is the key point: flexible enough for developer-designers, easy enough for "pure" designers.

Acknowledgment of theme designers: absolutely. I hope that Drupal can eventually do its own "CSSZenGarden", with full credit to the designers.

One of the things that concerns me is that some contrib modules require modifications to the theme at the moment. I certainly don't want to support all the possible little niggles in the default template. Also , xtemplate is not as freely modifiable as phptemplate ( or even phptal ) , since even the slightest difference in the data might require a .theme hack.

I don't know about the exact php-level template changes and the specifics of navigation.module (which is a great candidate for integration though), but just about everything including the css hacks could possibly achieved directly from the browser.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

Adrian, good job getting this discussion going. Many good points and issues raised.

Two main objectives of this discussion should be:

More themes/templates available for Drupal.

Easier for administrators to use themes/templates.

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

I agree with both of your main objectives. However, it seems to me at least that neither of these has been served by the changes in the theme system from 4.3 to 4.4.

It seems that power, flexibility, and php purity have all been served at the expense of ease of use. In 4.3 and prior, themes were basically HTML files divided into functions by PHP tags and with PHP calls that retrieved dynamic content. Themes are now basically mini modules that build content by adding HTML tags to content.

Basically it seems as if the PHP code in Drupal has expanded and engulfed the HTML markup used to generate pages, while what should be going on is the reverse-- removing as much HTML markup as possible from what Drupal's PHP code generates and centralizing it in a file or files easily accessible to a non-programmer.

Perhaps to clarify the first goal-- if the object is to create a situation where a drupal site isn't instantly recognizable as Drupal because it uses a standard template-- then themes need to be less powerful, less flexible, and easier to create, modify and maintain by non programmers, so that more themes will be available and up to date. It seems that with each of the last three major revisions of Drupal, a large number of themes have been left abandoned, and the only ones that have been consistently kept up to date are not the simply, easily understandable by non-programmers ones.

I know this sounds awfully negative; don't get me wrong, I love Drupal. But the more I look at themes in 4.4 the more I think I'll be sticking with 4.3 for the foreseeable future.

This is about getting rid of everything that isn't needed to display the basic site, but still allow theme_ override functions should they be needed. The theme system is incredibly robust, but not nearly designer friendly enough.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

The theme changes have not "engulfed" anything. All that changed was the removal of the theme class, the addition of many more theme functions, and addition of documentation.

Those were the changes made to the theme system. Maybe the new themes which were developed do not seperate PHP and HTML well enough, but that is a seperate issue.

For example, I do not think that XTemplate templates are effected at all by the new system?

The PHP code has literally "engulfed" the HTML within the theme by requiring that themes return output, whereas before it was possible merely to escape out of php using ?> tags and use HTML in the theme, meaning the only PHP the theme designer had to know were the hooks needed to divide the theme into parts (header, node, comment, footer) and the hooks to pull content from the database, which were clearly visible in the themes provided with Drupal.

Now it's not nearly that simple. Most editors I use for HTML and PHP syntax coloring don't help for editing themes because the entire theme is PHP code, with each line prefixed by "$output .= " and all the HTML enclosed in long unbroken lines of HTML.

Forgetting just about the difference between a theme file that is PHP-based and builds $output from HTML and content for return, which is clearly more programmer-friendly than designer-friendly, just the basic issue of having to escape all quotes within HTML tags makes theme development more of a chore than a pleasure.

XTemplate, and PHPTemplate were both made for people who are not confortable using PHP.

Designers are not meant to go into the theme system, they are meant to use one of the template themes in development. The theme API is meant as a base for php developers to make new themes.

That is why it is a good idea to add better support for templating into the theme system. So designers do not get bogged down in php. But your argument that the current theme system is a step backward is a little short sighted.

You really need to take a look at the the version of phptemplate in contrib cvs - it may already be outdated, but you'll find the *.tpl files are pretty much XHTML escaping to php where required.

There's nothing about the changes to the theme system that alter that, it's all down to how a specific theme is built.

adrinux
adrinux@ntlworld.com

Adrian Simmons
adrinux@anaath.at

Or rather, ehrr, one GUI to administrate them all.

The current theme/template administration system is ineffective because it is designed from the point of view of designers/programmers rather than users. The average user cares about whether a theme/template is based on Chameleon or Xtemplate about as much as they care what brand of caffein was being drunk when designing it.

What the user wants (IMO):

All themes/templates presented as one list. No need to present info on theme systems. Drupal auto refreshes list every time theme admin page loads. Drupal automatically loads and unloads theme code based on which template is selected.

To see a preview of each theme - a nice thumbnail of the theme/template. At the moment, with so few themes this is not so important, but when there are hundreds (!?) of themes/templates it will be essential to be able to visually identify them.

Brief description of template. Fixed width or liquid, XHTML 1.0 or XHTML 1.1, accessibility compliance, does it use tables or is it CSS pure....

Version number of template - which version of the template it is

Drupal version compatible - which version of Drupal the theme/template is for. With auto warning.

What else?

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

I have already prepped the install api i am working on for this purpose. =).

And as far as hundreds of themes/templates goes.. yes. this is why i believe we need to rework the theming system.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I really like the idea of info for available templates being syndicated from drupal.org to the template administration page of Drupal installations.

When an administrator sets their site to an available template, it gets automatically downloaded and installed.

Would this be too much of a resource hog?

Are you doing something similar with modules?

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

Although practically we are atleast several months away from the infrastructure for something like this

One of my plans is already that there will be an xml stream from drupal.org with all the latest versions of the modules (for your release)

This is just going to be simple at first, for instance notifying the admin of an important security update on one of the modules he has installed, and the like

There are too many scary things that can happen when automatically downloading any code from the internet. So the security issues of actually installing off the net will need to be completely sorted out before this will ever ship enabled in a drupal core install.. but that doesnt mean it can't be seperated into a contrib module, or something.

WHat's a resource hog about it? you speaking of bandwidth , or memory / processing power? Ofcourse I havent coded all of it yet, but updating an rss feed once a week, and keeping it in the versions table internally , that doesnt exactly take a lot of juice

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

It seems that power, flexibility, and php purity have all been served at the expense of ease of use. In 4.3 and prior, themes were basically HTML files divided into functions by PHP tags and with PHP calls that retrieved dynamic content. Themes are now basically mini modules that build content by adding HTML tags to content.

Basically it seems as if the PHP code in Drupal has expanded and engulfed the HTML markup used to generate pages, while what should be going on is the reverse-- removing as much HTML markup as possible from what Drupal's PHP code generates and centralizing it in a file or files easily accessible to a non-programmer

battery relays manufacturer hair brush

This is an old conversation

phpTemplate adds complexity.
xTemplate still exists and is HTML mark up with some tag for php.

Currently, Drupal offers you a choice. You even have some other engines as well

-sp

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

No that it seems a central template system is landing I think some terminology could be defined.

I would like to call the engine (in this case phptemplate, but might be xtemplate) "theme"
And the design a "template".

This difference was already introduced in Xtemplate on 4.4 and chameleon on 4.4. Basically I see a theme (the engine) defining most of the "feel" and the template defining the "look".

Ber
Mediarevolution.org :: het platform voor online muziek

spam related: bots may mail me here

Themes being made obsolete in a way , and templates becoming what defines the feel , and styles defining the look.

The idea is to seperate out the core functionality all themes should have, and then replace what we consider to be themes with templates.

At the most basic level , phptemplates are pretty much an exact replica of the php onlythemes without the configuration settings.

I'm not really sure I see the 'themes' as they currently stand, but templates would take their place.

And templates would essentially be template engine agnostic. You needn't even know a template is written using smarty until you decide to modify it.

The extra functionality that can not be defined in a normal template file could be defined in an optional .inc in the template directory.

Why not keep on naming templates themes? .. welll.. because it's a template.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I sort of think of a template as a 'skeleton', and the stylesheets as a 'skin'. I quite like the 'skin' terminology because it's something most people are used to with applications. But it certainly is getting complicated. A theme can have several templates and a template can have several different styles...

adrinux
adrinux@ntlworld.com

Adrian Simmons
adrinux@anaath.at

skeleton == markup
skin == presentation

I am busy writing a complete document with solid examples and comparisons regarding my proposal. It's starting to become quite complete actually

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

This makes very much sense. So, designers (as opposed to developers) would mainly be "skinning" skeletons.

And developers would mainly be tinkering with the skeleton.

And it's nice because it's a clear distinction away from the current theme/template terminology. So, pre-4.5, we say themes/templates, and 4.5+ we say skeletons and skins.

The idea of a skeleton and skin already has a name in the publishing world:

The skeleton is called the "dummy" layout. It's called a "dummy" because it serves as a layout guide for laying out the elements that are put on the page.

Then the actual skin (fonts, colours, etc.) is called the Style/Stylebook.

In any case, it looks like an agreement on approach is developing:
Abstracting the layout (template) and the style of the content as two separate entities allows for the most flexibility in design and configuration. Both could abstract layers (layout and style) can use CSS tags, but only the layout layer would use the template engine. Make sense?

My $0.02.

Cheers,

Devin.

i think adrian is proposing to move some config settings out of theme files and into a core theem API. that way, it will be easier for an admin to change themes while not touching settings. sounds good to me.

My initial post dwells on my motivation more than on the actual proposal. I suppose I wanted to get input from the community before i set on a course

I need to emphasize that these proposed changes do not affect the theme() function, and any of the contributed modules in any way. This proposal aims to modify the basic themeing functionality of Drupal in such a way, as that it can be to the maximum benefit of the users.

The outline :

  1. I resurrect my templates theme, and get the proposed template system working properly.
  2. Convert as many of the current themes as is practical into their own templatized version.
  3. Create 2 new files for the drupal core. Firstly, templates.inc. Which contains all the code nessecary to display a page using a specified template file. Secondly, seperate all the configuration/administration functionality into a template.module.
  4. At this point we need to do proper research as to what functionality we are missing in the new system. And we might at this point extend the template system towards some usefull general purpose functionality.
  5. Define explicitly the minimum requirements for contributed templates. Users can and probably will modify their own templates to be incompatible with the written spec, but we should not accept a template into contrib that doesn't have all the functionality .. and we should probably consider requiring validation. This hopefully will give us some consistency.
  6. Hold the proposed theme design contest on the new developer friendly platform , getting loads of valuable feedback
  7. Ship the top four or five templates with Drupal 4.5.0
  8. ???
  9. profit!!

I have to stress however, this is not on my immediate to do list. I am currently doing extensive work on the install api, attempting to get it ready as soon as possible. But after the install api I will be tackling this

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I realized that we could integrate current themes into the new system by providing a dummy layer. Ie: the same way we have a phptal.template glue library for PHPTal support, we could have a theme.template glue library aswell. The glue library would simply consist of a template init hook, where it simply includes the theme. Since the theme() functionality hasn't been modified greatly, it will function as normal without requiring a template.

This does not however solve the problem of enabling template designers to create their own html for other theme_ hooks. Also, legacy drupal themes should try to support atleast some of the minimum specification, by at very least getting rid of the _settings hook.

This method would alleviate some of my concerns with maintaining the current themes, and templates as seperate entities. I do really think that most themes currently available would be much better off as templates though.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I still do not see why you want old themes to meed a "minimum specification." It is a good idea to provide a central settings page, and it is also a good idea to set a standard on how new templates are made with your new system. But there is no reason to force developers to update their old themes.

When I am working on my own site I really like the current set-up. It allows me not only to theme the site, but also write new functionality right into the theme functions, so that I can keep my changes out of the core.

What I would like to see your template system do, is sit on top of the current theme system. You can reorganize the theme admin section to make everything more centralized, and add your template setting there.

It just seems like you can do everything you are proposing with out modifying the current system to much.

I side with CMX on this. Preferably, the PHP-template system should co-exist with existing themes and theme systems. I'd rather not depricate the Xtemplate system until the PHP-template system has been adopted for a while and has proven to be the system of choice. Similarly, the Chameleon theme has unique properties too; for one, it is extremely light-weight/fast.

Reworking the theme settings page(s) is a good thing, but from what I can tell, it has nothing to do with the PHP-template system itself.

As a Designer/Developer just about to deploy a 4.4 theme I have to say that some sort of 4.4 layer or other legacy support surely has to be provided, at least for long enough to update existing set-ups.

My theme for an extranet (no open access just yet) is built against 4.4 and does a "template" style access to multiple child styles so I agree 100% this is a good conceptual direction for drupal to support - closer and more neatly tied to the core - at the moment I have the configurable parts hardcoded or locally included in the theme php...

The point is that I'm sure I'm not the only one that has thought drupal good enough to be worth the time to hack a few workarounds here and there ...
But it would be a shame/showstopper to see that wasted .. overnight at least. Drupal has changed alot, and no doubt needs to keep changing as it gets better, but while allowing sites to keep close to the improvements, without losing custom functionlality already built against the current 4.4 API.

just my 2 cents, HTH

jon :)

[JT]

I agree with many of the other comments that completely dropping support for (at least) 4.4-era themes will piss a lot of people off.

Right now, I can't launch any new site without having to go directly down into the PHP level to edit code (e.g. add a horizontal nav bar that uses navigation module). So, this and the fact that there aren't hundreds of designers using Drupal lead me to believe that the current system is not workable for design-only scenarios.

Adrian has shown that he can pull off some amazing stuff. I think as a community we need to clearly articulate what the goals would be for a 4.5 template/theme system. It sounds like a certain level of backwards compatibility is necessity, but changes need to happen to move past the current "developer only" stage of theme design.

My suggestion would be to have the new system be a module if possible (potentially patching core to install, like groups). It can then "prove itself" for 4.5, with potential integration into core for 4.6.

PHPTAL should not be slow by definition... I am also impressed by PHPTAL, but last time I have checked it, my main consern was that all the templates needed to be wellformed XML (otherwise they won't be parsed). I am not sure, that a usual designer would like to try and find wellformdness errors in the templates.

If PHPTAL would complie the TAL templates to PHP (which is always an option for all template engines), then it could be as fast as Smarty or any other choice. And since it is much more designer friendly, it would be an ideal choice to present some example templates. Then it is up to some designers to get to know it, and get to like it.

Nothing in the PHPTAL (or TAL) concept makes it inherently slow. PHPTAL has some architectural refinements to improve OOP in php4. But these won't be needed in php5---and can optionally be eliminated now in favor of speed optimization. Just checking the code for conditional includes, and placing the cache check early will speed typical pages served by 1 or 2 orders of magnitude. Let's not forget that a feature (and purpose) of templating is to manage full and partial page caching. PHPTAL wins hands down from a designer and programmer standpoint, in my opinion. If speed issues are the only "perceived" concern in using PHPTAL, then we need to study PHPTAL in a little more detail. Plus, PHPTAL rhymes with Drupal! ;-)

I feel phptal is the best template engine out there, and if designer friendliness is the goal , i can't even ponder not including support for it. It also allows php calls from within the template file, and can thus accomplish push/pull hybrid templating. Smarty and pure phptemplates should also be able to accomplish this quite easily. Xtemplate however will always require additional logic written in php for anything you attempt to do (hence why i don't know just how designer friendly it actually is)

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I've only use Smarty out of all those template engines out there, and I like it a lot. It's very powerful and very flexible. I'm not saying that Smarty is the right choice, but I wouldn't mind something with that degree of flexibility.

The trouble with Drupal as it stands is that it displays stuff in what I call a "pushing" manner. You go to a certain module and it pushes the data out in a fairly rigid way. If it has data to display it will go ahead and display it, using the theme to describe how the nodes are laid out. Drupal says "I'm going to display ten nodes now" and so it calls on the "display node" function ten times.

The alternative is a "pulling" system, which is, IMO, a more powerful option, and would work best with templates. In this system, the information to display is made available to the theme, but not displayed unless the theme expressly wants it. The theme is parsed, then it comes to a bit where it says "I want to display ten nodes now", whereapon it calls on Drupal ten times for the data to display (and given a decent templating system, this repetition can be done automatically).

The former method is far less flexible.

Anyway the current system isn't too bad, as far as it goes. If there was only one thing I could do to improve it would be to add support for different themes for different types of pages. I don't want the pages generated by all the modules to look the same. Sometimes I don't want a rightbar, for example.

Anyway, that's all I have right now :)

[teamonkey]

[teamonkey]

So instead of having modules call theme functions you would have theme functions calling module functions. That is another approach, but with Drupals extreamly flexable internals it might be more difficult to implement than on other systems. For example, using the pull methodology would require nearly the whole system to be driven by the theme. For this system this does not seem desireable.

Also, the current theme system has pretty much the same level of control, you just achive results in a different manner. For example, if you can control which pages display a sidebar inside the theme quite easily with a if statement. You would just have to check which page you are currently on.

Probably the biggest thing is that the current module driven system is more developer centric than designer centric. That is why you are seeing many more complex and powerful modules than you see for other systems, and fewer themes. We just need to add more designer stuff to Drupal, then we will have it all. :)

Any templating engine that can call php functions from within the template, could be able to accomplish hybrid templating (which i basically see as .. everything gets pushed, but you can ask for whatever you want optionally

Also, I intend to allow users to have seperate templates / styles for seperate sections if they want, to afford greater customizability.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

push or pull... a lot of that becomes a non-issue when the caching system becomes more mature.

Right?

Devin.

Caching and push vs pull are completely unrelated ideas. Caching only pertains to storing HTML pages that have been generated.

Push is a name given to templating systems where the code packs a list of variables and exposes them to the template. The code has to know in advance what the template needs, and a template designer/user cannot decide later that they need something else. In other words, they cannot decide, in the template, to call a core function or do a SQL query. Any new variable has to be pushed to them from the code. An example of this would be

<?php
echo $streets
?>
This would only generate output if the variable $streets had been packed and pushed to the template in advance.

Pull on the other hand, says that you decide in the template what content you want to display. Or rather, ALL the content is available and you write queries in the template to get and process it. For example, I worked on a system where we would write things similar to this in the template:
[User{ name = "John" || name = "Bob" }/Address/Street]
This query would "pull" list of users from the database with name either John or Bob, get their address and output the street part of it.

- Robert Douglass

-----
visit me at www.robshouse.net

my Drupal book | Twitter | Director, Product Operations Commerce Guys

Robert,
Thanks for explaining the differences between the push and pull paradigms. I think I favour a bit of a hybrid view. My perspective comes from the fact that content generally can be classified as static, periodic and live. Each classification of data calls for the appropriate technique.

My guess would be that static data naturally fits in the push based technique. Periodic data could be used in a puch based system; however, because periodic content is subject to revisions and updates there could be an arguement for a pull based system.

I wouldn't think that Live data, by its very nature, would work on a push-based system.

When I refered to a caching system, I was thinking that only static and periodic data would be cached. They could be pulled or pushed.

In a pulled system, the CMS would look for the content in a flat file instead of hitting on the database. If the flat file doesn't exist or has expired, then the CMS pulls a fresh view of the content from CMS and stores it in the cache in addition to publishing the content to the client.

In a pushed system, a natural cache exists, content pages are generated into the cache as they are release for public consumption. If they expire a cron job would have to clean up the content. If new content updates arrive, the content pages in the cache are re-generated by the CMS.

I've seen both of these system in action though, obviously, I didn't have the vocabulary to describe them.

The pushed system tends to lighter in terms of resources. Also, I can push to multiple caching servers for load balancing. Vignette worked this way.

Thanks for putting some descriptors around my body of knowledge! Now... time to get back to work. :-)

Devin.

I've now written a couple of themes using Xtemplate 4.4 and have some comments in case they're useful to this discussion.

My only previous CMS theme development experience was with Xaraya, which I found dauntingly complex. Template information could be in any of many different files in different locations, and rather than HTML the temlates were written in an XML encoding that was practically like learning another scripting language. While no doubt powerful, the complexity was too much for me. One of the primary features that attracted me to Drupal was its simple but powerful xtemplate system.

In general, I found Xtemplate to be very easy to use. Because all (or nearly all) HTML is there in the .xtmpl file and all styling in the .css file, very different looks can be achieved easily. As an example, I took an existing HTML site and in under an hour was able to make a basic conversion to xtemplate.

But there were two main issues:

  • I couldn't delete any template sections that the original xtemplate had without causing errors.
    For example, the xtemplate theme includes a "mission" section (with a "mission" field). I didn't want to use a mission--but when I deleted it in the .xtmpl file I got an error message (the template couldn't be parsed). So I had to leave the section in, even though it was empty.
  • More importantly, I couldn't create new template sections or add fields to existing sections except by editing the xtemplate.theme file.
    In many or most cases, a theme or template designer is going to wish to add new information. Looking e.g., to the xtemplate settings page, there are a number of variables introduced for display via the theme--but what if a designer wants to add another variable? Or a module-based section? In either case they're stuck editing the (core) xtemplate.theme file--and, if they introduce any new template sections, this will cause errors in the use of any other xtemplate skin, as they will lack these sections.

In sum: I very much like the xtemplate system, particularly for its clear separation of logic from presentation. I'd wish to avoid a system that put the logic back into the skin. Having all the HTML generation in one file is extremely handy for customization. But to make xtemplate (or another candidate system) flexible and useful enough for easy customization, it would need some way to (dynamically?) modify the template sections and fields being parsed. In addition, it would need to avoid errors if requested sections were not present.

I can picture an interface that enabled the custom structuring of nested template sections, each with particular fields, with each field being linked to a data source (and, perhaps, section and field data stored in the Drupal database). This might resemble the current administration interface for nested book pages. Something of this sort would enable the online administration of the template structure so that designers could be freed from PHP and focus on design, while still haveing the flexibility to add new data sources as needed.

because xtemplate lacks any form of flow control or command syntax within the template library , you will always be required to make a change to the theme logic when adding or removing features not present in the base theme. I do not believe xtemplate is suitably designer friendly because of this actually.

By logic in the template file I am not referring to loading elements from the database, or manipulating data in any way, I am simply referring to presentation logic which would allow a template designer to (for instance ) foreach of the list elements; display this using these parts of the list. While I do believe in the seperation of code and markup, I also believe that presentation logic has a valid place within your markup.Of the template systems I intend to support.. xtemplate will likely be the only engine incapable of push/pull hybrid templating.

regarding your ideas about being able to have a templating system usefull enough for flexible customization. do some research on phptal , and take a look at an archived (yet at the time, completely valid) template file for my PHPTal drupal theme. Even though you might not realize it , the template contains some presentation logic which allows it to be incredibly customizable. Do a search for tal:for in the source code to see an example.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

Yep, this is one element missing in xTemplate - a logic file unique to each template.

If the functions in xtemplate.theme were in a class, each template could have a logic file which could extend the class and override the functions with custom logic.

I like the idea of having a clean separation of structure, style, and logic. Also prefer logic to be implemented in PHP - developers already know PHP, and it's way more powerful than any template system language will ever be.

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

i want to know that is there module for moblog??

amadarum

Hello.

There is, but please, keep to the subject of the thread.

Ber

I'm one of those "designers" he is talking about, coming from movabletype and let me tell you, drupal is a fricking nightmare ot try to understand. luckily I was able to corner a resident geek and she explained the conceptual model. Now it know it will be hard to use, but it is doable.

Three things would help

1. Update the documentation to explain how templates work, especially in context of other popular CMS's and blogging tools.

2. Consider creating a design wizard. (I'd be happy to help design the interaction for it)

3. Make it easy and obvious to edit the CSS file. (preferably in the tool)

Thanks, and I really really hope you guys do find a way to make drupal easier to use, because it has amazing functionality.

WEB: www.eleganthack.com YIM: christina_wodtke

I have checked out the latest CVS and I was wondering what the status of this new templating system is. I'm going to be moving http://www.gamerswithjobs.com/ from our heavily modified PostNuke installation to a Drupal based solution. This new theme API sounds like exactly what I need to get the GWJ template done and I was wondering how far along it was and if there was a place I could check on the status or possibly pitch in.

Hi,

I am capable to program a little and PHP is new for me. I am still learning.

What makes THEME devoloping difficult is the missing of a clear documentation of the skeleton. I looked at several themes now and most of them do not look like eachother if looked to their structure.

So it is hardly possible for someone with a little experience to make his own theme. I know I am struggeling with it. :-)

Grtz. Henk

Grtz. Henk

WebSite powered by Drupal: http://pd5dp.ham-radio.ch
Other WebSite : http://www.qsl.net/pd5dp

Email:
pd5dp@amsat.org

any new work on this?

stay tuned

If you had asked me a few weeks ago if Curl, the web content language ( www.curl.com and not haxx.se cURL ) had any relationship to PHP or Drupal I would have said a flat 'no'. That was before I came to see how many web templating options are tightly-coupled to HTML, XHTML , XML or any 2 or 3 of these together. For better or worse our web is HTTP - it is not HTML. And thank goodness it is not (yet) dependent on XML.
A few weeks ago I would have said that PHP as a language interests me no more than Perl. Give me REBOL or Smalltalk or python or Ruby or ICON or ObjectIcon.. And now maybe Io or Converge or Falcon.
But even the language that gave us MVC, Smalltalk, has no web framework that is not tightly-coupled to HTML. The case of Rebol is even sadder: the QuarterMaster framework is HTML to the core ( and even UNICODE Rebol3, like Tcl, cannot cope with literal strings which contain non-matching curly braces which means neither can handle literal strings. I cannot template is I am not allowed an open-curly brace, some value and then a closing curly brace. Nuff said. If there were an Apache modIcon for the ICON language, I would not be here. Oz would be the language to use if only anyone were using Oz. Gnu Smalltalk appears to be a hopelessly one-man show. So maybe PHP.
Curl is only of interest to enterprise, government or other large, secure environments. It was not even used for the Amaya browser in spite of their common DARPA/MIT origins.
My first criterion is ease of flipping Content-Type to text/vnd.curl and PHP passes that test.
My next criterion is ease of handling curly braces: in PHP those are within

<?php

?>

The final criterion is templates not tightly coupled to HTML - and that is what I am evaluating now.
And if we get a tie-in to an existing CMS framework? So much the better ...

Robert Shiplett
http://aule-browser.com