Problem/Motivation
In the issue #3548125: Allow usage of VEFS in preview mode, support for the preview mode was added. But this change introduces an issue with broken AJAX, because when Views renders the AJAX response, it sets the preview=TRUE
The same is with the "View" area plugin (when we insert a view inside a view by the "View area" plugin, the Header or Footer - it uses the preview=TRUE mode too.
In the result, on the real page (not in the Views edit page) we have the wrong ID for the form selector, like this:
<div class="views-filters-summary views-filters-summary--use-ajax" data-exposed-form-id="views-ui-preview-form" data-once="views-filters-summary"><span class="prefix">
Steps to reproduce
Case 1:
1. Create a view.
2. Enable AJAX mode in the view.
3. Choose some exposed options.
4. Click on the "Reset" link or on any "Remove filter" link.
Actual result: It doesn't work, showing an error: Uncaught TypeError: exposedForm is null
Expected result: It should work.
Case 2:
1. Create a View with a Page display with some exposed filters.
2. Create a "Block" display with another exposed filters, save the Views entity.
3. Insert the created block into the "Footer" section of the Page display using the "Views area" plugin.
3. Choose some exposed options in the embedded view block, submit, see that the Summary items appeared.
4. Click on the "Reset" link or on any "Remove filter" link on the embedded views block.
Actual result: It doesn't work, showing an error: Uncaught TypeError: exposedForm is null
Expected result: It should work.
Proposed resolution
Seems we have to make additional checks to ensure that the current preview mode is related to the Views edit page, not to the real website pages.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork views_filters_summary-3548430
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
murzI debugged this a bit, and seems it is not easy to understand from the current View context, is this view rendered for the Views Edit page, or as an AJAX response.
But found some options to check the traces of the AJAX or "Views area" plugin, like this:
This workaround is not ideal, just sharing my findings, will try to find a better way to do this.
Alternatively, we can get the current route and check if it is related to the Views Edit page, and rely on this, instead of the
$view->preview == TRUEComment #3
murzComment #4
mably commentedThanks a lot @murz for all this investigation work.
Checking the route sounds like a nice solution, let's see what we can do with that.
Comment #5
murzComment #7
mably commentedLooks like we simply needed to replace :
$this->view->previewBy:
$this->view->live_preview@murz can you confirm that it also fixes the problem on your side?
Created a dedicated method in case we need to add other checks.
Comment #8
murzTested, works great on my side! And such an easy solution, thanks! How did I not notice it myself? 🙈
Comment #9
mably commentedI have to admit, Claude gave me some clues ;)
Let's merge this!
Comment #11
mably commented