Exposed filters: URL processing on embeds

Ah, I didn't know that. I'm not a developer, I just wanted to make my site work. Said that, this is probably a bug in Category package, which I'm probably unable to track down and report correctly.

But wouldn't it be much more simple for everyone, if my patch was used instead of requiring other modules to do tricky things? I'm afraid that very few module developers are thinking specifically about Exposed filters while embedding. My patch works well in all cases, I believe.

If this is rejected for a good reason - right. But I'm afraid that the situation is quite hard to solve at all, then. (Requiring all embedding module's authors to cooperate, I mean.)

Changing to "code needs work", assuming that my simple patch is not much welcome here.

After more checking, I noticed that on my Category+View embed only the Exposed filters button breaks, not the click-sortable table headers. I seem unable to find where these titles are generated for reference, but this is at least inconsistant. Clearly the URLs are constructed some other way on table headings (and good, even with URL aliases working), which should be used on Exposed filters submit also. Then no need to other modules modifying $view->something

The change of button-label for localization compatibility - no change of my opinion at all. Necessary.

I would rather think that an Exposed filter is merely a tool to control the node-listing behaviour, just like the clickable table-titles.

For the name of button, another suggestion might be "Search" or something like that, which is the case on my site. I'm not native English speaker, not much help here. BTW - end-user-confusing terms are all over Drupal.

Okay, submitting a new Issue to the Category module project, to fix my problem at the right place.

Just for reference - it's here: http://drupal.org/node/159378

BTW - the passing of URL to view->url while embedding is a bit strange thing, due to the filtering arguments (when used):

