I would like to ask for some context variables to be defined, so theming can be done that depends on the context:

we alread have $teaser to know if the node is being called as a teaser or full

but I think some powerful context variable would be:

$block - the node is being called from a block, that is, the node will be shown in a block, probably as sidecontent

that way, the theme would be quite powerful and would solve a lot of possibilities.

Comments

joachim’s picture

Title: Context variables » Context data for nodes

Adding context information to the node object and subsequently the node template would open up many possibilities for modules and the theme.

Currently we have a few flags that follow the node object around: 'teaser' and 'page'. These get abused by quite a number of contrib module to get a desired effect, but doing so can have negative side-effects on other modules (eg nodeblock loads nodes as non-teaser, but community tags gets broken by this).
By the time we get to the node template, we also have is_front and sticky variables.

We could generalize these and allow the modules that contribute to the node to also add their data here.

Some practical examples of what data to store:

General nodes
We already have 'teaser' and 'list' that follow the node object around in node_view calls. 'sticky' is stored in the node object itself. We can fold all these in.
In addition:
- nodes in a list would get 'first', 'last', 'even' and 'odd'. Various possibilities for themers :)
- location in the page: most nodes are in the main content area, but some modules load nodes for display in a region.

Blog nodes
Each blog node would get:
- blog
- blog-user

This means we can avoid the current odd situation where an individual's blogroll at blog/user/1 shows their user picture over and over and over again. With the 'first' context flag, a theme can show the picture on only the first post.
Alternatively, a site could put the user picture and user details in a block and hide the userpic completely on in the individual blogroll. Either way, we get something a lot snazzier.

Taxonomy
We could hide the current term in the list at taxonomy/term/1, or highlight it in some way.

Views
There's a huge number of things this would be good for views.
I often find I do a load of view theming, when all I really want to do is say 'don't show the node links on teaser nodes in this view' (and I want a teaser list; really don't want to reinvent the wheel styling a list view).
If the views module dropped the ID of the view into context, a simple switch in the node template would do the job.

The hardest part of this is going to be figuring out a clean, simple, and extensible data structure that is easy to access.
My very vague current thinking is that the keys should be the flag names and the values either TRUE or some sort of data if needed.
This is just a rough initial sketch to start a discussion on:

// imagine we're setting the context array for a blog node in one go
$node->context = array(
  'list' => array(
    'first' => TRUE,
    'even' => TRUE,
  ),
  'region' => '_main', // the main content area, alternatives are theme region names.
  'teaser' => TRUE, // shown as teaser
  'blog-user' => 1, // shown on an individual blogroll, giving user ID
);

An alternative would be to store the name of the module that set the flag as the value instead of just a TRUE -- I'm not sure this would have any useful applications though, just seems like potentially a good idea:

$node->context = array(
  'list' => array(
    'module' => 'node',
    'first' => TRUE,
    'even' => TRUE,
  ),
  'region' => array(
    'module' => 'node',
     '_main', // the main content area
   ),
  'teaser' => 'node', // shown as teaser
  'blog-user' => array(
    'module' => 'blog',
    1, // user ID
   ),
);
Farreres’s picture

I am very sorry that I didn't see your reply. I don't have that profound knowledge, but I agree with you, theming should be empowered and made more flexible. I hope others join the discussion sooner or later.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.