I've found that if a module's preprocess functions use the module name instead of "template" any theme that wishes to add or change things with a preprocess function must fully re-implement the preprocess function. Additionally, the re-implementation can be unreliable since on cache clears both preprocess functions can run. If the preprocess functions are named with template all the variables will be set and handed off to the overriding preprocess function where the values can be changed, added or removed (i.e. template_preprocess_privatemsg_view in favor of privatemsg_preprocess_privatemsg_view). This greatly reduces the amount of code that needs to be copied around and simplifies things for themers who may not understand or be interested in the logic that's being added by the module.
For what it's worth, this is how it's suggested to implement a module's base preprocess functions: http://drupal.org/node/223430
I've attached a patch that does this for privatemsg and have confirmed it cleans up a lot of our custom privatemsg theme issues.
| Comment | File | Size | Author |
|---|---|---|---|
| privatemsg.patch | 1.87 KB | elliotttf |
Comments
Comment #1
jerseycheesesubscribing
Comment #2
berdirThanks, didn't know this.
Commited to all branches, except this part:
this is IMHO correct, because we extend an existing preprocess here, author_pane is a template defined by author_pane.module, not by us.
Powered by Dreditor.
Comment #3
michelle@Berdir: Yup, definitely don't want to commit that bit since template_preprocess_author_pane already exists in AP. :)
Michelle
Comment #4
elliotttf commentedAh, right you are, sorry about that. Thanks for committing the others though.