Problem/Motivation

Starting with Drupal 11.3.0, Core natively updates the browser URL during AJAX View filtering by default (see Change Record #3552223). To maintain the view state across reloads, Views Reference Field appends its viewsreference[compressed] parameter to the URL.

However, there is a bug in how the module reconstructs the View from this compressed parameter. When a View uses Relationships (e.g., to Media for images), reloading the page with the compressed parameter causes the relationship to fail. This not only leaves the relationship-based field empty (even when data exists) but crashes the rendering of all subsequent fields in the row.

Steps to reproduce

  1. Install Drupal 11.3.0 (or higher).
  2. Create a View of type "Content" (e.g., Bundle: Page).
  3. Enable AJAX: Yes in the View settings.
  4. Add a Relationship: Content: Media Image (set as NOT required).
  5. Add the following Fields in this specific order:
    1. Field 1: (Media Image) Media: Image (using the relationship).
    2. Field 2: Content: Title (standard base field).
  6. Reference this View in a node using the Views Reference Field.
  7. Visit the node and apply a filter via AJAX. Notice the URL updates with ?viewsreference[compressed]=...
  8. Reload the page.

Expected result

The View should reload with the filter applied. Both the Image (Field 1) and the Title (Field 2) should be visible, provided the data exists in the database.

Actual result

Field 1 (Image): Is empty/missing, even if the Media reference is correctly valorized in the database.
Field 2 (Title): Is also empty/missing, despite being a standard base field.

Observation

If Field 2 (Title) is moved ABOVE Field 1 (Image) in the Views UI "Fields" list, the Title renders correctly, but the Image remains empty.

CommentFileSizeAuthor
#18 Screencast from 2026-04-21 09-26-57.gif10.82 MBscott_euser
#2 3578487.patch1.62 KBweseze

Issue fork viewsreference-3578487

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:

About issue forks

Comments

f.tendi created an issue. See original summary.

weseze’s picture

weseze commented
StatusFileSize
new 3578487.patch1.62 KB

Experienced the same problem today.
This largely broke our views... Copy pasting an url would result in a broken result page. Refreshing the page would result in a broken result page...
Simply deleting the code that adds this to the URL fixes all of our problems. Not sure what this was supposed to do...

See attached patch. Probably the entire system for adding the compressed string can be deleted as of Drupal 11.3.x?

scott_euser’s picture

scott_euser commented

When the configuration options get long you'll get 414 errors. Note to reproduce you'd need to click twice with ajax history enabled, then eg click back for things to start failing without it (and not every scenario will fail).

Haven't looked deeply at the 11.3 changes yet but probably the same solution as described in https://www.drupal.org/project/viewsreference_extras/issues/3577383 is needed instead of the current patch (since the current patch reverts to previous problems)

scott_euser’s picture

scott_euser commented

Hiding patch due to above mentioned reasons

weseze’s picture

weseze commented

Could you clarify: "since the current patch reverts to previous problems" please? What are the previous problems?

For us at least without the patch we are getting fatal errors and non-working views on all of our websites. At the moment this only occurs when refreshing the page or sharing a link. So not highly critical, but still a serious issue.
With the patch everything is working fine...

scott_euser’s picture

scott_euser commented

The compression was added to resolve the 414 errors as I replied above. Have you tried the other issue I suggested in #3?

weseze’s picture

weseze commented

I'm afraid I don't follow... Or I misunderstand the core of the issue here...

We are not using the "viewsreference_extras" module. So a patch on that module is not useful for us.
We are also not using "AJAX history" option, since Drupal core 11.3.x now seems to handle that out of the box. We do have that module installed.

The 414 errors you are referring to: we never experienced those.
If I understand correctly these are coming from to long string arguments in the URL, caused by the "viewsreference[compressed]=..." part generated by this module to persist filters in AJAX requests in the URL.

Since Drupal 11.3.x (or previous versions with the AJAX history module enabled) support this behaviour already, why is this compressed string needed?

scott_euser’s picture

scott_euser commented

Just because you haven't experienced 414s doesn't mean we can revert it to cause those issues again for others with bigger more complex use of viewsreference. You're welcome to use your patch, I'm just explaining why it cannot be merged, so you should expect to have to maintain your patch indefinitely is all, and I'm suggesting you read that trail of issues to avoid having to maintain your unmergeable patch.

If you read that issue it was not related to views reference extras, it's just someone explaining how they solved.

Ajax history module extends core ajax history and gives you the option to exclude query string variables (though as noted in #5 there views ajax history has a bug so you need a patch from that).

But you're of course welcome to stick to your patch.

scott_euser opened merge request !100

scott_euser’s picture

scott_euser commented
Version: 8.x-2.0-beta10 » 8.x-2.x-dev

Managed to find time to get to this. Before: broken as per issue summary. After: Works when refreshing the page, relationships no longer broken.

Will see how best to add test coverage for this, but in the meantime if someone could apply the MR patch to confirm it also sorts it for them.

scott_euser’s picture

scott_euser commented
Status: Active » Needs review

Test coverage added as well. If someone could confirm please that this solves it for them as well, will get this merged in. Until then, feel free to use the views ajax history + #3574963: exclude_args not applied to exposed form submissions in cleanURL() to exclude the viewsreference field from the query string altogether (avoiding this issue).

Thanks!

weseze’s picture

weseze commented

Confirmed! This change fixes issues for us with page refreshing and url copy-paste.

scott_euser’s picture

scott_euser commented
Status: Needs review » Reviewed & tested by the community

Excellent thanks for taking the time to recheck

  • scott_euser committed ac9508fe on 8.x-2.x 
    fix: #3578487 Compatibility with Drupal 11.3.0 AJAX History:...
scott_euser’s picture

scott_euser commented
Status: Reviewed & tested by the community » Fixed

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

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

Maintainers, credit people who helped resolve this issue.

pcambra’s picture

pcambra
he/him
Primary language Spanish
commented
Status: Fixed » Active

I think this has broken the ajax pager for our views, for what I'm seeing, after updating to beta11, when using the pager, I get empty results

scott_euser’s picture

scott_euser commented
Status: Active » Fixed
StatusFileSize
new Screencast from 2026-04-21 09-26-57.gif10.82 MB

Hmmmm I gave this a go on a clean Drupal 11 install and it seems to work fine. Can you raise as a separate issue please @pcambra with steps to reproduce from clean install? E.g. viewsreference plugins installed/view configuration/etc

Screencast of it working okay

(sorry for the poor quality screencast, convert to gif did a terrible job but I guess its sufficient)

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

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

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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