Howdy!
I have searched around but can't seem to find a definitive word on best theming practices when it comes to a site run mainly by cck and views.
User Case
A small non-profit publication that posts all of its magazine articles on line in a web format. I volunteered to designed the system using nodes types for stories, editions and contributors (Authors, photographers, illustrators, etc). These node types rely heavily on cck fields for images, text and the node referencing fields. Views is then used to determine which editions own which stories and which stories, photos, etc are owned by which contributor.
Most of this output is done in the theme files, and this is the problem for best practices.
For example, in my first iteration my node-edition.tpl.php file is about 400 lines of code as it has to load stories, retrieve titles, lead images etc and layout different sections of the magazine differently.
To streamline things a bits I created some custom layout functions (for repeat tasks) which currently reside in my template.php file. I assume this is bad practice (I am still fairly new to drupal development), but I am uncertain where is the best place to keep these functions? Would it be alright to store these functions in a custom module for the site, even though they require custom cck fields? Note, that I am already planning on creating a custom module mainly to deal with the custom blocks I have created.
Finally, I have been thinking about moving some of this code to the contemplate module (http://drupal.org/Project/contemplate) as it will simplify my theme files for when we find a drupal themer to work his/her magic. I was planning on using the file base contemplate approach for the main bulk of my layout code, but I am still uncertain where to keep these annoying custom layout functions.
Any opinions would be greatly appreciated.
Comments
Theming
No not bad practice - actually this is the right way. You should always keep as much PHP logic/functions out of your actual theme files as possible - keep the PHP in template.php or in your custom module (depending on the situation, e.g. some things can only be done inside of a module) and call that into your theme files with a basic variable. I assume you know how to do this from what you said, though if not: Setting up variables for use in a template (preprocess functions) (this is for Drupal 6... I do not know how to do it in D5, but there is a process for that). Using phptemplate_preprocess_node() is a life saver (there are also functions for page, comment, etc - or just phptemplate_preprocess() which you can pass a $hook).
Using this method I've got a rather complex forum + organic groups node template of mine down from several hundred lines, to about 60. All the complex PHP is in template.php, leaving only simple PHP print variables and a small amount of if/else statements to handle adjustments when the template is being used in the context of the forum, versus OG, versus a teaser, etc. Simpler content types have even less. Once in template.php they are also much more handy - I can instantly grab a huge chunk of functionality and drop it in any other node template using just a single line of code. I'm a themer and not really a programmer at all, but once I got the hang of this, Drupal became much more powerful to me :)
I haven't had too much occasion to yet, but I do use at least one CCK field inside of some PHP logic in my template.php (I'm checking whether a checkbox option on the node is checked or not, to determine whether to print the results of the PHP out for a particular user or role).
No, don't do that. Contemplate use, other than as a tool for discovering how to theme the inner "stuff" of a node/fields/etc is generally discouraged. If you use it and have it make actual physical files, this is "ok", but still not ideal in my opinion (just stick to your own node templates). You can copy/paste any of the code it suggests directly into your own node templates. Definitely do "not" override the theme directly in Contemplate (storing the changes only in the database).
Hope this helps :)
-- David
davidnewkerk.com | absolutecross.com
View my Drupal lessons & guides
Thank you!
Yes, I agree that it is bad to store PHP in the database. I did this once and took weeks to track down a mysterious server Error.
The reason I was considering the disk-based contemplate.module approach (i.e. node-{nodetype}-{field}.tpl.php" where {nodetype} is the content type and {field} is either "body", "teaser", or "rss" - stored in /sites/all/contemplate) as it seemed like a pretty clean way to do things for future themes changes the future. Especially, if I move my layout functions to a custom module.
Then again, as you suggested if I used the preprocess functions to set variables (this concept is somewhat new to me), I could do the skeleton of the layout in my node-edition.tpl.php theme file, which may make a bit more sense to a themer who might come in after the fact, rather than having everything spew out mysteriously at once when I print the
$contentvariable.I will have to do a little more research here, but I will likely follow your suggestion. Thanks for the lead.
Also, I just realized that it might be possible to duplicate much of contemplate.module function by implementing the hook_nodeapi() api in a custom module?
Anyone tried that?
Also what is the best base theme to start with? I have played with zen, but it seems to be getting pretty bloated. I am not sure how well it does performance wise.
I use the built-in views
I use the built-in views theming and they worked great.
Not powerful enough
Views theming is powerful, but not specific enough for my needs (I use it in limited cases).
For example I used some of the cck fields as radio check marks for choosing a theme to render the magazine article (we have 3 default themes - lead image full width, lead image inset right, lead image inset left). Doing this in the node-story.tpl.php is fairly straight forward.
Now I am looking at cleaning up my node-story.tpl.php file by moving this PHP logic code (not sure of a better term) either
The advantage I see in moving much of this code to a custom module, is that it makes it easier to switch the site to a new theme or to use multiple themes on the site as I don't have to recreate my template.php file. That way I can keep the template.php for overwriting various theme functions.
I am sure there are many more possible variations. I guess this is why I was asking about best practices. There seem to be so many options I was hoping to hear if anyone had a to make similar choices and could point me in a definitive direction.