Clean urls off break all Ajax views

I can reproduce the bug by using this view and adding ?t=123 in the queue
Yes your patch solves the issue, but i have no idea whether this is the right fix, how can we find that out?

$view = new view;
$view->name = 'exposed_ajax';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'exposed_ajax';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'exposed_ajax';
$handler->display->display_options['use_ajax'] = TRUE;
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '10';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'node';
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Sort criterion: Content: Post date */
$handler->display->display_options['sorts']['created']['id'] = 'created';
$handler->display->display_options['sorts']['created']['table'] = 'node';
$handler->display->display_options['sorts']['created']['field'] = 'created';
$handler->display->display_options['sorts']['created']['order'] = 'DESC';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = '1';
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['exposed'] = TRUE;
$handler->display->display_options['filters']['status']['expose']['operator_id'] = '';
$handler->display->display_options['filters']['status']['expose']['label'] = 'Published';
$handler->display->display_options['filters']['status']['expose']['use_operator'] = FALSE;
$handler->display->display_options['filters']['status']['expose']['operator'] = 'status_op';
$handler->display->display_options['filters']['status']['expose']['identifier'] = 'status';
$handler->display->display_options['filters']['status']['expose']['required'] = 1;
$handler->display->display_options['filters']['status']['expose']['multiple'] = FALSE;

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'exposed-ajax';

Here is some documentation from http://www.w3.org/TR/Window/

This attribute represents the query portion of a URI. It consists of everything after the pathname up to and excluding the first hash mark (#).

This seems to make sense, what do you think?

So i just committed it :)

This patch breaks every single ajax views when clean urls are off.

With the patch the url looks like this : /?q=views/ajax?q=exposed-ajax instead of /?q=views/ajax. First might want to check if ? is already in the url and that q is views/ajax and not the page/panel/whatever URL.
The checks sounds good enough, but I'm not sure it is.

Looks like this patch handle whatever I throw at it with clean urls on or off. Please confirm.

Fix doc style.

+++ b/js/ajax_view.jsundefined
@@ -35,8 +35,22 @@ Drupal.views.ajaxView = function(settings) {
+  var queryString = window.location.search || '', sep = '?';
+  if (queryString !== '') {
+    // Remove the question mark and Drupal path component.
+    var queryString = queryString.slice(1).replace(/q=[^&]+&?/, '');
+    if (queryString !== '') {
+      // If there is a '?' in ajax_path, clean url are on.
+      if (/\?/.test(ajax_path)) {
+        sep = '&';
+      }
+      queryString = sep + queryString;
+    }

Isn't there a drupal function for doing this? Maybe not because drupal just uses the internal drupal path. I'm wondering whether it would be possible to add a seperate function so it's kind of easier to maintain/understand

Well the drupal js landscape is pretty arid, nothing remotely close of doing that in core. The only other solution would be to set this stuff in PHP. js-wise I don't think you'd be able to make that much simpler if you want to cover all use cases.

I'm not very familiar with drupal php function to get arguments, could be something to look at.

Instead of JS, in theme.inc line 124 that could work:

        'ajax_path' => url('views/ajax', array('query' => drupal_get_query_parameters())),

But after the first call it add a status parameter. Don't know where that comes from.

The PHP solution is not that good after all. It puts all fields values in the url, but only values from the first submit, the following requests keeps the same URL. I mean it works, it's just that what is in the URL is pretty much useless. And I still see the issue of double "?" in the URL too but this time it doesn't crash.

To get more or less the same behavior you'd need to go with JS. The JS code might not be the clearest (really the weirdest here is the regex) but at least it doesn't confuse people with useless GET parameters that are not used.

I've edited a bit the JS, a tiny bit clearer.

It might have been better to open a different issue, since I already took over I'm just changing the title to reflect what's going on.

Thanks for working out this patch!

I tested this with clean urls enabled and disabled and the stuff which are done in the debugger looked fine.
Committed to 7.x-3.x

Thanks a lot :D

I've been playing around to implement ajax history/bookmarking and this functionality get in the way pretty bad. Not possible to use as-is. I'm not saying to change, I'm just warning that it's not the end of it and there might be a couple of people looking for this.

This week I'll have a little something to show in #343535: Enable bookmarking of AJAX views and I might explain a bit more the issue with this.

A patch for the other issue would be cool!

nod_,

Thanks much for this fix. I upgraded to 7.x-3.0 on 12/28 and didn't realize that AJAX was broken (was using sorted columns in a view) until this week. I'm a real Drupal novice, but I was able to apply your patch and get my site back to full functionality with this when I applied this patch today.

PS: I'm not sure if it's considered proper to chime in with confirmation of functionality after the patch has been committed to the dev code train by dereine, but figured another data point wouldn't hurt.

This patch seems to be the cause of #1376686: Error with Ajax enabled views in admin overlay for jQuery 1.7 and Views 3, see comment #13 in that issue.

Have you tried -dev or my patch ?

(ignore, I made a mistake)

Back to fixed, sorry for the noise

I'm not sure what mistake longwave made, but I think the relationship between this and #1376686: Error with Ajax enabled views in admin overlay for jQuery 1.7 and Views 3 was not an error. Both -dev and 7.x-3.0 seem to have the patch in #12 applied, and this patch (in combination with the earlier patch in #1) seem to be the cause of the new AJAX parse error, as reverting the changes in those patches makes the error go away. I'll document the rest of what I've found in the newer thread, but I wanted to ping here in case those who wrote the patch are better able to debug it than I've been.