Created a search view with a contextual filter and added some sort fields for the view. Placed the sort block on the view, but the sort dropdown wouldnt display. When i debugged, the following condition in the build function in Drupal\search_api_sorts\Plugin\Block\SearchApiSortsBlock is failing.
if (!$search_api_display->isRenderedInCurrentRequest()) {
//Display is not rendered in current request, hide block.
return [];
}
The isRenderedInCurrentRequest function compares the current path which is for example /myview/1 to the plugin definition for the view which is /myview/%param and the condition fails there. Commenting out the return causes the sort dropdown to display properly.
The condition needs tweaking to correctly accommodate contextual filters.
Thanks
Sukanya
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2842557-14--views_displays_route_matching.patch | 2.21 KB | drunken monkey |
Comments
Comment #2
strykaizerThis looks like a search api issue, assigning accordingly
Comment #3
borisson_Possibly also related to #2829074: QueryString processor doesn't work for views that use contextural filters
Comment #4
strykaizerComment #5
strykaizerCheck on routename instead of path
Comment #6
strykaizerComment #7
borisson_Looks great, same reservations as in #2855758: Search api display for blocks always returns false in isRenderedInCurrentRequest. Not sure if this needs a test, if it doesn't let's get this in.
Comment #8
strykaizerEdit: comment removed
Comment #9
borisson_I had the same question a couple of times in facets as well already. Let's fix this in search api.
Comment #10
boobaaAs this could be done in an object-oriented fashion, we shouldn't introduce procedural code, I guess. IOW: Let's get it done the same way as the path.
Comment #11
boobaaComment #12
strykaizerThanks Boobaa,
One thing we should change. This is now implemented in the base class (displaypluginbase), but it should move to the views plugin version instead (ViewsDisplayBase), since we hardcode a views plugin id to match the route here.
This way, search api pages and possible other implementations can provide their own checks.
Comment #13
borisson_In addition to that, I think we should remove the implementation of that method in
DisplayPluginBase, so that everyone that introduces such a plugin is 100% sure that their implementation works for their use case.PS: Next time, please provide an interdiff as well as a patch to make reviewing easier.
Comment #14
drunken monkeyThat all makes sense to me, thanks for reporting, and for the work here so far!
So would everyone be fine with the attached patch?
The base implementation should be fine for most use cases, so I wouldn't remove that. People should make sure the base implementations work for their plugins in all cases anyways, nothing special here, as far as I can see.
Comment #15
borisson_Sure, your explanation here makes a ton of sense. Thanks!
Comment #18
drunken monkeyGood to hear, thanks for your input!
Committed.
Thanks again to everyone here for your work on this!