--- If URL alias is passed in, it breaks, because Views append the arguments to the URL. (In my case I passed 'url_alias_for_category', and the Submit button pointed to 'url_alias_for_category/###&filter_values', where ### is the third argument given to views_build_view. This URL doesn't work.

--- Luckily, in this case the argument is just node-ID, which is present in un-aliased URL already (but what if the argument was calculated by the embedding module, not present in the URL at all - heh?) So I sent 'node/###' to view->url ... And got 'node/###/###&filter_values' ! This one works, okay, but stil is not fully correct.

--- So finally I found out, that I should send 'node/$arg' to get just 'node/###&filter_values'.

My comments:
--- Can't find this in documantation (adding a comment now)
--- The URL on Submit button my not be aliased.
--- There should be a way to pass-in URLs, where the given arguments are not necessarily present. So we need some mechanism to leave passed-in URL untouched, if the view is embedded! (This whole problem is about view->url to view->real_url change.)

Ok, the URL-problem is now fixed in category_views module ( http://drupal.org/node/159378 ), so this part is closed.

Changing the title now, to reflect remaining things to be solved somehow:

--- Submit button label to allow sensible localization
--- Discuss URL arguments affecting passed-in URL on embedded views

The URL's on embedded View with Exposed filters AND arguments:

Passing URL's into embedded View via $view->url is currently insufficient, if there is some Argument given (third argument to views_build_view() ). Views always encode the Argument into the URL, either replacing "$arg" placeholder or just appending to the end, making it impossible to correctly embed into a page with URL not containing the argument (URL alias especially).

In the source code I read a comment on $type: " 'embed' -- Use this if you want to embed a view onto another page, and don't want any block or page specific things to happen to it." I think that URL-modifications should be also disabled by 'embed'.

So I created a simple patch (attached), resulting in the following behaviour:
--- If the View IS NOT the 'embed' type, all works just like before.
--- If the View IS 'embed', and the supplied URL contains the '$arg' placeholder, then the argument is encoded just like it was before (giving '$arg', the embedding module clearly wants the encoding to be done).
--- If the View IS 'embed', and there's NO '$arg', then the given URL is used without change (no encoding), allowing ANY url to be used, even if it doesn't contain the given arguments.

Now on 6.x-2.x :

The problem of URL handling on Exposed filters' submit button in the case of embedded views still stands as it was in Views 1.x.

To summarize - once a view embedded on another page have Exposed filters, the submit button points to the view page (not the page where it's embedded), so just applying a filter to the shown list of nodes takes you to entirely different page. That's not desirable (in most cases, if not all).

Back on 1.x I was told to set $view->url explicitly to override the path - now it's renamed to $view->override_path, having quite the same function, and the same problem too: If arguments are given to the view (by passing them as function arguments while embedding), Views code still inserts the values into the path (either by replacing placeholders '%' [was '$arg' on 1.x], or appending to the end). This is fine on dedicated pages of the views, but with an external path override it breaks the path. If the argument values are present in the original [embedding page] url, somewhere, then we can work around the problem by passing a path with dummy placeholders for Views to replace, but while passing arbitrary arguments [not present in the actual URL], no luck at all. There's currently no way to pass an arbitrary path as override, without having it changed by Views.

Additionally, we now have a nice wrapper function views_embed_view() for easy embedding. This function is in the position if a view is embedded, it must become the developer's responsibility to assign URL appropriately per #4, it's 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 per it's phpdoc, but still it lacks any handling of the embedding path, becoming unusable on views with exposed filters.

(As a sidenote, the views_embed_view() documantation is misleading - it accepts a numeric ID of the view as first argument, not name.) EDIT: It accepts both, sorry for my misunderstanding.

-------------------------------

Example use-case (skip if scared of wall-of-text):
Let's say, I was writing a few articles about topics corresponding to Taxonomy terms on another content type, and wanted to embed lists of these related nodes somewhere in the article, also allowing the viewer to further filter the list. I'll create a View, and embed it through a snippet pasted to each of these articles. The View will have a few Exposed filters for additional filtering criteria, and an Argument [taxonomy term ID] in order to re-use the same View in all these articles, without the overhead of creating and maintaining a separate View for each taxonomy term.

Let's say article 'node/2' was about taxonomy term 3, and the re-usable view [ID=1] was called 'myview'. The snippet pasted to article 'node/2' is then: <?php print views_embed_view(1, 'default', 3); ?>. It shows nicely in the article, but once the user tries to filter the list using Exposed filter, he is sent from 'node/2' to 'myview/3?filter_values_here...', so he is facing the filtered list alone. The article 'node/2' vanished from his screen.

Since there's currently no way to pass a path override through views_embed_view(), we'll break it into pieces, and paste to 'node/2':

<?php  $view = views_get_view(1);
if ($view) {
$view->override_path = 'node/2';
print $view->preview('default', array(3));
} ?>

Now, if the user submits exposed filter, he is sent from 'node/2' to 'node/2/3?filter_values_here...'. The View is still embedded in the article, but URL got changed. You see - the argument value (3) is hardcoded in the snippet, and doesn't appear anywhere in the URL. Still, Views append it to the path, creating something weird. (Coincidentally, I had a comment #3 somewhere else on the site, and now it suddenly shows under the article 'node/2' where it shouldn't be.)

If I was passing the node ID that's in the URL already (i.e. '2' for 'node/2'), I can write $view->override_path = 'node/%';, and let Views to replace '%' with whatever I passed as argument, but in this example I'm passing an arbitrary value there's no place for in the URL. Unsolvable problem.

------------------------------

Proposed fix:
The attached patch makes two tiny changes:

- views_embed_view() pass the current path (from $_GET['q']) as an override, to ensure that embedded View always send the user back to the same page on filter submits. I know that #4 mentions edge cases, where $_GET['q'] might be inappropriate, but views_embed_view() is supposed to be the simplest solution for snippets, with not many options, right? This makes it work as expected. Note that the second fix (below) is needed for this to work well.

- If a path override is present, the arguments are only inserted to the path in place of placeholders. With no override (i.e. the native path of the view used), nothing changes, and the arguments get appended, as this is how the native Views' paths work. But the presence of path_override indicates, that the caller code took over the path which is therefore external and unknown-format to views.
While it's callers business to provide argument values for the view through function call arguments on embed, we can't know where and how he got the values from. If he decoded them from URL somehow, it's also his business to handle the reverse process, by indicating argument positions in path override using placeholders. If he got the values in some different way (like hardcoded value in the example above), we shouldn't touch the override path provided (we can't make assumptions about the embedding page behavior regarding path format/arguments).

It boils down to:
view_path/% --> view_path/arg_value
view_path --> view_path/arg_value
override_path/% --> override_path/arg_value
override_path --> override_path

I would swear I changed the status, but apparently I didn't :-O

I'll stick with overrides and workarounds then ;-) Just wanted to help improving this module, where the embedding stuff seemed flawed to me (I was really unable to imagine, what might be the other use cases you mention), but now this issue evolved to areas where I'm not much of a help. So be the use case recorded here for future reference, and I'm moving to more useful work.

Have a nice day.

This is sad, but what can I do... It smells like a misunderstanding - the maintainer wrote (#18):

I disagree that it is not desirable for a views exposed filter to go back to the actual path of the view. In fact, I very much consider it the exception that you might not want to go back to the view path.

This patch attempted to do exactly the same, i.e. avoid exposed filters going somewhere else. The misunderstanding, as I see it, is in the fact, that the "actual path of the view" is in fact the page embedding the view (in the case of embeds), not the page of the view alone (which is different from what the user normally see, incomplete in the case that view is intended to be just a subpart of something). I might even suggest to remove the page of the view alone, which is duplicate and broken in context of a view created for the sole purpose of embedding somewhere else.

I see no solution in the situation, where the only use case for a feature (that I can imagine), is broken, but still maintainer calls it edge case and just an exception not worth to be considered. There's no work I can do on the patch, except throw it to recycle bin, or reroll and ask for it to be reconsidered (which I already did enough times). Our opinions are obviously somehow incompatible... I can't do anything about that. So this is the end, I suppose, there's no point to argue.