Prevent saving search_api_view of originalQuery

Created on 20 October 2022, about 2 years ago
Updated 21 May 2023, over 1 year ago

Problem/Motivation

There is no pager on the Saved searches view

Steps to reproduce

Create saved searches. Go to Saved search page /user/[user-id]/saved-searches or edit the related Saved searches view in admin UI, use user's ID in "Preview with contextual filters:" field. Check if there is a pager.

Proposed resolution

I tried to create some custom views for Saved searches. And couldn't receive pager with any settings.
What I've found during debugging. The search views related to the saved query object in saved search entities are executed during loading the entities not only in views, but also in custom code which just loads the saved search entities. Maybe it happens when a saved query object is being unserialized. It looks likes the pager on the Saved searches page is just replaced with values of the executed search_api view from the last saved search entity. Try to save the search for multiple search results but the result should contain small amount of results e.g. 1 or 2. Create several such saved searches. Use setting for a pager in views so elements per page should be less than count of saved searches, so the pager should be displayed. But it is not.

Is there some ideas how to prevent execution of a search view related to the query object when we load a saved search entity?
I think, this also can impact on a performance, not only on broken pager.

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

🇺🇦Ukraine khiminrm

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting this problem, and sorry it took me so long to get back to you!
    Also thanks for investigating so thoroughly and already finding the root cause of this bug. Your solution also looks pretty good – I just want to note that the if ($original_query) is unnecessary since getOriginalQuery() will always return a query object.

    I shortly thought about whether it even makes sense for the query object to serialize its $originalQuery field, but opted against changing that since it’s hard to predict what that change might break in someone’s code. Let’s just fix it locally for this module, as you suggest.

    Slightly adapted patch committed. Thanks again!

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

Production build 0.71.5 2024