function views_embed_view

This function is meant to be called from PHP snippets, should one wish to
embed a view in a node or something. It's meant to provide the simplest
solution and doesn't really offer a lot of options, but breaking the function
apart is pretty easy, and this provides a worthwhile guide to doing so.

Note that this function does NOT display the title of the view. If you want
to do that, you will need to do what this function does manually, by
loading the view, getting the preview and then getting $view->get_title().

Parameters

$name:
The name of the view to embed.

$display_id:
The display id to embed. If unsure, use 'default', as it will always be
valid. But things like 'page' or 'block' should work here.

Comments

The first option is the machine name of the view, this is found if you hover over the edit link on the views page and look at the link address. The second is the block or page machine name, so if its the first block it would be block_1 or block_2. This is found in the view under the "Other" list.

<?php print views_embed_view('blog_posts','block_1', $node->nid); ?>

Here is an example of views loading on a node page.

<?php

/** * @file * Default theme implementation to display a node. * * Available variables: * - $title: the (sanitized) title of the node. * - $content: An array of node items. Use render($content) to print them all, * or print a subset such as render($content['field_example']). Use * hide($content['field_example']) to temporarily suppress the printing of a * given element. * - $user_picture: The node author's picture from user-picture.tpl.php. * - $date: Formatted creation date. Preprocess functions can reformat it by * calling format_date() with the desired parameters on the $created variable. * - $name: Themed username of node author output from theme_username(). * - $node_url: Direct url of the current node. * - $display_submitted: Whether submission information should be displayed. * - $submitted: Submission information created from $name and $date during * template_preprocess_node(). * - $classes: String of classes that can be used to style contextually through * CSS. It can be manipulated through the variable $classes_array from * preprocess functions. The default values can be one or more of the * following: * - node: The current template type, i.e., "theming hook". * - node-[type]: The current node type. For example, if the node is a * "Blog entry" it would result in "node-blog". Note that the machine * name will often be in a short form of the human readable label. * - node-teaser: Nodes in teaser form. * - node-preview: Nodes in preview mode. * The following are controlled through the node publishing options. * - node-promoted: Nodes promoted to the front page. * - node-sticky: Nodes ordered above other non-sticky nodes in teaser * listings. * - node-unpublished: Unpublished nodes visible only to administrators. * - $title_prefix (array): An array containing additional output populated by * modules, intended to be displayed in front of the main title tag that * appears in the template. * - $title_suffix (array): An array containing additional output populated by * modules, intended to be displayed after the main title tag that appears in * the template. * * Other variables: * - $node: Full node object. Contains data that may not be safe. * - $type: Node type, i.e. story, page, blog, etc. * - $comment_count: Number of comments attached to the node. * - $uid: User ID of the node author. * - $created: Time the node was published formatted in Unix timestamp. * - $classes_array: Array of html class attribute values. It is flattened * into a string within the variable $classes. * - $zebra: Outputs either "even" or "odd". Useful for zebra striping in * teaser listings. * - $id: Position of the node. Increments each time it's output. * * Node status variables: * - $view_mode: View mode, e.g. 'full', 'teaser'... * - $teaser: Flag for the teaser state (shortcut for $view_mode == 'teaser'). * - $page: Flag for the full page state. * - $promote: Flag for front page promotion state. * - $sticky: Flags for sticky post setting. * - $status: Flag for published status. * - $comment: State of comment settings for the node. * - $readmore: Flags true if the teaser content of the node cannot hold the * main body content. * - $is_front: Flags true when presented in the front page. * - $logged_in: Flags true when the current user is a logged-in member. * - $is_admin: Flags true when the current user is an administrator. * * Field variables: for each field instance attached to the node a corresponding * variable is defined, e.g. $node->body becomes $body. When needing to access * a field's raw values, developers/themers are strongly encouraged to use these * variables. Otherwise they will have to explicitly specify the desired field * language, e.g. $node->body['en'], thus overriding any language negotiation * rule that was previously applied. * * @see template_preprocess() * @see template_preprocess_node() * @see template_process() */?><div id="node-<?php print $node->nid; ?>" class="<?php print $classes; ?> clearfix"<?php print $attributes; ?>>

<div class="content"<?php print $content_attributes; ?>><?php// We hide the comments and links now so that we can render them later.hide($content['comments']);hide($content['links']); print render($content);?> </div> //Embedding the view before the comments are displayed <div class="embedded-view"><?php print views_embed_view('blog_posts','block_1', $node->nid); ?> </div><?php print render($content['links']); ?>

Something gets mucked up after the first display is used, because block_1's VBO (bulk operations) gets applied to all the subsequent displays that are previewed. The only fix I've found for this is to call views_get_view('my_view') again, which seems wrong...

If anyone is trying hard to figure out the display's machine ID, expand the "Advanced" pane (right most), and under "Other" configuration, you will see "machine name" setting that you can even change! In D6/Views2, you could just use it but now you can change it!

But when you filter them on the UI side (IE: when you're building your view and adding contextual filters), how do you reference each one? For example, if I just pass in two integers, how does it know one is a reference to a nid and the other is a uid?

We were running into issues where a callback function (run via cron our drush) would not return the view results, but it worked fine with devel's PHP execute page.

The issue was views access permissions and/or the entities it referenced. While it worked when we used the advanced query setting "Disable SQL rewriting", that was not ideal. Instead we opted to alter the global user temporarily, which might work for anyone else that runs into this use case... For example: