Contextual View Blocks
The basic technique here is to decorate an existing page (a node page, or another view) with a view block, and then to take the parameters for the view block from the path, By placing a snip of php code like the following in the "Argument Handling Code" section of the view configuration field for the view:
In 4.7:
<?php
if ($view['type']=='block' && arg(0) == 'node' && is_numeric(arg(1)){
$arg[0] = arg(1);
}
?>In 5.x:
<?php
if ($view->build_type == 'block' && arg(0) == 'node' && is_numeric(arg(1))) {
$args[0] = arg(1);
}
return $args;
?>NOTE: The code should not go between <?php and ?> delimiters; just typed in directly.
This code is called whenever the view is accessed. It says "If the view is a block, and the path is "node/n", where n is an integer, then set the view's first argument to the integer. We know that paths that look like /node/n point to a node.
"But what if I'm using pathauto.module to set up custom paths for my nodes?", you may ask. Well, path aliases only change the outward-facing path. Internally, modules will still see the original, canonical path (ALWAYS!). This is very useful.
Now we should set up our view so that it takes that argument from the path and actually does something useful with it. Examples:
- Show all the nodes authored by the current user whenever someone visits "/user/n"
- If you use CCK, show all the nodes referenced by the current node.
Some more advanced ideas:
- Check the path in the "Block Visibility" field of the block config page for the view block instead of in the view argument section, like:
<?php
if (arg(0)=='node' && is_numeric(arg(1)) { return TRUE; }
?> - Actually load the node with:
$node=node_load(arg(1));and then use fields on the node (such as $node->type and $node->uid (author)) as parameters. You can also use this technique without views, printing out fields from the current node in a custom block. Also, node_load caches the node object, so this is actually not a significant performance hit (the node is already being loaded for display).
Here's my recipe
I needed to upgrade the behaviour of earlier solutions like 'sidecontent' or my home-rolled 'relatedblock' to just
Add a textarea where we can put content to show up in a block beside a node
I want a column called 'adcolumn' which is hand-filled to show stuff relating to pages. A 1-1 relationship.
Create the Field
Enable Views and CCK and Text field
Create the Block
Add a view. admin/build/views/add . Called adcolumn also if you like, it's not important and they don't conflict.
Title: optional
Nodes per Block: 1 I guess. Doesn't make a difference.
No more link, no header or footer or empty text (for me).
No sorting etc options need to be changed. (Label:blank, Handler:Group, option:default, Sortable:no, Default Sort:none)
Add Argument: Node: ID
Default: Empty Text, Title: blank, Option: equal, Wildcard:blank, Wildcard Sub: blank
Argument Handling Code
if (arg(0) == 'node' && is_numeric(arg(1))) {return array(arg(1));
}
Almost there...
Enable, theme, layout
Visit admin/build/block and shift the new block into a sidebar or something.
Have a look at the page you added side content to before.
It should start showing up!
Turn it off by visiting [Administer - Content Management - Content Types - Page] and clicking the "Display Fields" tab.
It's all cool once you know what you are doing, but I got sidetracked trying to grok argument handling.
The content shows up unneccesarily framed in either a LI or a table cell. I guess this can be fixed with views theming, but I'm just going to normalize it with CSS tody.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
Context sensitive embeded views
Here's an article that uses these ideas to embed a context sensitive view on a page that pulls in other content created by the owner of that page, based on a Node Reference.
See : http://drupal.org/node/221919