Transferred from my blog at Dries' request. First, the blog post:
Today on drupal.org I just posted my ‘personal battle plan’ and it includes a fairly large project that doesn’t actually require a great deal of Drupal experience to help on; it requires just enough coding knowledge to extract the right amount of code, create the files, and then — probably the only place where a little bit of coding knowledge is really needed — effectively separate logic from presentation without adding too much processing time to the code.
The idea here is that I think there should be a project called the Drupal 5 Themer Pack which includes every (or nearly every) theme function in Drupal 5 core as a .tpl.php and the corresponding template.php code. Right now I envision the structure that each Drupal ‘system’ might have a file such as template-forum.php which is included from your standard template.php. It includes all of the forum theme functions, and each one has a .tpl.php for presentation. This code does not change the output in any way but makes it easier for Drupal themers to identify the theme functions they need and actually modify them.
As a bonus, it might include alternate versions — maybe a PHPbb-like set of templates for forum, or whatever. Plug it in, make the changes you need, and go.
There is a fair bit of work here, but it’s also learning work — because in so doing, whoever extracts the theme functions will be forced to learn something about how Drupal actually does that part of the code. It could lead to recommendations for patches for future versions of Drupal to improve the theming functions, and it could make life a whole lot easier for themers who don’t want to have to know anything about code at all, because they can take these things that are already created for them and simply tweak them. That’s a lot easier than doing the actual extraction like they have to do now.
Right now I am basically doing an exploration of who might be interested in contributing to this project, and working to organize effort and get something good going here. I’m thinking of pitching this to the Drupal Dojo as something that students can work on as a learning exercise AND contribute to Drupal.
Any thoughts? Want to work on it? Make sure I have contact info — as I’ll be putting together a list.
Second, Dries' response:
Earl, for Drupal 5.0, Vlado, Adrian and myself spent a couple of weeks trying to move all theme functions out of the modules into stand-alone phpTemplate files. The idea is that designers should simply copy the template file and start modifying it, rather than having to convert a module into a theme themselves.
We created a script that does just that -- and that got us 95% there. It removes the theme functions from the modules, converts them to template files, and stores the template files in the module-specific directories.
It all worked (except for the last 5%), but the problem we ran into is that it turned out to be 10% slower.
I'm hoping you and others can pick up the work (with help from us), and help us get this _in_core_. I think this is a case where we are better of changing the default behavior. It makes too much sense not to do it in core -- plus, we already started working on it.
What needs to be done is "simply" this: we need to make it 10% faster. :-)
Let's talk more about this on the mailing list?
My response: Yes, there are absolutely aspects of this that are a good push toward core. However, there are a couple of important things here: 1) Drupal 6 should be 6 months away, and this kind of project can benefit now, as well as having a future benefit by having the bulk of the theming work be done now. By being useful now, people who might not otherwise participate in this work might participate and contribute. 2) I think it's important to get more themers participating in Drupal, and making this easier is a good way to do it, and to follow up 1, can be a major benefit now. 3) I don't have a solution for the 10% slower yet. 4) This project mitigates that 10% problem by presenting the pack as a pick & choose type deal. You don't include the templates for items you aren't overriding, but for themes that do want to override them, they drop the code in, add a line to their template.php to include the right stuff, and start modifying. To refute 3) above, I might have a solution to the 10% issue which involves template compiling -- I believe the bulk of the slowdown comes from having to read template files into memory over and over again. Compiling all the .tpl.phps into a single file could mitigate that effect. I don't know, it'd have to be proofed and benchmarked. This work could benefit that. Also, I have access to Frando's work on creating .theme files but I don't have access to Adrian/Vlado's work on separating out into .tpl.php. Frando's work includes an extractor, though, that I think can be repurposed to do just that, so I'm not terribly concerned.