Enable bookmarking of AJAX views

the problem is that the browser NEVER sends the fragment to the server

The asynchronous module states:

This module requires Page renderer module and a theme that support dynamic loading (e.g. Chrysalis).

Both Asynchronous and Page renderer are dev versions, so this probably isn't a very stable thing to be trying to build into Views any time soon. I think it's great that people are making strides to make Ajax calls bookmarkable... but if it's not stable anywhere else yet, then there's no way it's going to get into Views.

Oops, didn't mean to change the title. Changed it back.

I don't think we need to use any kind of a plugin for this. All we need to do is have the browser check the fragment and make an ajax call if it exists; and to have the browser UPDATE the fragment on subsequent ajax calls.

Perhaps 'all' is understating how much work this actually is.

subscribe

I realize that this issue is quite old now; is there another issue where this functionality is being discussed or worked on? If so, I'd be happy to test patches.

To my knowledge nobody is actually working on this. This would be a useful feature, though, and I'd support work on it.

subscribing!

Wow, critical? Why does everyone think their needs are critical?

Just to get attention for the importance of it! It might not be critical! But still it's important!

And the issue is alive again since November 2009! That's the effect of Critical issues!

It's only alive if someone agrees to work on it. Maybe you should lobby dereine =)

it would be REALLY super if the AJAXed View remembered what view-page it was on when a link was clicked, and returned to that view-page again after the whole website-page reloaded.

it's a pain right now: if the user pages over six times in a sidebar view and clicks on a link, when the page reloads they have to page over six times again to click on the next link.

I can't find any views jQuery pagers/carousels that quite do what I want, either...

Drupal is so great most of the time I'm like "w00t! someone already did this I don't have to code it!" but then when I need to change/extend some of the functionality (like this) the awful reality of "someone else coded this now I have to unravel their strange, mysterious code before I have the faintest idea where to BEGIN to fix my problem" hits... :P

SUBSCRIBE

url should be ALWAYS different for every different part of Drupal website.

url should be ALWAYS different for every different part of Drupal website.

With AJAX this just isn't always possible, so this is a basically useless statement to make.

But without dynamic urls Ajax option for Views will be useless very soon also.

Golden rule is that every single click on the website should have unique url.

Or I read wrong tech blogs ?

No offense, but if it's that important to you, please help with the feature request. Your posts are coming off like orders.

Don't read me in a wrong way, I have only good intentions. I am views fan and views are fun for me. :)
Just read some articles and this one often appears - unique urls.
I never carried about that before when I was using ajax in views but now I just start understand how important it is.
So I wrote about that.

If I knew more about ajax I would upload some example patch here for sure.
Also would do this for jCarouselLite module which works crossly-browser perfect as views blocks. But the same - URL always the same.
I wrote about it here: http://drupal.org/node/762956

Believe me I thought its not a big change, just something in javascript which changes current url in a browser after each click.

Now I realize its not so easy to achieve that.

My experience is that with AJAX, it varies depending on how you are using it. Traditionally most AJAX in Drupal has been for form manipulation, and you don't want unique URLs for that. When using AJAX on pagers, indeed unique URLs are something you want. However, it's not as easy as all that because it means that you need to interpret the fragments as soon as the page loads and perform the proper ajax. That makes it hard to just add generically. I'm not saying it's impossible, but it's not a simple problem to solve, which is why no one has yet taken the time to solve it for Views.

I thought adding onClick='javascript:change url...' would be enough.
But you say it must be done after page load. So I believe you are right and have nothing more to add. :)

You are not allowed to change the actual URL with javascript, only the fragment. That's why it's so hard.

Which fragment ?

And is possible not to change , just add '?p=2' in the end ?

No, only the fragment, which is the part after the #

subscribing

Subscribing. Would it be possible, as an in-between step, to allow ajax views results to be bookmarked via clicking on a link, ala the "[link]" feature at http://drupalmodules.com/ ?

Yes, this should certainly be possible; the pagers are able to retain exposed filters, and that makes total sense as an option to AJAX exposed filters. Patches will definitely be considered.

