Edit link destination incorrect when using AJAX-enabled views [#1036962]

Comment	File	Size	Author
#71	views-ajax-nginx-1036962-71.patch	490 bytes	dsnopek
#65	1036962-views-ajax-destination-65.patch	1.02 KB	wiifm
#29	views-fix-destination-link-for-ajax-1036962-29.patch	747 bytes	grahamc
#26	views-fix-destiantion-link-for-ajax-1036962-26.patch	761 bytes	mr.york
#23	views-fix-destiantion-link-for-ajax-1036962-23.patch	1.27 KB	acbramley
#11	views-fix-destiantion-link-for-ajax-1036962-11.patch	1.22 KB	das-peter

Comment #2

dawehner

German

commented 23 January 2011 at 10:35

In theory the field handler would have to use something like $view->get_path() instead of drupal_get_destination().

I'm not sure whether this might open other bugs.

Log in or register to post comments

Comment #3

Anonymous (not verified) commented 2 February 2011 at 21:23

I'm having the same issue with 6.x-2.12. I've created a dashboard of sorts for admin's to keep on top of new content, and have several views in quicktabs. All the views are ajax enabled for nice pagination, but the link to edit the view sets the destination to views/ajax. When the user's use the link to edit a node, after hitting save they just get some json content on a blank screen.

Log in or register to post comments

Comment #4

dawehner

German

commented 3 February 2011 at 05:58

Perhaps this patch helps you: http://drupal.org/node/956186 but it was created based on a views issue.

Log in or register to post comments

Comment #5

iamjon commented 9 May 2011 at 12:15

Status:

Active

» Closed (works as designed)

Closing from a lack of activity.

Log in or register to post comments

Comment #6

apmsooner commented 9 September 2011 at 16:54

Status:

Closed (works as designed)

» Active

I'm reopening this issue because it persists and can't imagine works as designed. The edit path for ajax enabled view is: destination=views/ajax which makes page try to open an ajax file upon saving the record. Was there some sort of patch for this or a fix in the dev version?

Log in or register to post comments

Comment #7

dawehner

German

commented 9 September 2011 at 23:26

Does someone know whether there is an easy way to get the original url in an ajax request?

Log in or register to post comments

Comment #8

geerlingguy commented 19 September 2011 at 19:42

Subscribe, and to dereine, I'm not sure. This bug only affects one admin facing page on my site, so it's not a huge issue for me, but it would be fine with me if no destination was set at all, for my purposes.

Log in or register to post comments

Comment #9

josebrito commented 28 September 2011 at 12:00

I subscribe this post because I have the same problem.
I'd like to know how to get the original url to rewrite the "Edit" link.

Log in or register to post comments

Comment #10

Toongenius commented 25 October 2011 at 05:47

Same issue. Subscribing

Log in or register to post comments

Comment #11

das-peter commented 27 November 2011 at 13:34

Status:	Active	» Needs review
Issue tags:		+dvcs11

Status	File	Size
new	views-fix-destiantion-link-for-ajax-1036962-11.patch	1.22 KB

Same issue here - it's somewhat annoying if you use admin_views and saving a node sends you an ajax output :D
The idea I've had was to ensure drupal_get_destination() sends an appropriate destination. To do so I inject a custom value into the static cache of the function in views_ajax().
I'm not sure if this approach has nasty side-effects - at least it seems to work in my vbo case.

Log in or register to post comments

Comment #12

dawehner

German

commented 9 December 2011 at 07:58

Version:	7.x-3.x-dev	» 6.x-3.x-dev
Status:	Needs review	» Patch (to be ported)

This patch looks fine. Committed to 7.x-3.x and maybe needs a backport

Log in or register to post comments

Comment #13

das-peter commented 9 December 2011 at 08:03

Awesome thanks!

Log in or register to post comments

Comment #14

timofey commented 19 April 2012 at 03:20

Version:

6.x-3.x-dev

» 7.x-3.3

I am still having the same issue.

After using Ajax to sort columns, my links look like this:

http://mysite.com/node/555/edit?destination=content/aaa?order=field_min_cat_reference&sort=desc&SESS15903623b6f15e5251aa23535a3369d6=yO6Kgjdk8GIIO0OIsiiQe_N3ZCXmIBVpvKDGssmSXy8&SESSc8bs72943bc0ace60394d2d2804f4a26=1f7203034b2633804c07f7d8e73fe9a4&SESSbdfda35783e20c59510c085ddefb0784=64bd7a46f1185ca928f14431sebcdad5&__unam=3cb9d7a-12680c96942-342d3fd5-166&Drupal_tableDrag_showWeight=0&__utma=233812797.1535232275.1312595099.1534629601.1334834372.15&__utmb=331862797.1.10.1344804372&__utmc=233862797&__utmz=231862797.1334055455.8.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not provided)&__utmv=231132797.authenticated user,Moderate Front SlideShow,Moderate Foot Banner,Moderate Videos,Moderate Upcoming Events&has_js=1

destination should end at "content/aaa"

I'm using the 7.x-3.3 (2012-Feb-22 release). I can also see that it's patched with #11.... but it's not working.

Log in or register to post comments

Comment #15

dawehner

German

commented 21 April 2012 at 22:50

Version:

7.x-3.3

» 6.x-3.x-dev

Let's move the issue back as your comment is quite unrelated.

You seems to have enabled session ID via URL, i'm pretty sure this a wrong server configuration.
Additional this issue is only about edit links of nodes...

Log in or register to post comments

Comment #16

ddrozdik commented 5 July 2012 at 07:49

Same issue happens when I use filters(views 7.x-3.3).
Link looks as
http://mysite.com/node/1073/edit?destination=admin/dashboard/content%3Fq%3Dviews/ajax%26nid%3D%26type%5B0%5D%3Dnews%26title%3D%26status%3D0%26premium%3DAll%26uid%3D%26date_filter%5Bmin%5D%5Bdate%5D%3D%26date_filter%5Bmax%5D%5Bdate%5D%3D

On my local machine works fine but on dev server doesn't work.(strange)

Log in or register to post comments

Comment #17

ddrozdik commented 17 July 2012 at 08:52

Problem was in config of ngnix, need to correct configure mod_rewrite for sites on drupal 7, because they have some differences from drupal 6.

Log in or register to post comments

Comment #18

dazz commented 13 August 2012 at 09:56

and what is this correct configuration?

Log in or register to post comments

Comment #19

acbramley commented 28 August 2012 at 04:10

Getting this problem too on Views 7.x-3.3 with an admin page of users with exposed filters and edit links. After clicking the edit link on a filtered page, editing a user, and clicking save, I'm redirected to /views/ajax?field_user_fname_value=Adam&field_user_lname_value=&status=All&rid=All&field_access_control_tid=All

Log in or register to post comments

Comment #20

mojiro commented 7 September 2012 at 07:41

I also use nginx. Could you please post your new configuration ?

Log in or register to post comments

Comment #21

mustanggb commented 18 September 2012 at 14:29

Version:	6.x-3.x-dev	» 7.x-3.x-dev
Component:	table style	» Code
Status:	Patch (to be ported)	» Needs work

Changing #11 to following fixed it for me (CNW because I haven't rolled a patch):

// Overwrite the destination.
// @see drupal_get_destination()
$origin_destination = $path;
$query = $_REQUEST;
unset($query['q']);
$query_string = drupal_http_build_query($query);
if ($query_string != '') {
  $origin_destination .= '?' . $query_string;
}
$destination = &drupal_static('drupal_get_destination');
$destination = array('destination' => $origin_destination);

Log in or register to post comments

Comment #22

acbramley commented 18 September 2012 at 23:41

#11 didn't fix the issue for me, #21 did though :) thanks a lot

Log in or register to post comments

Comment #23

acbramley commented 18 September 2012 at 23:48

Status	File	Size
new	views-fix-destiantion-link-for-ajax-1036962-23.patch	1.27 KB

Here's a patch rolled off 7.x-3.x from the changes in #21

Log in or register to post comments

Comment #24

acbramley commented 18 September 2012 at 23:49

Ah the problem here is though when you return to the destination with the query parameters, ajax filtering/sorting etc no longer works

Log in or register to post comments

Comment #25

grahamc

Oxford, UK

commented 29 October 2012 at 11:39

The filtering isn't working because the $_GET += $_POST;
line does not overwrite existing keys in $_GET with the new $_POST values.

~~Change that to $_GET = array_merge($_GET, $_POST); and it works again.~~

edit: Oh, nevermind, that's already fixed if you're using the current release of Views.

(I'm wondering whether query parameters should even be necessary if the user has an active $_SESSION...? - Views saves/loads status of the filters there anyway.)

Log in or register to post comments

Comment #26

mr.york commented 29 October 2012 at 14:13

Status	File	Size
new	views-fix-destiantion-link-for-ajax-1036962-26.patch	761 bytes

The filtering isn't working because the $_GET += $_POST;
I removed this modification.

Log in or register to post comments

Comment #27

mr.york commented 29 October 2012 at 14:14

Status:

Needs work

» Needs review

Log in or register to post comments

Comment #28

29 October 2012 at 14:16

Status:

Needs review

» Needs work

The last submitted patch, views-fix-destiantion-link-for-ajax-1036962-26.patch, failed testing.

Log in or register to post comments

Comment #29

grahamc

Oxford, UK

commented 29 October 2012 at 22:35

Status:

Needs work

» Needs review

Status	File	Size
new	views-fix-destination-link-for-ajax-1036962-29.patch	747 bytes

So, _another_ attempt at creating a patch from #21 then...

Log in or register to post comments

Comment #30

Funksmaname commented 3 January 2013 at 23:42

Thank you! This patch seems to have fixed the nasty error I was getting in views with ajax enabled...

Log in or register to post comments

Comment #31

seanbfuller commented 20 January 2013 at 20:02

This patch worked great to fix the critical issue for us of hitting the ajax page after editing a node. We did find one minor nit that came out of it, however: If you are paginated in beyond the first page of results, you get a page=x argument in the url when you come back after editing. This makes it impossible to get to back to the first page using the pager. Looks like this is because the url value overrides the non-existent value in the pagination link.

Steps to reproduce:

Create a view of nodes with ajax pagination that has a few pages of results.
Paginate to the third page of results.
Click edit (either from an edit link or contextual links) one an item to go to the node edit page.
Save the node and you should come back to the view page, on that same result page. Notice that you should have a page=2 in the url.
Try to go to the first page of results and you'll just keep reloading the third page of results. If you paginate to any other page, it works.

Again, I'm not sure that this minor item is worth holding up the larger fix. This also might be more of an issue with pagination. A "page=0" parameter on the link would fix this. Not sure if that's worth splitting out to a new issue. Beyond that, the patch worked and fixed the critical issue so thanks.

Log in or register to post comments

Comment #32

mstef commented 29 January 2013 at 21:38

Patch #23&29 do not resolve the issue for me.

This is the link to the edit form after submitting the filter via AJAX: http://localhost/node/23/edit?destination=admin/workbench/content/my%3Ft...

After submitting, I'm redirected to: http://localhost/admin/workbench/content/my?title=6timestamp%5Bmin%5D%3D...

Which is incorrect because now title=(the entire remaining URL), so it all gets sent into the title filter.

Log in or register to post comments

Comment #33

mstef commented 29 January 2013 at 21:43

Status:

Needs review

» Needs work

Perhaps that's a separate issue entirely?

Log in or register to post comments

Comment #34

mstef commented 29 January 2013 at 21:57

Status:

Needs work

» Needs review

Sorry, it appears my bug is unrelated. Forgot what I said..

Log in or register to post comments

Comment #35

mxwright commented 4 March 2013 at 17:33

Thanks! This seems to fix a long-outstanding issue for us.

Log in or register to post comments

Comment #36

rogerrogers commented 19 March 2013 at 21:42

Just wanted to chime in that this patch works for us. We have had to use on multiple sites. Will this get included in the main branch?

Log in or register to post comments

Comment #37

john bickar commented 11 April 2013 at 18:23

Status:

Needs review

» Reviewed & tested by the community

Tested the patch in #29 and it resolves the issue for me.

Log in or register to post comments

Comment #38

jlporter commented 10 June 2013 at 17:27

#29 fixed our issue which was in the views_admin module, applied to 3.7 cleanly with a patch -p1 (got something weird with p0).

related admin_views issue that was fixed by this patch: https://drupal.org/node/1650420

Log in or register to post comments

Comment #39

merilainen commented 13 June 2013 at 09:53

#29 worked for us also, not using views_admin. Experienced it only on our development server, which is Nginx. Local apache environments didn't have any problems. I know, they should be identical, but life is life :)

Log in or register to post comments

Comment #40

westie commented 13 June 2013 at 14:51

#29 worked for me, again on nginx. Please can this be committed?

Log in or register to post comments

Comment #41

torpy commented 10 September 2013 at 05:14

Chiming in with another "it works for me!", this time on IIS 7.5 and IIS 8.

Log in or register to post comments

Comment #42

moonray commented 25 November 2013 at 14:30

#29 worked to fix the problem on Pantheon (nginx server).
Like #39 said, local apache based environment isn't affected by this bug.

#31 indicated there is still a small problem that needs to be solved, but we should probably try to fix that in a follow-up patch since the critical issue is solved by the patch in #29.

Log in or register to post comments

Comment #43

mustanggb commented 28 November 2013 at 10:42

Priority:	Normal	» Major
Issue summary:	View changes

Although I'm the original "patch" creator I recently applied this to a new site and it's still working fine.

Bumping to major for a bit of attention and it's quite an important fix for people using the AJAX feature.

Log in or register to post comments

Comment #44

dawehner

German

commented 21 December 2013 at 08:24

It would be great to merge some of the comments and move this to the issue summary. This helps people to understand what is going on.
One requirement about the patch: Could we add some comment why we exactly need to unset $query['q']?

Log in or register to post comments

Comment #45

enzipher commented 16 January 2014 at 20:28

Does the issue mentioned in #31 get any love here? If not it would be better to put that one as a separate issue.

Log in or register to post comments

Comment #46

seanr

he/him

commented 12 March 2014 at 17:06

I agree with #45 - please at least get this into views since it's working for folks, then we can address that one separately (unless someone's got a patch that fixes #31 now too).

Log in or register to post comments

Comment #47

CLEE25 commented 11 April 2014 at 21:31

Add me to the group of people who finally found a fix with #29. This was a problem across many sites, and was incredibly annoying since it never seemed to happen all the time. Only when I was demo-ing for clients.

#29 fixed it like a dream.

Log in or register to post comments

Comment #48

arosboro commented 5 May 2014 at 15:52

Can anyone else confirm that patch 29 does not introduce issues with bulk operations? I am finding that when I try to delete multiple pieces of content that the page just refreshes with no action taken.

Log in or register to post comments

Comment #49

arosboro commented 5 May 2014 at 17:44

I did some more testing. Caching was enabled which was causing the problems that I experienced. That is "works as designed" as far as I am concerned. I believe #29 successfully remedies 'views/ajax' being included in the destination parameter.

Log in or register to post comments

Comment #50

gmclelland commented 11 June 2014 at 21:52

The patch in #29 worked for me. In my case after I clicked the "Edit" link at admin/content/file and then edited and saved the file, I would be shown a bunch of json.

After patching with #29 on the latest Views module, editing files works as expected.

Log in or register to post comments

Comment #51

mustanggb commented 17 June 2014 at 11:24

Any chance to get this committed?

Log in or register to post comments

Comment #52

aaronbauman

he/him

commented 18 June 2014 at 19:10

#29 RTBC++

Log in or register to post comments

Comment #53

jdcollier commented 8 July 2014 at 19:30

Impertinent question ...

It seems this isn't in the dev or stable branches still. Is this due to a [very] understandable workload issue on the dev team, or is there a concern with this patch that I'm not seeing?

Every time I install this patch, then a Views security update comes out and wipes it out :(

I appreciate the work ... I'm honestly wondering if I'm missing something on this one.

Thank you so much!

JD

Log in or register to post comments

Comment #54

davej commented 14 July 2014 at 15:59

#29 resolved the problem here, with Views 7.x-3.8 under nginx.

Without the patch, the edit link URL from Views URL /group was:
/node/672/edit?destination=og%3Fq%3Dviews/ajax%26field_group_type_value%3DAll%26page%3D1
which, after saving the node, resolved to:
/views/ajax?field_group_type_value=All&page=1
which presented the user with some JSON.

With the patch, the edit link URL from Views URL /group is:
/node/672/edit?destination=og%3Ffield_group_type_value%3DAll%26page%3D1
which, after saving the node, resolved to:
/group?field_group_type_value=All&page=1

I agree with #31 that there is an issue with pagination after returning from the edit, also agree that this is a minor issue compared to the main issue.

Cheers,

Dave

Log in or register to post comments

Comment #55

djschoone commented 26 August 2014 at 09:49

#29 works for me too! Thnx.

Log in or register to post comments

Comment #56

westberliner commented 30 August 2014 at 22:11

Got an similar Issue with admin_views and nginx. #29 solved this.

Log in or register to post comments

Comment #57

dafeder

he/him

Philadelphia, PA

commented 3 September 2014 at 10:13

#29 worked for me on pantheon. Commit it!

Log in or register to post comments

Comment #58

lukus

he/him

commented 17 September 2014 at 13:11

This is working for me also.

Any idea when this will be committed?

Thanks

L

Log in or register to post comments

Comment #59

jkingsnorth commented 2 October 2014 at 23:12

Duplicate issue here: #2188829: Error when creating new user if the user listing has more then one page - the RTBC patch in #29 also fixes that, so it would be great to get this in Views as it is obviously still a problem!

Log in or register to post comments

Comment #60

jkingsnorth commented 2 October 2014 at 23:15

The 'broken pager' issue described in #31 and since is actually a separate issue that is being worked on here: #1786524: AJAX pager does not work if page number set in URL - so I don't think it should impede the progress of this patch.

Log in or register to post comments

Comment #61

labboy0276 commented 3 October 2014 at 12:36

Thank You, I can confirm #29 works as well. This problem has been around for so long, I just became accustomed to it....

Log in or register to post comments

Comment #62

parisek

Czech

commented 7 October 2014 at 09:28

I can confirm too that #29 patch worked and problem solved. Patch is ready for 2 years why is not committed?

Log in or register to post comments

Comment #63

16 October 2014 at 03:26

xurizaemon queued 29: views-fix-destination-link-for-ajax-1036962-29.patch for re-testing.

Log in or register to post comments

Comment #64

wiifm

English

Wellington, NZ

commented 16 October 2014 at 22:17

So this is a major issue, and it is effecting a major module in admin_views (with 54k installs and counting).

Steps to reproduce:

Install admin_views
Visit /admin/content
Sort a column (uses AJAX)
Click 'edit' on any piece of content
Click 'save'

Expected behavior:

Returned to the content admin screen with the sort maintained, and a message saying 'saved'

Actual behavior:

Sent instead to /views/ajax/and JSON is presented on the screen confusing all content authors.

Example edit link (before patch):

Note the q=views/ajax in the destination:

/node/19/edit?destination=admin/content%3Fq%3Dviews/ajax%26type%3Dtlms_partner%26status%3DAll%26vid%3DAll%26order%3Dtitle%26sort%3Dasc

Example edit link (after patch):

/node/19/edit?destination=admin/content%3Ftype%3Dtlms_partner%26status%3DAll%26vid%3DAll%26order%3Dtitle%26sort%3Dasc

Patch at #29 fixes this (running against views 3.x), and looks like it has for everyone else here. Intrigued as to why this has not got the maintainers attention by now?

RTBC +1

Log in or register to post comments

Comment #65

wiifm

English

Wellington, NZ

commented 16 October 2014 at 22:28

Status:

Reviewed & tested by the community

» Needs review

Status	File	Size
new	1036962-views-ajax-destination-65.patch	1.02 KB

4 files were hidden/shown/deleted

Status	File	Size
hidden	views-fix-destiantion-link-for-ajax-1036962-11.patch	1.22 KB
hidden	views-fix-destiantion-link-for-ajax-1036962-23.patch	1.27 KB
hidden	views-fix-destiantion-link-for-ajax-1036962-26.patch	761 bytes
hidden	views-fix-destination-link-for-ajax-1036962-29.patch	747 bytes

Had a discussion with @dawehner on IRC, Daniel suggested to improve the documentation of the patch as to why it is actively unsetting $_GET['q'].

Attached is a new patch that does this (no code changes).

Log in or register to post comments

Comment #66

ChrisFlink commented 28 October 2014 at 08:19

Status:

Needs review

» Reviewed & tested by the community

Tested the latest patch by wiifm on the latest dev version of views. Comment makes sense. Patch seems to work fine and the issue when json is displayed instead of a page is gone. Since the last change to the patch only updated the comment and patch in #29 was successfully tested too, I'd say commit asap because this is a major issue with a solution laying around for over two years.

Log in or register to post comments

Comment #67

acbramley commented 5 November 2014 at 00:48

Confirming this only seems to be an issue on Nginx configurations, using a local apache instance I couldn't reproduce the problem but could on our staging site running on nginx. After applying the patch the issue was fixed!

Log in or register to post comments

Comment #68

fabianx commented 12 December 2014 at 14:28

Status:

Reviewed & tested by the community

» Needs work

+++ b/includes/ajax.inc
@@ -50,12 +50,17 @@ function views_ajax() {
-        $origin_destination .= '?' . $query;
+      $query = $_REQUEST;
+      unset($query['q']);

Why are we using $_REQUEST when just above we set $_GET to be $_POST and $_GET.

If we want the original vars without what was posted, we need to save the var before the

$_GET = $_GET + $_POST

If we want the combination of $_GET and $_POST, we can directly use $_GET in the first place as we just combined them ourselves.

I believe this wants to have the original $_GET instead ...

UPDATE:

It seems this wants to replace drupal_get_destination(), which is statically cached.

That is okay, but it should probably use the same functions:

- https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...

   // ...
   $query = drupal_http_build_query(drupal_get_query_parameters());
    if ($query != '') {
      $path .= '?' . $query;
    }

Log in or register to post comments

Comment #69

douggreen commented 12 December 2014 at 14:35

Given how long this took to get committed (and it does look like it's committed), I'd suggest a simpler change, which is just to use $_GET instead of $_REQUEST.

The problem with using $_REQUEST is that it can contain cookie data (see http://php.net/manual/en/reserved.variables.request.php and http://php.net/request_order), depending on the php ini configuration. And cookie data with httponly set (see http://php.net/setcookie) should never leave the server.

Log in or register to post comments

Comment #70

fabianx commented 12 December 2014 at 14:37

I don't think this is committed, yet.

And I think using proper APIs is important to avoid such problems.

And I still believe the destination URL should be created before $_GET is merged with $_POST.

Log in or register to post comments

Comment #71

dsnopek

he/him

English

USA

commented 28 January 2015 at 19:55

Issue summary:	View changes
Status:	Needs work	» Needs review

Status	File	Size
new	views-ajax-nginx-1036962-71.patch	490 bytes

1 file was hidden/shown/deleted

Status	File	Size
hidden	1036962-views-ajax-destination-65.patch	1.02 KB

I can also confirm that this issue occurs under nginx but not Apache. Does anyone know why? I really can't imagine how differences in webservers could cause this. But I know next to nothing about nginx, so that might be why I don't get it.

Anyway, I agree with @Fabianx in #68 that using the same APIs as in drupal_get_destination() which is being inlined here makes sense. This basically means switching from $_REQUEST to drupal_get_query_parameters() which has the magic property of skipping $_GET['q'].

So, here is a much shorter patch that both (a) fixes this problem for me under nginx and (b) makes the Views code closer to the code it's inlining.

Please let me know what you think!

Log in or register to post comments

Comment #72

brandy.brown commented 29 January 2015 at 18:55

#71 worked for me. Thank you!

Log in or register to post comments

Comment #73

katannshaw commented 29 January 2015 at 19:25

Patch #71 worked for me as well. Thanks.

Log in or register to post comments

Comment #74

istryker commented 31 January 2015 at 18:12

Status:

Needs review

» Reviewed & tested by the community

Haven't tested, but that patch looks better. Calling the Drupal function to get the parameters vs getting them directly.

2 people said it worked, RTBC issue

Log in or register to post comments

Comment #75

xurizaemon

he/him

Ōtepoti, Aotearoa 🏝

commented 13 February 2015 at 03:52

Issue tags:

-dvcs11

+dvcs11 nginx

Here's hoping it gets into the next Views update I guess :S

RTBC++ from me too.

Log in or register to post comments

Comment #76

Anonymous (not verified) commented 17 February 2015 at 12:34

I just stumbled upon this bug in Pantheon and #29 fixed it for me.

Log in or register to post comments

Comment #77

dsnopek

he/him

English

USA

commented 17 February 2015 at 12:37

@ivanjaros: could you try the patch in #71 and see if that works for you too?

Log in or register to post comments

Comment #78

lunk rat commented 18 February 2015 at 23:21

#71 fixes it for me on BOA 2.4.4 with PHP 5.5.21, Nginx 1.7.9.1

Incidentally I am also creating a dashboard that uses AJAX-enabled views within a Seven overlay to provide edit links to content. This patch fixed my issue.

Log in or register to post comments

Comment #79

areynolds commented 19 February 2015 at 06:52

#71 works beautifully in an nginx environment (tested both in Kalabox and Pantheon).

Also, might I add @dsnopek has impeccable patch labeling etiquette.

Log in or register to post comments

Comment #80

vadym.kononenko commented 23 February 2015 at 13:24

#71 works for me.

Log in or register to post comments

Comment #81

simon georges commented 20 March 2015 at 16:43

#71 fixed it for me on IIS 7.5. Great work everybody! Let's commit this ;-)

Log in or register to post comments

Comment #82

simon georges commented 20 March 2015 at 16:44

Issue summary:	View changes
Issue tags:	-dvcs11 nginx	+dvcs11, +nginx, +IIS

Log in or register to post comments

Comment #83

FutureFirstDave commented 20 March 2015 at 16:51

Yup, #71 works for me too.

Log in or register to post comments

Comment #84

socialnicheguru commented 20 March 2015 at 19:57

Will this fix in #71 work on apache or break its functionality while fixing nginx?

Log in or register to post comments

Comment #85

fabianx commented 20 March 2015 at 23:31

RTBC +1

Log in or register to post comments

Comment #86

dsnopek

he/him

English

USA

commented 21 March 2015 at 12:52

@SocialNicheGuru: This fix doesn't break anything on Apache - everything continues to work fine there.

Log in or register to post comments

Comment #87

hanoii

Spanish

🇦🇷UTC-3

commented 10 April 2015 at 15:40

@dsnopek just found this issue on panopoly on pantheon and remember about a this patch which I used to use in serveral of my sites, but now it has a patch from you, any chance to include the patch in panopoly as well: #2468989: Include views patch to fix destination query string on ajax calls from views ?

Log in or register to post comments

Comment #88

gmclelland commented 17 April 2015 at 17:55

The patch in #71 works for me using NGINX on Pantheon

Log in or register to post comments

Comment #89

ChrisFlink commented 1 May 2015 at 07:02

Patch #71 works for me too, and is RTBC but was not included in 7.x-3.11 release.
I wonder why?

Log in or register to post comments

Comment #90

mustanggb commented 1 May 2015 at 10:39

Such a simple and elegant solution, let's have it!

RTBC++

Log in or register to post comments

Comment #91

lunk rat commented 1 May 2015 at 13:44

Priority:

Major

» Normal

This patch works great for my sites.

Every time Views gets a security release I start seeing people commenting "RTBC++" on patches that are ready because we all have to patch after installing the security release ;) ... let's drop this one off of the list of things to remember to do when we update our sites!

Log in or register to post comments

Comment #92

rogerrogers commented 1 May 2015 at 14:07

@lunk_rat For real. It works. It has worked for years. Include it and be done with it.

Log in or register to post comments

Comment #93

fabianx commented 1 May 2015 at 14:49

Priority:

Normal

» Major

I think priority major is correct.

Log in or register to post comments

Comment #94

meaton commented 5 May 2015 at 17:25

I can also confirm that this patch works well on Pantheon/NGINX.

Log in or register to post comments

Comment #95

dawehner

German

commented 6 May 2015 at 15:18

Status:

Reviewed & tested by the community

» Fixed

I totally agree that $_REQUEST contains too many information. We already merge into $_GET, so using that as part of drupal_get_query_parameters() should be fine.

Ups, I committed that as part of d08465de955b88e5f262c06d99b79ceb167dca88 already when trying things out locally, anyway,

git --allow-empty helped in that case. Committed that empty message and pushed to 7.x-3.x

Log in or register to post comments

Comment #96

6 May 2015 at 15:19

dawehner committed c3536f4 on 7.x-3.x authored by dsnopek

Issue #1036962 by acbramley, dsnopek, grahamC, mr.york, das-peter, wiifm...

Log in or register to post comments

Comment #97

20 May 2015 at 15:24

Status:

Fixed

» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Log in or register to post comments

Comment #98

sushantpaste

Marathi

Sawantwadi India

commented 14 September 2015 at 11:20

Thanks for the patch :)

Log in or register to post comments

Comment #99

Solthun commented 9 November 2015 at 12:15

I can confirm that this patch worked on an environment with nginx and also on Azure hosting with IIS.
Thanks for the patch!

Log in or register to post comments

Comment #100

betoaveiga

Spanish

Daule, Guayas

commented 26 September 2016 at 22:42

(I know it's old, but it could help somebody searching the same like I did)
To fix this problem you can create/modify your module hook_init like this:

function your_module_init () {
  if (isset($_GET['destination'])) {
      $_GET['destination'] = str_replace( 'q=views/ajax&','',$_GET['destination']);
  }
}

It works for me.

Log in or register to post comments

Comment #101

michaeljhill commented 8 March 2017 at 16:13

I'm having this issue while using the Jump Menu format of Views. I need AJAX to be enabled so that I can see my exposed filter in the view's block. Instead of getting sent to the expected address, I get directed to "document-root/views/ajax" when AJAX is turned on. I've tried the patches on this thread but they have not made a difference. I see several people saying this issue is only occurring on nginx, however I'm having this problem with apache being my web server.

Running:
Drupal 7.53
Views 7.x-3.15

Log in or register to post comments

Edit link destination incorrect when using AJAX-enabled views

Comments