Viewsform has incorrect form submit URL if loaded through ajax

I'm still seeing this issue on Drupal 9.5. Patch from #11 did not fix the issue for me, but the patch from #5 did. Not sure why the new patch didn't work. Some investigation is needed.

My use case is a modified version of the commerce cart as well which uses ajax to update the quantities when they are changed. I'm seeing the action of the form change when the views form is replaced.

Updating the target to 11.x since that's the new standard and this code looks unchanged since the 9.5 release.

Neither patch fixes the issue in every case. It's not just broken for Viewsform, but also for ViewsExposedForm.

See 🐛 Submit broken when used with AJAX. Closed: works as designed

If I have a view with exposed filters that has a Data Export view display and a Block view display, then even if the Block display is alone on a page by itself, without the Data Export attached to it, the Apply button will still incorrectly have the URL to the data export.

I want to draw attention to this issue again.
This is a fairly old issue that is still reproducible and that would be desirable to close. I personally encountered this bug on 4 projects.
To resolve the bug caused by this issue, this patch or a custom hardcode has always been used.

I am not sure how to reproduce it on a clean core, but it is a fact that it has an impact on other modules (contrib/custom) that require the correct form action when using AJAX.

This patch does not make any major changes, but only adds an additional scenario for the case when the current route is 'views.ajax'

Added steps to reproduce in core. Patch works to fix this, although on the front page you are sent back to /node instead of /. Needs work for test coverage.

Added a test and rearranged the logic a bit

RTBS from my side
The patch works as expected and the new test looks good.

Many thanks to @mstrelan for providing the test

ViewsExposedForm hasn't been fixed yet.

@solideogloria I think that's a slightly different scenario and I think we should raise a separate issue. FWIW you can set the "Link Display" of the block display to a Custom URL (it's weirdly in the Pager part of the configuration) which would fix this issue.

Created 🐛 ViewsExposedForm has incorrect form submit URL if loaded through ajax Active

I'm triaging RTBC issues → . I read the IS.

The steps to reproduce look great, although I haven't tried them and rhere are still items in the remaining tasks. The proposed resolution says this was fixed in other cases. Are there other cases that need to be checked? Do we need a meta for this work? (I have not searched to see if one exists).

I then read the change record. Instead of a statement of the bug and the error it should include actions required by the reader to make any changes needed in their core or site.

Next, I started the test only job in GitLab.

I then read the comments them and see a followup has been made for Exposed forms. However, the proposed resolution implies that exposed forms have been fixed. This goes back to my questions about maybe needing a meta to organize the work. I also do not see that anyone has reviewed the MR and there are not comments on the MR.

Back to the test job. The results show the test ran successfully when it should have failed. It also has a deprecation notice. That needs to be sorted.

I have updated the remaining tasks with the items I found. Setting to needs work.

Marked 🐛 Exposed Form Reset button Inherits the page display URL when using as a block and AJAX Closed: duplicate as a duplicate of this.

Replying to #29

The proposed resolution says this was fixed in other cases. Are there other cases that need to be checked? Do we need a meta for this work? (I have not searched to see if one exists).

It's just pointing out other areas where similar bugs have been fixed. I only know of this issue and the other one 🐛 ViewsExposedForm has incorrect form submit URL if loaded through ajax Active so far so not sure we need a meta.

I also do not see that anyone has reviewed the MR and there are not comments on the MR

I've reviewed the MR, it looks good mostly but we need some work on the new constructor params.

It also has a deprecation notice. That needs to be sorted.

I don't see any failures in the gitlab pipelines, deprecations would trigger a failure? Where were you seeing it?

I've also rebased the MR.