Rerolled #38 for 10.3.x branch (it also applies to 11.x). There's something not quite right in #40 it's missing a variable name. I couldn't reproduce the TypeError either. I'll push this to an MR for 11.x as well.
You can either download the (patch/diff) file from the merge request (from the code dropdown) and use it from a local path in your composer file or just add .diff or .patch to the merge request URL and use that as your patch file URL in composer.
This looks good to me. Need to switch the merge branch to 3.x now though.
This needs re-rolled for the new version. I'll see if I can get that done.
Ah I see the dispatch method changed from Drupal 9.5, but this should still be the correct order as it was marked as changing in Drupal 10.
This fixes the warning you get when cron runs and it can't find the plugin info when determining cron lease time (Line 264 of core/lib/Drupal/Core/Cron.php).
Also, the dispatch method had the parameters switched. I see this was done when trying to fix issue #3336482 but I do not believe this is correct as it the dispatch method expects the event first.
nrogers → created an issue.
Yes, I agree this seems like the target should just be 10.1. Especially since 10.2 isn't officially released yet and it makes Drupal think it's unsupported on 10.1 so it's sending me unsupported module emails.
This works great and looks good to me! +1 RTBC
I ran into the issue in #95 while writing the tests and I don't think it's related to this issue. I think it should be opened as a separate issue as it happens when a filter is required but has the "All" option checked for checkbox options.
Ok, I have added the regression test as well.
Ok, I added back the boolean plugin exclusion you had in there before. I don't quite follow why that value isn't in the form state, seems to be a behavior of the status or admin media filter, but that passes the tests anyway.
I found this problem also occurred with a webform plugin we were using and decided hard coding the plugin id types was a bad idea. So I reworked the patch to just test for any input regardless of plugin type. I also moved the code outside of the reset button loop so that it works when the form does not contain a reset button. This does not cause the regression in #77 as it's looking at the form state for the input values instead of the view. I also added a test to demonstrate the problem, however, I don't have much experience with tests so if I need to change anything let me know. Opened a new merge request for 11.x, I don't think I have permissions to close the other one.
I modified the previous patch to only exclude required exposed text filters from auto processing. I only excluded 'string' and 'combine'. I'm not sure if there are other text plugin ids that should be excluded as well, but these are two that I came across when I encountered this issue. I did verify this does not cause the regression outlined in #77.
nrogers → made their first commit to this issue’s fork.
I can confirm the caveat in #155, "Control visibility" doesn't show up for me on a page where blocks were already placed until I move the block to a new section or remove and re-add the block. However, it did work on another page where there was only one section present.