I think an example would be the best way to demonstrate this. Earl? On 3/27/07, Chris Johnson <cxjohnson@gmail.com> wrote:

I read the issue referenced and all of its comments. However, as someone who is not expert in theming, I did not see how this makes it easier to theme Drupal. It just makes it different, from my limited view.

Can someone explain in fairly plain language what the immediate benefits are which make it easier?

I think it might be helpful to module developers to understand what they can now do, or shouild do, which will make theming Drupal installs using their modules easier to theme.

Thanks, ..chrisxj

-- 2bits.com http://2bits.com Drupal development, customization and consulting.

Chris Johnson wrote:

I read the issue referenced and all of its comments. However, as someone who is not expert in theming, I did not see how this makes it easier to theme Drupal. It just makes it different, from my limited view.

Can someone explain in fairly plain language what the immediate benefits are which make it easier?

I think it might be helpful to module developers to understand what they can now do, or shouild do, which will make theming Drupal installs using their modules easier to theme.

1) Modules can provide *.tpl.php files right in their module directory. By being separate files, they are easily found. 2) These .tpl.php files have a 3 step process to use by a themer: Copy the .tpl.php file into the theme directory, edit the .tpl.php, and clear the cache. phptemplate.engine will discover the new .tpl.php file without needing a template.php at all. 3) The phptemplate_variables_HOOKNAME syntax is a lot easier to use. It's also marginally faster as it uses references, not array_merge. 4) As Dries commented, by having the tpl.php files available (note that this is actually another step, but that's why I'm working on the themer pack; to get the .tpl.php files available in a usable form) this makes it easier for a contrib module to create from-the-web theme editing. Right now such things exist, but they only have access to about 8 templates. Drupal has 137 themable functions in core. Add in a few modules and this quickly goes up to 200, or more. Most of these themable functions are simply inaccessible. They are buried in the code and they are not written in a way that separates logic from presentation, so a designer can't do much with them. 5) Once this is really really done, i.e, as many .tpl.php files are created as should be (which is not to say that Every Single Template should be a tpl.php, but most of them should be), alternative theme engines should find it relatively easy to translate core's existing templates. This will be really useful for 4, where you'd rather let people edit smarty or phptal syntax rather than PHP.

On 27 Mar 2007, at 12:28, Chris Johnson wrote:

I read the issue referenced and all of its comments. However, as someone who is not expert in theming, I did not see how this makes it easier to theme Drupal. It just makes it different, from my limited view.

I've spent some time reviewing this patch (http://drupal.org/node/ 130987) and I think it's almost ready to go in. This is likely to be one of the killer features in Drupal 6. It would be appreciated if other people could provide their last-minute feedback/review. Thanks, -- Dries Buytaert :: http://www.buytaert.net/