Problem/Motivation
FilterPluginBase::groupForm() initializes $groups in a conditional that may not always be true and then uses it outside that conditional.
Notice: Undefined variable: groups in Drupal\views\Plugin\views\filter\FilterPluginBase->groupForm() (line 761 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).
Steps to reproduce
Install standard profile
Edit the Content view and click on the Content: Published filter
Uncheck the Optional checkbox
Click Remove in both items under the Group options table
Save the filter
You'll get an error on save " Oops, something went wrong. Check your browser's developer console for more details. "
In the logs:
Uncaught PHP Exception TypeError: "count(): Argument #1 ($value) must be of type Countable|array, null given" at /data/app/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php line 1002
Proposed resolution
Initialise $groups before using it.
Remaining tasks
Do it
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-2339921
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:
- 2339921-undefined-variable-groups
changes, plain diff MR !8402
Comments
Comment #1
dawehnerLet's better define $group = []; by default
Comment #2
almaudoh commentedDone.
I looked further into why my exposed filter was not displayed after I applied this patch and found that I had omitted to define the title when creating the views exposed filter. While that was entirely my fault, it would have saved me a lot of time and effort if the exception thrown was more like 'Your grouped view filter will not be displayed if you don't specify a title'.
Comment #3
jhedstromPatch in #2 still applies with fuzz, but should be rerolled for the testbot.
Comment #4
adci_contributor commentedRerolled. Please review.
Comment #5
dawehnerThank you for the reroll!
Comment #6
jhedstromI added a beta phase evaluation to the issue summary.
Comment #7
almaudoh commentedGreat job, guys! I'm wondering if it would be too much scope creep to add #2
Comment #8
webchickHm. Sounds like we are missing some test coverage here?
Comment #9
webchickComment #10
jhedstromTest coverage for this specific error will be non-trivial, given that from what I can tell, there is currently zero coverage of any of these form methods. (Not that it wouldn't be valuable though.)
Comment #11
jhedstromI filed a follow-up issue #2421023: Create tests for FilterPluginBase form methods to add tests. As I said above, it will be non-trivial, and since this is such an obvious bug fix, I don't think it need be blocked by that task.
Comment #12
alexpottComment #13
jhedstromAdding some related issues.
Comment #14
sudheeshps commentedComment #15
sudheeshps commentedComment #16
pwieck commentedComment #18
Anonymous (not verified) commentedAs @sudheeshps and @pwieck are wordlessly suggesting, the patch in #4 still applies. So RTBC'ing.
@alexpott: seems you tried committing the patch from #2 iso the rerolled one in #4 :)
Comment #19
alexpottGiven the fact that there are tests see #2421023: Create tests for FilterPluginBase form methods perhaps we can test this.
Comment #20
Anonymous (not verified) commentedWould this be a good start for the test?
Comment #21
Anonymous (not verified) commentedThis patch will fail because of a bug unrelated to this issue: for some reason, after changing the group to "OR" an escaping issue occurs (cf. 2339921_filter_display_bug.png ).
A second issue that came up, is that there is no "Create new filter group" available during the test (cf. other screenshots).
I'd vote to get #4 in, and handle all test coverage in #2421023: Create tests for FilterPluginBase form methods. The issues that come up, could then be handled in child issues and this patch wouldn't be held up.
Comment #23
Anonymous (not verified) commentedI made a seperate issue for the filter display problem: #2432759: views filter formatting in or group
I added the same test coverage there to demonstrate the issue, so I'm hiding the patch from #20 and #21 for now.
Comment #24
Anonymous (not verified) commentedI found an issue that describes the exact problem I encountered while writing a test.
Comment #25
Anonymous (not verified) commentedThe issue in #23 got in, not sure if we need the one from #24 as well, so I'm going to let testbot run over this again.
Comment #28
almaudoh commentedusing local domain name here will likely fail on testbot
Comment #29
Anonymous (not verified) commentedOh yes. Thanks for the pointer!
I looked over the patch again, and this will still not pass since "<" is encoded wrong. I think there is an issue for that somewhere.
Comment #31
aerozeppelin commentedAn attempt to reproduce the error and write tests for it
Comment #32
aerozeppelin commentedWhile writing tests for this, i encountered this notice,
Notice: Undefined index: #states in Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedFiltersGroupForm()Here is a fix for it.Comment #41
guerinteed_mike commentedStill seeing issue -> core 8.6.3
Comment #42
dawehnerIMHO we should not
a) Let's remove the
@file commentb) Extend
\Drupal\Tests\views_ui\Functional\UITestBaseinstead and write a browser based test.We have a test now though.
Comment #49
quietone commentedSearching for duplicates I found #3277134: Count Argument is null and it brings to fatal error when upgrading from PHP 7.4 to PHP 8.1 which is addressing the same problem. I am closing that one in favor of this earlier issue.
The change starting here is out of scope.
Closing #3277134: Count Argument is null and it brings to fatal error when upgrading from PHP 7.4 to PHP 8.1 as a duplicate.
Comment #50
medha kumariRerolled patch #32 in 9.5.x .
Comment #51
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #54
pcambraI think patch in #50 is removing a bunch of stuff, added a MR bringing #32 up to date, it works for my use case.
Setting to NR to clarify what's left.
Comment #56
pcambraComment #57
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
Comment #58
acbramley commentedFigured out how to reproduce this one, updating IS.
Comment #59
acbramley commentedFunnily enough fixing this error starts throwing more:
Warning: Undefined array key "status" in Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput() (line 1619 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).and
Warning: Undefined array key "status" in Drupal\views\Plugin\views\filter\FilterPluginBase->convertExposedInput() (line 1505 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).Comment #60
acbramley commentedComment #61
smustgrave commentedTest coverage appears here https://git.drupalcode.org/issue/drupal-2339921/-/jobs/7228657 I tried to find an existing test that maybe we could expand but this could be expanded on in the future maybe.
Code was seems straight forward and no objections
Going to mark
Comment #62
quietone commentedComment #63
alexpottCommitted 6419400 and pushed to 11.x. Thanks!
Committed ffcc4c3 and pushed to 11.3.x. Thanks!
Comment #67
idebr commentedThis is causing new warnings in tests:
See https://git.drupalcode.org/issue/drupal-3463868/-/pipelines/702131/test_...
Comment #69
alexpottReverted... we need to fix that.
Comment #71
alexpottI rebased the branch MR on top of 11.x so it should fail the same way as HEAD did.
Comment #72
alexpottI've fixed the MR up to not use NULLs as a value for $selected_group.
Comment #73
godotislateMR needs to be rebased against HEAD. Tests are failing because the 11.x commit for #3557585: Update to Composer 2.9.2 is missing.
Also, it might be a good idea for a follow up to document the params and and return type of
FilterPluginBase::convertExposedInput().Comment #74
acbramley commentedRebase came back green
Comment #75
godotislatelgtm
Comment #76
alexpottSecond time lucky...
Committed and pushed b2c0b060da2 to 11.x and f1f4db7022c to 11.3.x. Thanks!