Problem/Motivation
Some Views displays (such as block displays) do not have a natural path. For these cases, Views provides a 'Link display' setting that allows the display to point to a specific path, including a custom URL. This is particularly important for exposed filter forms. Currently, when an exposed form is rendered for a block display, it ignores the display’s 'Link display' setting and instead falls back to the page display path or the current request path.
Proposed resolution
Update the exposed form so that its action URL respects the display’s 'Link display' setting, including when a custom URL is configured.
Remaining tasks
- Add or update automated test coverage.
- Review the patch and iterate as needed.
User interface changes
None.
API changes
None.
| Comment | File | Size | Author |
|---|
Issue fork drupal-1874838
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 #1
itangalo commentedPatch attached.
Comment #2
itangalo commentedThere were some related issues about this:
#1023074: Exposed filter forms with block view with a feed display submits to the feed URL
#525592: views_embed_view() + exposed filters button = homepage redirect
#607606: Exposed filter in block always defaults to filtering the feed view
They are either marked as 'closed (works as designed)' or 'fixed'. I think this approach/patch solves the issues.
Comment #3
dawehnerThanks for working on this issue! I saw #1329776: Utilize the custom_url/link_url view options in the get_path of the context display which seems to be really similar, so i'm wondering whether we should also check that the link type is custom_url?
Comment #4
itangalo commented@dawehner: It seems to be exactly the same issue. The patch above is against views_plugin_display.inc, so it would affect *all* display types. I think it makes sense, but I really don't know the Views architecture well enough to say what problems might arise.
Comment #5
dawehnerSo i guess this is safe to commit. Any objections?
Comment #6
itangalo commentedSeems good to me!
Comment #7
dawehnerPerfect. Here is a 8.x version.
Comment #9
itangalo commentedIt seems this patch, or some code very similar to it, is now in Views core.
Comment #10
olli commentedI can't find #7 in 8.x.
Comment #11
dawehnerGood catch! I guess we need to add a test here.
Comment #12
jibran10: vdc-1874838-10.patch queued for re-testing.
Comment #25
pcambraComment #26
pcambraAdding a patch to make it easier to include it in composer.json workflows
Comment #28
dpiCross feedback in #2844823-32: Views exposed form action incorrect for embedded views' displays with other displays with paths
Comment #31
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
For the tests requested in #11
Did not test.
Comment #33
yannickooI am happy that I found this and never needed to use that in my time working with Drupal - until now :D Even when having the patch applied I cannot see a differen
actionattribute in the exposed filters forms.Do you think we should also try to read that configured Custom URL first before taking the
<current>URL like this?Comment #34
yannickooComment #35
smustgrave commentedMR isn’t pointed to the right branch. And appears to be missing test coverage
Comment #38
yannickooSo we have a new MR now that is against
11.xbranch. Tests are still missing.Comment #40
joelpittetAdded tests and touched up the issue summary to remove references to "content panes". I hope that moves this forward a bit.
Comment #41
joelpittetForgot to set the status
Comment #44
phenaproxima@catch pointed me to this issue after we argued over #3567584: Update search recipe for Canvas.
This looks like a great solution. I had no idea that "link display" was a thing, or that it supported custom URLs. This appears to solve the problem I opened #3569621: Exposed filter forms should be able to redirect to an arbitrary URI for, albeit in a typically obscure Viewsian way.
I made one tiny change in the MR, which is to use
===instead of==. I don't think that's a substantive enough change that I'm not comfortable RTBCing this.Comment #45
joelpittetThanks @phenaproxima!
Comment #47
larowlanCommitted to main and backported to 11.x thanks