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

Command icon 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

murz created an issue. See original summary.

murz’s picture

I 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:

    if ($this->view->preview) {
      // The "view" area handler plugin uses the "preview" to render the
      // inner view. Therefore, we have to use additional check if this preview
      // is not come from the "view" area handler plugin or not.
      $isPreview = TRUE;
      if (!empty($this->view->parent_views)) {
        // Preview from the "view" area handler plugin.
        $isPreview = FALSE;
      }
      elseif ($this->view->dom_id) {
        // Ajax refresh of the inner view.
        $isPreview = FALSE;
      }
      if ($isPreview) {
        return 'views-ui-preview-form';
      }
      ...
    }

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 == TRUE

murz’s picture

Issue summary: View changes
mably’s picture

Thanks 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.

murz’s picture

Issue summary: View changes

mably’s picture

Status: Active » Needs review

Looks like we simply needed to replace :

$this->view->preview

By:

$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.

murz’s picture

Status: Needs review » Reviewed & tested by the community

Tested, works great on my side! And such an easy solution, thanks! How did I not notice it myself? 🙈

mably’s picture

I have to admit, Claude gave me some clues ;)

Let's merge this!

  • mably committed b120b1ef on 3.x
    Issue #3548430 by murz, mably: Detecting of the preview mode breaks AJAX...
mably’s picture

Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.