Views content type fails on unspecified arguments [#1362448]

views_content/plugins/content_types/views.inc, doesn't handle arguments that wasn't passed, properly. It doesn't add anything to the $args array before looping, causing subsequent args to be shifted by one. This causes the original missing argument to get the value of the following, which can give pretty odd behaviour.

Comments

Comment #1

merlinofchaos CreditAttribution: merlinofchaos commented 6 December 2011 at 14:44

Status:

Active

» Postponed (maintainer needs more info)

Wasn't passed properly?

I'm not sure it's possible for that to even know what 'proper' is for the arguments. The generic view handler just passes along what it was configured to send.

Can you give a more detailed example of what you mean? Because anything I can think of amounts to configuration error.

Comment #2

Xen CreditAttribution: Xen commented 6 December 2011 at 18:01

Status:

Postponed (maintainer needs more info)

» Active

No, "doesn't handle [...], properly". That is, it's "missing arguments" that it doesn't handle.

I ran into the problem with a view that had 2 contextual filters: one taking a OG group and one taking a taxonomy term, but I can't see why it shouldn't be the same for 2 term filters, lets call them "group" and "category".

The view has a "Context" display, and the group filter is set up to to provide a default value when not supplied, which is the same as the wildcard.

In argument input, both is set to "From context", the appropriate type is selected ("Term ID") and they're set to "Context is optional".

Now, in a page manager panel which has a term context, we'll insert the view and select "No context" for the group argument, and "Term ID" for the category argument.

This has the effect of having the category term id from the panel context, end up in the group argument, which might work for 2 term filters, depending on how the view is configured, but will produce very odd results with different types of arguments. The issue is that it loops the configured contexts through, and converts the contexts as specified, but if nothing is specified, or the context doesn't exists, it doesn't add anything to the array of args sent to the view, which messes up the ordering.

Using a Content pane display instead, things work as you'd expect, configuring the group filter to take a "No context" argument, causes the group filter to use the wildcard, and the category filter gets the id intended for it.

Comment #3

merlinofchaos CreditAttribution: merlinofchaos commented 6 December 2011 at 18:54

Ahh! Ok, there was definitely some valuable data in that followup.

I'll add that 'views_content/plugins/content_types/views.inc' doesn't handle the content pane displays, so I never even thought about that aspect. (That's handled by views_pane.inc)

So what you're saying is that this bug is actually unique to the 'context' display and not the 'content pane' display. Is that accurate?

Comment #4

Xen CreditAttribution: Xen commented 6 December 2011 at 19:55

Exactly. I've fixed my personal problem by using a content pane instead.

Comment #5

merlinofchaos CreditAttribution: merlinofchaos commented 3 April 2012 at 00:13

Status:

Active

» Fixed

Oh I see now. You were inserting a 'context' display as actual content. That...is something you probably should not be doing. Those views are not meant to be utilized in that manner.

Wow, this bug was *much* easier to fix than it was to understand.

Committed and fixed.

However, the solution you came up with is superior -- in my opinion you should always content pane displays with your Panels. They are vastly superior.

Comment #6

Xen CreditAttribution: Xen commented 5 April 2012 at 20:50

It wasn't me, it was a coworker, it was only after some fiddling that I noticed that it wasn't the usual content pane... But I haven't figured out yet what this context thing is about either.

If context displays aren't supposed to be used that way, wouldn't it make sense if they cann't be?