I'm marked this as an unassigned task. If anyone would like to role up their sleeves and take it upon themselves to write a patch it would be awesome

Can anyone think about "%menu_tail" ?

I've used the jQuery BBQ hashchange plugin for things similar to this, and that plugin is now included in D7, but it's used for the Overlay, so I'm not sure that we can reuse it for Views.

We possibly can but it's going to create some ugly URLs. The real issue is going to arise that you can have repeated ajax operations that move you quite a ways through a set of views. Plus, there is a LOT of data that goes into ajaxing a view and it all needs to be somewhere on the page. One of the reasons I've never tackled this is that I'm afraid of how much the data can balloon leading to enormous URLs.

subscribing

Hi guys, I have a sandbox project that deals with this. I'm not making a patch here because it needs an external lib. and I'm not sure how much it'll be possible to integrate. It's missing ui options and all that for now.

I haven't put it through rigorous testing yet, still, it works for basic exposed filters and pager. Here is the tentative module name : views_ajax_history.

The amount of data is actually not that bad (or I missed some pretty huge stuff) as far as state saving goes, it's all done by the browser and the length of URL is not bigger than a view without ajax enabled.

@nod_: nice :) I haven't tested it but if I'm right the external library you are mentioning is history.js. I believe you can use the integrated jQuery BBQ instead. It would remove the external library issue.

Might not be the place to discuss this, but history.js is actually much better statechange > hashchange. You don't need the # anymore on proper browsers.

A lot of time passed since #22 :)

@nod_ yes, but bbq is included in core, which makes it that much easier to use, and even adds a possibility of it being included in Views...

hash urls are fine for admin pages, I'd be very sad to see that on views pages. Using a hash has his own sets of issues too, the intelligent state handling page from history.js has a pretty good writeup which I share.

As usual IE is the problem, everything is fine for other browsers. If you absolutely need history I'd say just don't use ajax views. If this goes in views somehow I really don't think it should be on by default either (except for a clean implementation using statechange).

In any case I really don't want to contribute to views by introducing the crazy url hash hack just because it's used by core.

Who cares about my opinion anyway, it's important and I just have to make the thing pluggable to allow for a different library to be used by contrib. If someone can walk me trough the best way to do that in views (a new class? just some JS wizardry?) that'd be nice.

If someone wants to help the js part is here : views_ajax_history.js. There is no config form for this either, *wink* *wink*.

Anyway I'll get working on a patch using bbq to include that in views.

Sorry, no patch yet, just adding a reference to #1341226: Discuss the use of the History API in the overlay module.

See also: #1084336: Use HTML5 History API for AJAX (so URL preserves state of exposed filters) - perhaps that issue should be marked duplicate?

In the interim is it at all possible to allow for the ajax to still function even if there is a &page=X in the query string? For example, I've got some links to specific pages of a view that uses ajax...but if I go to myview&page=3, the ajax pager no longer functions. Throbber shows up, goes away, page stays the same. It seems as though we could still get that to work, even without fancy javascript stuff. And that would get us part of the way towards bookmarking specific pages in an ajax-paged view.

Is this a separate bug that deserves its own issue?

I'd be happy to work on it if someone can point me in the right direction...I'm having trouble finding the right place in the code for this...

I can't believe I missed this thread while searching for existing issues. I've implemented a solution in a patch to Views 3.5 here:

#1786904: Deep link filter settings & Reload results from AJAX submit when using the browser's back button

I would suggest https://drupal.org/project/views_ajax_history by nod_. It's not a sandbox project anymore, and works great.

This module allows users to save ajax views. Each saved view is an entity.

https://drupal.org/project/views_save

Any chance of getting this into views core?
This is standard / expected behavior for modern web apps.

I don't know enough about Views coding, but maybe you are interested in this solution that I found
http://www.accessadvertising.co.uk/blog/2013/03/html5-history-api-ajax-u...
http://www.accessadvertising.co.uk/blog/2013/04/html5-history-api-making... (here the solution)

Thanks for so much shared code :)

I came accross this today when experimenting with using AJAX option for Views, I was hoping that the URL would be updated when filters and pagination changes (like it does without AJAX enabled), maybe this issue could be restarted?

