Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Views in pop-ups -I haven't tested others- are not working well when using ajax Views.
The problem I've found is the Views plug-in not doing a proper rendering of the view, losing Views ajax and settings in the way. This may be also related with some other issues about views exposed forms not working, etc...
To reproduce the issue:
0. We have an entity form that displays on a pop-up with two forms (and the drop-down selector). One of them is a View -with a pager- and the other one is an inline entity form. I don't think it matters, the important thing is having two forms in the pop-up.
1. In order to get the Views pager working we've had to enable AJAX In the View and remove the library 'entity_browser/view', just commented it out (Otherwise the pager is just not working).
2. Open the pop-up, get to the View, the pager is working *only the first time* you visit it.
3. Switch to the other tab / the inline entity form
4. Switch back to the View. Now pager is not working (it's redirecting to another page). This seems to be caused by missing drupalSettings for the new View.
Patch and more explanation will follow in a minute.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2558739-views_ajax_pager-01.patch | 3.05 KB | jose reyero |
Comments
Comment #2
jose reyero commentedThis patch fixes the issue for this specific case. Not sure about other set-ups, widgets, etc... I suspect this may help with any other views issues though.
It does two things:
- Keep the views dom_id in the form state so it can be reused when switching tabs back and forth. Not fixing the issue but it will prevent views js settings from growing up every time you switch.
- Properly render the View inside the View widget. As we are doing it now we are losing the form metadata -except for the very first rendering that seems to get through some other way.. I've taken a look at views ajax code and found out about render contexts, bubbling metadata, etc... so the idea is taken from there.
More comments in the patch itself.
Comment #3
slashrsm commentedThank you for your patch.
At NYC we discussed Modal display a lot and at the end we kind of agreed that it would probably make sense to go with "iFrame in a modal" approach. There are few reasons for that:
1. We are afraid that it will be very, very hard to reliably support all possible Widget implementations on Modal display. It seems to be just to different and we're afraid we'll need custom integration code for most of widgets.
2. iFrame display is in a quite good shape, which would make transition quite easy.
3. D7 media uses the same approach for it's media browser and it seems to work quite nice.
What do you think about that?
Comment #4
primsi commentedCreated a separate ticket for the implementation of the approach slashrsm mentioned in the above comment: #2569569: Make modal display plugin use iframe
Comment #5
primsi commentedComment #6
jose reyero commented@slashrsm,
Yes, I agree that "it will be very, very hard to reliably support all possible Widget implementations" so it makes sense to reuse as much as possible.
Then iFrame in a Modal sounds good, yeah, it will be much simpler, at least you won't get kicked out of the pop-up every time a link is not properly reworked, which is one of the things driving me crazy - well, I never tried it, but I think it will work that way, right?.
However, this patch -or part of it- still makes sense if you want to render complex objects like views inside other objects. But also when having a multi-tab iframe or pop-up or whatever I think the easier way will be using ajax reloading for every component so you can keep some state when switching back and forth.
So in order to reduce complexity too, why not making every sub-component ajax-enabled when possible, taking advantage of views being already capable of ajax reloading, then you don't need to rewrite them that much?
Comment #7
samuel.mortenson@Jose Reyero You bring up a good point - the experience of using AJAX filters and pagers in Views is almost almost always preferable to reloads, and now that we're moving to iFrames everywhere we should probably look into an AJAX-first experience for the entire Browser (Selectors, Widgets, etc).
Comment #8
samuel.mortenson@jose-reyero Just submitted https://github.com/drupal-media/entity_browser/pull/129, which among other things uses AJAX on Views filters, sorts, and pagers. Might be worth a look.
Comment #9
slashrsm commentedPull request that was mentioned in #8 was merged. Is this bug still relevant?
Comment #10
samuel.mortensonAlmost certain this is fixed now, as we handle pagers in a completely different way. Unless @jose-reyero is still having problems, I think we can close this as Fixed.
Comment #11
slashrsm commentedFeel free to re-open if needed.
Comment #13
boobaaViews pagers still not work as expected. Steps to reproduce:
1. Create an entity_browser view as usual.
2. Create an entity_browser using this view. It doesn't matter if it's a modal or an iframe.
3. Add an entity_reference field that uses this entity_browser as its widget.
4. First click on any pager-related link in the entity_browser works, second one does NOT work. All I'm getting is a JS error:
Uncaught TypeError: Cannot use 'in' operator to search for '.js-view-dom-id-baf7d6ecfe836159f240d12bbea5f2e290b2e7c076eaa3e438fcfbe573f31fc2' in undefinedin/core/misc/ajax.js?v=8.1.0:1213as a "response" to the POST request made to/views/ajax?uuid=f621a751a76f7e7a83882acdb0e21ca11b2c927f&original_path=/node/16336/edit&_wrapper_format=drupal_ajax.After (manually) applying the patch from #2 and a
drush cr, it remains the same.Comment #14
samuel.mortenson@boobaa I just worked on a core issue fixing a similar bug! Could you try my patch from #2700495: Method removing expired drupalSettings.ajax tries to remove settings when there is no ajax defined (comment #24) and see if it fixes the problem for you?
(P.S. I added the core issue to the https://www.drupal.org/project/file_browser project page when I first discovered this bug, unfortunately it affects everyone running 8.1.x before my patch was committed.)
Comment #15
boobaaSo this is/was apparently a core bug – the patch in #2700495-24: Method removing expired drupalSettings.ajax tries to remove settings when there is no ajax defined solved the issue for me.