Support admin overlay in exposed forms

views_preprocess is probably too late to override the path. You would have to use something like hook_views_pre_render.

I just played with this a bit, and the admin path stuff is a red herring. Any view at admin/* is already automatically admin path. My gut feeling is that overlay has a bug.

A method=get form can't work inside the overlay unless overlay takes over its submit event. Otherwise the browser will go straight to the non-overlay version of the URL. I'm attaching a patch that intercepts the submit event of method=get forms inside the overlay and redirects them to an overlay-friendly version of the URL they're trying to submit to.

Certainly it's a backport candidate after it gets committed to D8.

Forms submitted with a GET method are basically links. As a consequence, we should use the same logic for them as Drupal.overlay.eventhandlerOverrideLink. The code there will probably have to be refactored to allow that.

This basically is a big UI problem for all exposed filters in "admin" views (when using the overlay), so I've tested the existing patch as well. Works like a charm. I did not look into optimization, code refactoring possibilities as outlined by Damien though, just saying the existing patch works well.

tag

Patch in #4 works great, except that it breaks the Reset button if applied to an exposed filter. The filter itself is working fine, but a Reset click does not actually reset the exposed filters. When I revert the patch, the reset functionality works again.

Patch from #4 appears to work for me against core-7.14 and views-7.x-3.3

I can confirm that #4 works except the reset button how it is described in #11.

Marked #1630692: Exposed filter kills Overlay on My Drafts tab as duplicate.

Marked #1399894: Submitting an exposed filter in overlay, closes the overlay as a duplicate.

Duplicate #1788888: Overlay at admin/modules closes on submitting the form.?

The reason the "Reset" button does not work is because the patch from #4 prevents the form from submitting. Instead, the update serializes the form fields and redirects the browser to the path of the form action (the path of your view) with serialized form field data as arguments in the URL. Serializing a form does not include submit button arguments so the name/value of the submit button clicked or the name/value of the form's default submit button is not passed as arguments in the serialized form data. The default submit button for the exposed filter form does not have a name so not passing the name/value via the serialized form data is not a problem if only the default submit button is used. However, the reset button does have a name and value which are needed by views to reset the form.

The patch from #4 is not the right solution. We should find a solution that allows the form to submit.

There are a couple issues we have to deal with. The argument render=overlay is automatically appended to the form's action by Drupal.overlayChild.behaviors.parseForms() in modules/overlay/overlay-child.js which helps to retain the overlay when the form is submitted. However, since the form's method is "get" any arguments passed view the form's action are overwritten by the form's fields so render=overlay is not passed as an argument like it would if the form's method were "post". One option may be to update parseForms() to append a hidden form field named "render" with the value "overlay" to the start or end of the exposed filter <form> instead of updating the form's action. I've tested this option and it addresses the issue. It's a bit of a hack but unless exposed forms can be submitted using "post" method, I'm not sure of a better solution.

Please provide input.

In attempting to validate this per officehours task (http://core.drupalofficehours.org/task/2046), we confirmed that the patch above (overlay-modules-form-submit-1788888-14.patch) DOES NOT fix admin views with exposed filters in overlay (http://drupal.org/node/1116326)

Assisted by: pixlkat

Steps Taken:

1. Applied patch to create admin/people/list view. Note: we had to apply the patch BEFORE running install.php on local environment.
2. Confirmed that overlay disappears on 8.0-alpha1. When module is selected and submitted, or filter run on admin/people/list, '#overlay=' disappears from url.
3. Applied patch above. Confirmed that:
   • Patch fixes overlay problem on: /#overlay=admin/modules.
   • Patch does not fix overlay problem on: /#overlay=admin/people/list or /#overlay=admin/people/whatever (made new page to test).

Note that this is becoming a much bigger problem with admin/content being a view with exposed filters. Not sure about elevating to major but thought about it :)

I guess the solution suggested by AHOY in #18 is a bit hacky but it's working also for the reset button and i think a hidden element rendered only in overlays doesn't break anything. So here's a patch that solved that issue for D8.

If this will be commited i will of course provide a patch for views in D7 as well.

+++ b/core/modules/views/views.moduleundefined
@@ -1416,6 +1416,16 @@ function views_exposed_form($form, &$form_state) {
+  if (!empty($_GET['render']) && $_GET['render'] == 'overlay') {

We should use the request object instead of $_GET

Changed that the condition checks to use $_REQUEST

This is what a actually meant.

Added a comma after #value => 'overlay' and trimmed the comments.

Thank you. I would RTBC it, if I have a clue about the overlay.

Oh, it seems like there is no ?render=overlay anymore? :/

Dawehner's solution doesn't proposed in #25 doesn't work. The return value of the request object for the get parameter "render" is empty. The solution of the patch in #22 still works well, needs a reroll though.

Anyway, no matter what solution that is just adding a hidden field, all this is just a workaround, and other forms in overlays will still drop out of the overlay once they are submitted. The actual bug lies in the overlay module itself.

However since i tested it already i will add the reroll for the solution of #22 again.

Well, you should not use $_GET anymore in Drupal 8, just saying.

@dawehner well i'm not so experienced with the d8 API and so your first comment in #23 wasn't really helpful for me. Your comment in #30 is ok, but if you take the time to write that comment you could maybe also add an explanation on why it is like that or at least reference to some source. There are people out there that have only little or no experience with d8 API ;)

However, i found looked at the first patch in this issue again and since the only problem with it was the dropping out of the overlay on pressing the reset button, i tried to fix that. Here's what i came up with.

Found some coding standards related issues.

+++ b/core/modules/overlay/overlay-child.jsundefined
@@ -120,6 +120,29 @@ Drupal.overlayChild.behaviors.parseForms = function (context, settings) {
+    if ($(this).attr('method') === 'get') {

Why you are using '===' and later only '=='?

+++ b/core/modules/overlay/overlay-child.jsundefined
@@ -120,6 +120,29 @@ Drupal.overlayChild.behaviors.parseForms = function (context, settings) {
+      $('.views-reset-button input').removeAttr("onclick");

Why you are using double quotes?

+++ b/core/modules/overlay/overlay-child.jsundefined
@@ -120,6 +120,29 @@ Drupal.overlayChild.behaviors.parseForms = function (context, settings) {
+          if (this.type=='text' || this.type=='select-multiple' || this.type=='select') {

We need spaces before and after the '=='.

+++ b/core/modules/overlay/overlay-child.jsundefined
@@ -120,6 +120,29 @@ Drupal.overlayChild.behaviors.parseForms = function (context, settings) {
+            this.setAttribute('value','');

A space after the comma would also be great.

+++ b/core/modules/overlay/overlay-child.jsundefined
@@ -130,6 +153,16 @@ Drupal.overlayChild.behaviors.parseForms = function (context, settings) {
+    var newHref = $form.attr('action') + "&" + $form.formSerialize();

Single quotes please.

rerolled with fixes requested as per #34

Looks good to me

Works fine, tested it with the file overview.

#35: vdc-d8-1116326-35.patch queued for re-testing.

Assigning to nod_ for a js review

This is a views issue, overlay provides a way of adding behaviors to the child frame without messing with overlay javascript.

• I moved all the code to the views module.
• File did not pass jshint validation because of "==" instead of "===".
• moved some things around, renamed variables that should be named an so on.
• .once()-ed the whole thing.
• The input type "select-multiple" doesn't exist in HTML so I got rid of it. But maybe it's used somewhere i don't know?

This patch made me learn that views would add a hardcoded onclick attribute, not cool. I haven't seen it though so I don't know if it's actually required. Can you point out to me when that attribute would get added (so that I can get rid of it)?

Other than that I'm happy with it now.

with the patch now…

This patch made me learn that views would add a hardcoded onclick attribute, not cool. I haven't seen it though so I don't know if it's actually required. Can you point out to me when that attribute would get added (so that I can get rid of it)?

core/modules/views_ui/lib/Drupal/views_ui/Form/Ajax/Rearrange.php

In the UI add a new view, add some fields and click on the dropbutton to select "rearrange".

I have a similar problem that only occurs in Internet Explorer 10. I have added the patch https://drupal.org/node/1116326#comment-7679599 and when I submit a form in admin overlay using Internet Explorer 10 the host is set to admin.
Fiddler says:
Result: 502
Protocol: HTTP
Host: admin
URL: /admin/pegasus/dashboard/drafts?title=&type=All&state_1=draft&uid=&field_section_tid=All&render=overlay

@nod_
Which steps are required to get this patch RTBC?

Overlay is dead to D8 #2088121: Remove Overlay.

I think you meant to close this instead?

If not, sorry in advance! :)

Applies to views in 7.x no?

Yes, sorry. I somehow didn't see this had been moved back to 7.x - thanks!

Looks like this is back to being about a bug in Drupal 7 core now?

Seems like this should go into overlay module itself as a form_alter or maybe Form API?

Here's a generic overlay module patch - seems you need to use $_REQUEST instead of $_GET to detect this.

Checked using the maillog module's View with an exposed filter.

Looks good to me.

Given that this is modifying a potentially large number of forms, I think it would be good to check that $form['render'] doesn't already exist in the form before writing it.

If it does ever exist, it's better for this bug to keep occurring on that particular form than to clobber whatever else is there.

Quick reroll fixing that, as well as a few small code style issues.

Working great for me.

#56 work fine for us.

I can also confirm that the patch works like a charm. Thanks! Please commit to next release.

This is good to go. Marked for commit!

Committed to 7.x - thanks!