Contextual "edit view" links to a View's default display redirect back to the linking page

Something appears to have changed inside of Views itself. Updating to the new rc, I get the same problem, and I've traced it to the fact that those Views don't have other displays besides the default display that we've been manually embedding in the block / page. I was hoping to put off that conversion, but we may have to go for it. For now, let's make this a Views support request.

The issue here is that the contextual link normally is to the following URL:

/commerce/admin/structure/views/view/commerce_cart_block/edit/default?destination=node

Because there is only the default display, Views appears to institute an automatic redirect to the following URL:

/commerce/admin/structure/views/view/commerce_cart_block/edit?destination=node

Unfortunately, when the redirect happens, it's picking up on the destination query string and sending you back to the page you were on. ; )

So the question in the Views queue is: can we get around this behavior without having to fix [#] before our 1.1 release?

The code that does that redirect *should* in theory be able to unset $_GET['destination'] (as long as preserves the destination in the new URL) to ensure drupal_goto() doesn't choke on it.

Care to attempt a patch? It should be a one or two liner.

Patch attached. Think it's sufficient to just grab destination out of the $_GET?

I took a quick look at drupal_get_destination()

It includes this code I hadn't realized was there when I wrote the above:

  $destination = &drupal_static(__FUNCTION__);

  if (isset($destination)) {
    return $destination;
  }

Therefore we need to clear that static just to be safe.

It may be best to actually use drupal_get_destination() then unset both $_GET['q'] and the static.

Oh, in checking drupal_goto we do NOT need to unset this static.

We should still use drupal_get_destination to prepare the field, though.

Double checked and because of the way drupal_goto() works, we do still need to unset($_GET['destination']).

I think the proper way of doing it is to remove the drupal_goto and allow to get the default display directly via the url.
This patch allows to go to the default display, even if it's hidden via the setting, but hide the tab if the setting is enabled.

The only problem is that the access is coupled to the logic of generating the list of displays.

Feel free to comment which idea is better.

Patch in #7 was tested and worked here. Cannot comment on the better solution, so I leave alone the status.

#7 works and looks good to me. Thanks.

Thanks for testing the patch! Committed to 7.x-3.x after a short review.