Re #47: Did you try the module mentioned in comment #43? If so, I'd like to know if it worked for you.

Re #48 thanks for linking that, haven't tried that yet

> Re #47: Did you try the module mentioned in comment #43? If so, I'd like to know if it worked for you.

For anybody interested for this I can verify that https://drupal.org/project/views_ajax_history works fine for both filters and pager on Drupal 8 site. Will report if i find any problems, but for now it seems this module is a good solution until core supports this in the future.

For sure needs test coverage.

Tests provided.

I'm not sure we have to add also the pager info in URL

This looks like a Feature request and belongs more to Views rather than Views UI.

I see the pager is added correctly. Other question is whether we want to clean the URL for filters that are showing default values, making the whole URL (which, being displayed in the browser's address bar, is somehow part of the UI) much more cleaner.

The patch from #59 will change the url in the address bar incorrectly when the view is a block instead of a page.
When the view is a block, the view_base_path is empty.

Example: a node /node/1 with alias /categories-overview containing a views block "categories" with filter "color". After changing the color filter, the url would be mysite.com/?color=red instead of mysite.com/categories-overview?color=red.

The attached patch fixes this, so the url will be mysite.com/categories-overview?color=red.

Here is a reroll for Drupal 10.0.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Fixed failed commands on #70
Attached patch against Drupal 10.1.x

Re-rolling #65 for 9.5.9

Hi @webdrips
Your patch doesn't work, the view returns the error after applying:
Error: Class "Drupal\views\Ajax\SetBrowserUrl" not found in Drupal\views\Controller\ViewAjaxController->ajaxView() (line 219 of /code/web/core/modules/views/src/Controller/ViewAjaxController.php)

Is there a quick way we can clean up the URL that is built? Right now, I only have a couple of exposed filters and the URL already looks like this: ?date%5Bmin%5D%5Bdate%5D=2023-05-29&date%5Bmax%5D%5Bdate%5D=2023-06-16&promotion_type%5B6%5D=6&promotion_type%5B1%5D=1

#72 does not apply to 10.1.0. Here is a reroll.

(I tried to generate an interdiff but it fails for some reason.)

The most recent patch causes a bug if user visits bookmarked url and tries to uncheck the existing filter. The main reason is that queryString is preserved when performing request to the ajax callback page:

    this.element_settings = {
      url: ajaxPath + queryString,
      submit: settings,
      httpMethod: 'GET',
      setClick: true,
      event: 'click',
      selector,
      progress: { type: 'fullscreen' },
    };

So you can't really reset bookmarked filters.

Also it is better to push new filter state into history, so you can use browser navigation to restore previous filter state.

Instead of removing queryString that caused issues, now remove only params that represent exposed filters.

#82 causes a problem with pagination, for example :

1. Check a filter that returns 3 page of results.
2. Browse to page 3.
3. Check another filter that only has one page of results.
4. The view stays on page 3 and displays no result.

Remove the page param from the query string seems to fix it.

Here is a reroll of #83 for Drupal 10.2.

Re rolled with 11.x.

I made a fix so that browser URL is not updated if the view is in a dialog/modal, because in that case the browser URL is not the URL containing the view parameters.
It's like there's an URL for the page which is behind the modal (the one shown in the browser URL field), and one other URL ("hidden") for the "page" shown in the modal.
Without this fix, we got a strange behavior when using media library search in modal: it works the first time, but as soon as params are added to the browser URL, subsequent search is buggy until the whole page is reloaded.
I guess a test should be added for the modal case? Like just test that browser URL is not updated when an AJAX exposed form is used inside a modal.

And automated tests do not pass, I guess it's just some test code that needs to be updated for compatibility with current 11.x.

Then, I believe the merge request will be ready for review again.

I rebased and fixed tests but I can't remove the draft status on the MR.

I had to change the order of GET params in some related tests, I'm not sure why.
I suppose that's because the code generating the SetBrowserUrl command does not process them in the same order as the code generating the pager links.
I'm not sure it is a problem as long as the GET params themselves are still the same.

Have not reviewed as the issue summary needs some attention please.

I updated the summary but now the MR has a conflict.

I fixed the conflict (it was caused by #3323574: Pager not working correctly in AJAX view with exposed filters).

I also noticed we were mixing two ways to remove parameters from the query (a regex and parsing it as an array). I moved everything to the new way.

Rerolled patch from #85 for Drupal 10.4.6.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

left some comments on the MR.

After some searching I also found the contrib module Views AJAX History. Is there any reason why not to use that module and continue working on this issue?

Removed patches to focus on the MR.

I think comments have been addressed.

Feedback appears to be addressed for this one.

Now that we have htmx in core it could be a bit easier to manage that. We don't use htmx for exposed forms but that should be something to look into

I pushed a couple of commits to use constructor property promotion in SetBrowserUrl and remove the unnecessary docs from the controller constructor as well as merging in latest 11.x

Created a CR for the new AJAX command.

Discussed the issue with @catch and @nod_ - we talked about whether the new AJAX command should be in core or views. We agreed this is temporary because when we migrate to HTMX there is already a command for this. Also views ajax is likely to be replaced by HTMX - see #3548100: [PoC] Use HTMX for (some?) ajax views. We agreed to get this in, even if it is deprecated "soon" it's still a win in the meantime.

Committed 9c8eb29 and pushed to 11.x. Thanks!

Thanks for the work on this!

Sounds like Views Ajax History module probably needs a follow-up issue to mark itself incompatible with next release of core or perhaps check core versions otherwise sites might get 2 changes to history for each views ajax. Have I understood this right? Happy to work on contributing such a fix to there if so.

Thank you all! I just came across this wonderful improvement 🎉and had to remember this still existing and slightly related Views Core "Reset" button bug with AJAX views: #3346820: On views with AJAX enabled, exposed filter "reset" causes (non-ajax) page load
Maybe this can now be solved better based on this improvement? If anyone has a good idea for a resolution, that would wonderful.

Very cool, great to see AJAX improvements! @scott_euser: Handling Views Ajax History in a follow-up issue sounds like a good idea, and I have mentioned it in the Issue Summary.

Thanks for making me aware of the AJAX Reset issue @anybody. I in fact tried "Views AJAX History" just the other day, exactly to prevent page load after Reset or navigation back, with no luck. So since it's related, I am adding it.

I added a note to an issue in Views Ajax History: https://www.drupal.org/project/views_ajax_history/issues/3386120#comment...

This is triggering a weird race condition in our tests, easy to fix: #3560093: $target_url in ViewAjaxController::ajaxView can be NULL

Backport patch to D11.2.9 for composer.

It is a great improvement for institutional websites, though, in some other cases, such as stores or website where the UX takes over SEO purpose (for example when using views_infinite_scroll), I think one might want to restore back to previous behavior.

I've let a workaround solution in #2870341: Change URL in browser with page parameter.

So after updating from 11.2 to 11.3 this issue has caused a great deal of issues with query parameters. When an exposed filter (taxonomy reference field) allows multiple selections, new filter query parameters are always appended after every form submission. Also after de-selecting an option and submitting the form, the option is still selected.

I can reproduce this using a standard profile install. Creating a simple ajax view block with an exposed filter with multiple selection on the "Tags" field for the "Article" content type shows the issue. The resulting url after form submission looks like "/home?field_tags_target_id[0]=1&field_tags_target_id[1]=1&field_tags_target_id[2]=1". The "/home" prefix also gets injected when the block is on the home page and depends on the node alias.

Does anyone know why this might be? Why would this merge cause so much complications? Were multiple selections tested?

I believe there are some existing open issues about problematic behavior with multi-value selection fields, we also had issues with them before combined with the ajax_history contrib module and other cases. Found #3273334: Unable to unselect a multi select exposed filter in ajax view and #3121172: Exposed filters get values from url when ajax is on.

Although those two issues are related, the addition of this "feature" is probably the most disruptive I've encountered with Drupal core. To add that there is no way to opt in to/out of the feature is more frustrating. I would've expected more thorough review and testing from an issue that took 18 years to "resolve".