This is not really a feature request, but rather a workaround that provides an easy way to use Views to generate the output for nodes of a particular type (but not other types). I had a need for this and in searching the Views issues found several other people were looking for an answer. So this posting is informational, in the hopes that TNPB (The Next Poor Bastard) won't have to bang his head against the wall figuring out the solution.

Problem: You want to use Views to display nodes of type "derf", but not change the display of views of another type.

Solution: A combination of a View and a custom node display, as follows:

1) Create a view "derf_node" with an argument of type Node: NID and the usual filtering. Get it so it displays things the way you want.

2) Find the node.tpl.php file in your theme. Make a copy and name it "node-derf.tpl.php". Open the copy and in it you will find a line that looks like this:

print $content

Change this line to something like this:


// change these to change what view gets called

$viewname = "derf_node";
$display = "default";
$view_args = $node->nid;

$view = views_get_view($viewname);

if ($view_args != NULL) {
  $view_args = explode(',', $view_args);
}
else {
  $view_args = array();
}

if ($view) {
  print $view->preview($display, $view_args);
}

Save it. Now try redisplaying one of your derf nodes, and shazam, you're seeing it styled by your view.

Kudos to mlsamuelson, author of the most useful insert view module, whose code I shamelessly stole when developing this scrofulous little hack.

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (fixed)

This is the kind of thing that should probably either be posted as a patch to the documentation, or in the documentation section. Given the massive number of open issues in the queue, this is likely to be lost in the noise here.

MadOverlord’s picture

MadOverlord commented
Component: Miscellaneous » Documentation
Status: Closed (fixed) » Active

OK, moved it to documentation. I suggest there be a section in there called "Stupid Views Tricks".

Also, realized after perusing the advanced help that the code can be simplified to:

print views_embed_view("derf_node","default",$node->nid);

merlinofchaos’s picture

merlinofchaos commented
Project: Views (for Drupal 7) » Documentation
Version: 6.x-2.8 »
Component: Documentation » New documentation
Category: feature » task

Moving to Documentation queue then.

arianek’s picture

arianek commented
Category: task » feature
Issue tags: +views, +tutorial, +Documentation, +views tutorial

merlinofchaos:

this seems like handbook fodder to me ;-) i had a back and forth with esmerel (here: #233957: How to set up a category list) about whether it's ok for us to start maintaining the views section of the handbook - that's where i think tips like this out to live. the section is a little messy right now, but it *sounds* like you'd be ok with us adopting it and getting it back into shape, and maintaining it.

i'll plan to do so, and if you have feedback, issues, etc. regarding that, i've just started a Docs issue for it here: #673228: Clean up Views section of handbook

merlinofchaos’s picture

merlinofchaos commented

I'm definitely for the handbook contianing a section on tips, tricks, common view exports and other non-core documentation that would clutter the basic "how to use this" documentation that's in the advanced help. The biggest problems will be duplication of data and things that straddle the line between what should ship with Views and what shouldn't.

That and the user confusion the separation will create.

arianek’s picture

arianek commented

great - well, i can totally understand your concern, i think it would be useful to have a pretty clear division between what goes where, which will be stated at the top of the main pages in the handbook's views section. and whoever works on and reviews this will need to familiarize themselves pretty thoroughly with what is in the advanced help so that they can direct updates to the appropriate place. (maybe we can even post a views docs mini-guideline as well.)

MadOverlord’s picture

MadOverlord commented

FWIW, I'm totally in agreement about having this stuff in the handbook.

I would have a special "recipes" section where people can contribute quick tricks and hacks like this one. The key is to make it as easy as possible for people to contribute, and to encourage them to structure the contributions so that TNPB will run across them when googling or searching drupal.org.

That's a big reason why I posted this originally -- to make sure it would be findable by the TNPB and so save them time.

PS: huge kudos for Views, btw. I think there's maybe 2 pages on my site that don't use it either directly or through insert view.

arianek’s picture

arianek commented

hi.... i'm combing through the entire docs queue again, picking away at things.

re-reading this - i think i'm missing something, but........ why would you want to do this using code when it's a basic function of views to filter by node type, and you can export the code?

someone fill me in, or i think i ought to close this (there's a separate issue filed about working on the views docs)

MadOverlord’s picture

MadOverlord commented

I don't remember the exact circumstances, but it was useful in situations where you want a specific node type to be handled by a specific view. I was never able to find settings that did this entirely within views -- ie: the view is only executed when a specific node type is displayed, and it is the only view executed in the page content.

If there is a way to reproduce this effect inside views, great -- it should be better documented.

I was using it to replace the default display of ubercart product nodes with my own view -- ah, that might have been the reason; ubercart was generating its own specific output, so views would not get called. This was the method I found to over-ride it, because node-templates get called first.

Best,
R

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented

It actually looks like you were trying to use Views to style your node's display, instead of the standard/coding way (which would be writing code in node.tpl.php). So you could set up a View and pick the fields and other display options, and not have to write the code yourself in node-your-type.tpl.php.

arianek’s picture

arianek commented
Status: Active » Closed (won't fix)

i've just pinged an advanced themer on IRC to discuss this approach, and it sounds like it's an edge case, and not in line with best practices, so best not to add to the documentation. closing as won't fix.