CCK and Theming: content_format() & direct $node field reference VS. tpl file

Thanks for the compliment :D I'm always trying to improve my lessons/guides (the above mentioned one in particular), so I'm keeping an eye here to see if I can learn more as well, and add it to the lesson. I'm particularly interested in providing a good explanation for content_format() and how to use it in all the common cases for fields (single fields, imagefields, multi-value fields, etc). I haven't come across a complete-enough explanation of this yet, so any info or references (from anyone who knows) would be appreciated - and I'll expand my lesson once I understand this myself.

One partial response, regarding your Question 2: for me, preprocess functions are not really something I personally use in the sense I think you are describing to work with ordering or altering CCK fields (though there's no right or wrong way I'm sure - if it does what you want, and it's secure, go for it!). Here is one example of a snippet from the template.php of a site I'm working on, in the phptemplate_preprocess_page() function (I have similar snippets for _node but this is shorter/simple enough for the example):

function phptemplate_preprocess_page(&$variables) {
  // Login, Register, Logout, Account links
  global $user;
  if ($user->uid == '0') {
    $user_login = l(t('Register'), 'user/register') . '<span>or</span>' . l(t('Login'), 'user/login');
  }
  else {
    $user_login = l(t('Log out'), 'logout') . ' | ' . l(t('My Account'), 'user');
  }
  $variables['user_login'] = $user_login;
}

This could equally be placed (and in my case initially was) inside of page.tpl.php, in the spot of the theme were this functionality was to appear (the main difference being global $user wasn't added, that last line wasn't there, and of course just php open/close tags instead of the phptemplate_preprocess_page() function part). However that makes a mess of complex PHP inside my theme file, which would easily distress a themer who didn't know any PHP (such as myself not too long ago). In the theme file, a designer just wants to worry about theming as close to plain ordinary HTML as possible (and even "I" would rather not see that code cluttering up the theme file while I'm trying to work with the HTML and CSS). So instead, I cut and paste that code out of page.tpl.php and into template.php, in my phptemplate_preprocess_page() function. This part, ['user_login'] is where I define the variable that will be made available to page.tpl.php (though I use the same name in my function, it doesn't have to be). Then, using the variable name I chose at the bottom of the function, I can just write <?php print $user_login; ?> in my page.tpl.php. Whenever I make something like this I ensure it has a good HTML structure I can get at with precision using CSS, adding a container with ID or Class when necessary (so a themer would then not have to worry about ever touching that PHP... just check with Firebug to see how to get at it with CSS).

Others may feel differently, but personally I dislike the concept of having a separate template file per field. The quantity of files can quickly become overwhelming and confusing, and seeing everything in context is more difficult. It's also harder in instances where you have one snippet of code (say, an opening container div meant to hold a certain group of the fields) begin in one template file, remain open, and then close in another template file. On the other hand, in a single template file (preferably with proper indenting), this structure is instantly clear, and familiar enough to a themer accustomed to working with static HTML.

For simple cases when overriding $content may be unnecessary: though it also affects the order of fields on the Content Type's create content form (so may not be desirable), for basic re-ordering of fields, the drag and drop order of fields on the "Manage fields" page of the CCK type does affect the order in which fields are output to $content. Assuming you're ok with the same order on the create content page, for some cases this should be sufficient.

Anyhow, I hope this helps... and I hope to learn more myself as well :)

- David

for others who stumble here:

beware of using $node->field_name[0]['view'] vs. $node->field_name[0]['value']

the 'view' approach will respect permissions on that field, the 'value' approach will not. this means that even if the permissions has said anonymous users cannot see this field, your theme might blow that away and show that field to the public. yikes!

I just wanted to add a way to obtain the list of formatters available. If noone uses it, at least I write it here for myself in case I need it in the future:

drupal_set_message('<pre>'. print_r(_content_field_types(),true).'</pre>');

will render something like

Array
(
    [fivestar] => Array
        (
            [label] => Puntaje Fivestar
            [description] => Guardar un voto para este tipo de contenido.
            [module] => fivestar
            [formatters] => Array
                (
                    [default] => Array
                        (
                            [label] => Como Estrellas
                            [field types] => Array
                                (
                                    [0] => fivestar
                                )

                            [module] => fivestar
                        )

                    [rating] => Array
                        (
                            [label] => Puntaje (p.ej. 4.2/5)
                            [field types] => Array
                                (
                                    [0] => fivestar
                                )

                            [module] => fivestar
                        )

                    [percentage] => Array
                        (