Wrong form action URL for exposed filters of content pane view displays using contextual filters

Analog problem here : arguments not received by Content-pane in PM. Searching for 1 week...
And in fact I'm rebuilding the strict identical website to
http://nodeone.se/blogg/learn-page-manager-screencast-series-summed-up
and following up, step by step in order to check out this matter.
My first try (building factboxes related to an article with Content-Pane ep. 5,6 in this Serie) and failure, led me to a strange bug around Node Reference that stopped me going further.
http://drupal.org/node/1284752

Such an assumption shouldn't be hardcoded into view.inc
View.inc shouldn't know of any plugin types.

This just nailed Earl and myself while working on a project together. ;) #2 can't work. I'll see if Earl has any bright ideas on the cleanest way to fix this.

Hi all,
I agree that the view.inc shouldn't be concerned with the plugin type itself.
But that doesn't help us solve the issue.
I think that the display handler (views_plugin_display) should provide its own function of get_url that will basically return $this->view->get_url();
Then in the views_content_plugin_display_panel_pane we can overwrite this function and if it is selected to use panel_path ($this->get_option('inherit_panels_path')) then we can return it instead of the view url.
This will require another change though in the function "views_exposed_form" the will use $view->display_handler->get_url() for the form action instead of the $view->get_url().
Will try to provide a patch later on but just wanna see your thoughts about this.

Here are the 2 promised patches.
Unfortunately this cannot happen without patching ctools as well.

+++ views.module	(working copy)
@@ -1890,7 +1890,8 @@
+  //$form['#action'] = url($view->get_url());

Please don't comment out old code, better remove it.

@dww did you and Earl find a solution? Nonetheless #7 needs review.

Update status based on my last feedback.

At least the views part looks pretty fine for me, the ctools part as well.

I have attached patches with the code from #7 minus the commented out code and with the addition of white space between if and ( in the ctools patch. Do I need to create an issue in the ctools queue as well?

Most displays don't have a get_url() function, but all of them have a get_path() function. I'm not entirely sure of the difference, but using get_path instead of get_url also fixes this issues, and doesn't require a ctools patch.

I would suggest to move this issue first to ctools and commit it there.

Once that is done you can patch views, as views have to depend on a current stable release on views.

So this process might take some time.

In my latest comment / patch I mentioned that a ctools patch may not be required. Moving back to views queue unless there is a problem with that method in #12, which there may well be.

Hi,
most displays are supposed to extend views_plugin_display so they should have get_url() as it is part of the patch.
If you look closely to the get_url() function in the /includes/views.inc file of the views module you will see that it does a bit more things then to just return the path. So if you decide not to use the get_url function for the form action then you might end up with broken urls.

The simple example to simulate is :
create simple view with path like : test/%
expect the % will be term to filter on and set the view
add some exposed filter (like node type or anything that will filter the results)
then open test/12 (where 12 should be replaced with appropriate id from your terms)
if you do not use get_url function for the exposed form the action of the form will be test/% instead of the expected test/12.
So yes , the get_url must be used and get_path will cause problems.
Unfortunately this change requires patches in both modules but I have not come to a better solution yet.

Moving to CTools issue queue for review of patch in #11.

patch in #11 worked for me. Looked for hours for an answer so very happy. Was rather tough to find this issue, after stumbling into the problem on several occasions. Maybe there should be duplicate issues in affected modules, referenced back, to make it easier to find?

Correction, I did have issues with patch #11. Page based views with exposed filters don't work due to missing method in a views object. Occurred for me while running commerce module which makes extensive use of page based views with exposed filters. Also tried patch number #12 but as vflirt suggested this caused issues with pages with embedded arguments. In the end I did as in the attached patch. I know it's a quick and dirty solution but it works for the present without ctools patch required. Sorry but a more correct solution will require a rethink and someone with more knowledge of the workings of these two modules than me.

Hi , try the patches from #7 , i see that patches in #11 missed the changes in plugins/views_plugin_display.inc in the views and that is why you will have problems with standard displays.

thanks vflirt, well spotted. Will give it a go when I get the chance. Rushing to get my current project live, will try shortly after that.

Resuming this issue:

The patches from #7 are working, but views.patch.txt needs to be fixed as mentioned in #8, right?

I re-created these as -p1 patches.

Am'd and pushed the CTools patch. Sending back to Views.

Committed as well, thanks!

I don't know if this is the same issue, but it happened yesterday when I upgraded to dev in order to generate a patch.
My arguments in the menu path stopped connecting to the views argument. Here's why.
$router_item['page arguments'] = array(0 => viewname, 1 => displayname, 2 => first_arg);
then in views_page()
unset($args[0], $args[1]);
leaving $args = array(2 => first_arg)
Then in views.inc _build_arguments, we iterate through the arguments using $position, starting at 0
$args[$position] fails to find the first arg

There are still issues for block with contextual filters included with drupal context( not panels). See my use case and path request http://drupal.org/node/1359594#comment-6124866

Also related, embedded views on node paths with exposed filters: http://drupal.org/node/1269794#comment-6139256