0

I have a view with 2 contextual filters, each is set to display all results if not present. This is tested on the Views edit screen using the Preview Contextual Filters. Both contextual filters filter taxonomy term Ids.

With none set it gives loads of results; with '152' it returns three results; with '152/366' it returns one result. These are the expected results.

However in my Drupal 7 code I have tried the following, but none of the ones with filters work:

print views_embed_view('my_view','default'); // ✔ all shown

print views_embed_view('my_view','default',152); // ✘ nothing
print views_embed_view('my_view','default','152'); // ✘ nothing
print views_embed_view('my_view','default',array(152)); // ✘ nothing
print views_embed_view('my_view','default',array('152')); // ✘ nothing
print views_embed_view('my_view','default',152,366); // ✘ nothing
print views_embed_view('my_view','default','152','366'); // ✘ nothing
print views_embed_view('my_view','default',array(152,366)); // ✘ nothing
print views_embed_view('my_view','default',array('152','366')); // ✘ nothing
print views_embed_view('my_view','default','152/366'); // ✘ nothing

Also, all the ones that use array for the contextual filter argument generate an error: "html_entity_decode() expects parameter 1 to be string, array given"

I feel like I'm missing something obvious here...

  • Please check in the views preview section the format views is expecting the contextual filters But if there are 2 contextual filters code views_embed_view("view_name", "view_dsiplay_type", $filter1, $filter2), should work. – arpitr Sep 27 '13 at 9:49
  • The views preview says separate arguments with /, so 152/366 works, as does 152 for the single argument case. As I understand it views_embed_view takes separate arguments (as you point out), rather than a string combination that needs parsing. – artfulrobot Sep 27 '13 at 10:09
5

If you have devel installed , try checking with this syntax , if you do not see any result then try passing the arguments as 4/1(w.r.t given example) in the preview of views to cross check you have results with those combination of exposed filters. Debugging at devel/php will save lots of your time.

dpm(views_embed_view("view_name", "view_display_type", 4, 1));
  • 1
    Thanks! Got it. Completely unrelated to views. The test user didn't have access permission to see the output from the View. *blush* – artfulrobot Sep 27 '13 at 10:33
0

This is fixed for you, however there is another detail which may break the display of the view. If the arguments are optional then when not selected they will have the option -Any- with the value All.

In my case when -Any- was selected the view would break. Selecting specific value would work OK. The solution is in the Contextual filters options of the view. The Exception value under Exceptions must be All and it is case sensitive. Then the filter is ignored.

0

If your View has some Organic Group Relationships on it, be careful if you add a relationship like the one in #2 below. For me, adding that Relationship results in non-administrative users not being able to see any results from the views_embed_view.

Here's the Contextual Filter and Relationships that causes no results for me:

Contextual filters

  • Taxonomy term: Term ID

Relationships

  1. OG membership: OG membership from Content
  2. (OG membership from node) OG membership: Group Content from OG membership

At first I thought it may be a user permissions problem (from a comment on the accepted answer here), so I got desperate and I disabled and uninstalled the og_access module and rebuilt the user permissions, which didn't fix it either.

At this point, I recalled that these same Relationships work just fine on a different View, and so by this I figure that the combination of these Organic Group Relationships and the Taxonomy Term ID Contextual Filter are somehow together causing some weird access bug.

So the fix for me is to remove the 2nd OG Relationship from the View since it isn't a 100% requirement for my View, and to leave the Contextual Filter because it is required. It sure would be nice to bring in the Organic Group that owns the content here though.

It's sad that this happens, I bet I've been burned by this in the past multiple times and never really noticed this much about it until now. In the past I know I've given up on Views many times and just built a custom db_select to get the data I need. Le sigh, I hope this helps someone and my future self that gets burned by this again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.