Undefined array key 0 in Drupal\views_ui\ViewEditForm->

Checked locally:
`php -l core/modules/views_ui/src/ViewEditForm.php`
`php -l core/modules/views_ui/tests/src/Functional/FilterUITest.php`
`vendor/bin/phpcs --standard=core/phpcs.xml.dist core/modules/views_ui/src/ViewEditForm.php core/modules/views_ui/tests/src/Functional/FilterUITest.php`

Result: syntax checks and PHPCS pass.

The attached patch includes functional test coverage and is ready for testbot review.

Thanks, I’ll move this into an issue fork / merge request.

Hi akhilsoni, The steps to reproduce involve installing a contrib module. Can it be reproduced without using any contrib modules? If this is a bug in core then it should be reproducible with core modules/ themes only.

Thanks for reviewing @oily.

I agree that a pure core reproduction is ideal. However, I think this still points to a core Views UI robustness issue rather than only a Facets issue.

The actual failure happens in core when a filter references a group ID that no longer exists in filter_groups. In that situation, ViewEditForm::getFormBucket() falls back to group 0, but the configured groups may start at 1, so $group_info['groups'][0] does not exist and the Views UI breaks.

The MR includes a core-only functional test that reproduces the broken state by loading the core test_filter_groups view and setting a filter to reference a missing group. That avoids requiring Facets/Search API in the test coverage while still exercising the same invalid/stale Views configuration state.

Facets is one way this state can be created in real sites, but once the Views config contains a missing group reference, core should not fatally break the edit UI. The proposed change makes core fall back to the first configured group instead of assuming group 0 exists.

So I believe this is valid for core, with Facets acting as the real-world trigger rather than being required for the core test case.

An extensive effort is underway to convert Functional tests to Kernel or Unit tests wherever possible. Doing this makes test runs faster and cheaper. Kernel tests are now capable of making requests with drupalGet(); see the change record. The new test that is being added by the MR appears to only take actions that are now capable of being performed by Kernel tests. Please check to see whether the test may be re-implemented as a Kernel test, perhaps extending ViewsKernelTestBase.

Thanks for the review. I updated the MR to move the added coverage from a Functional test to a Kernel test using ViewsKernelTestBase. The test covers the same missing filter group scenario by loading the core test_filter_groups view, setting one filter to reference a group that no longer exists, and confirming the Views UI edit page still renders successfully. Moving back to Needs review.

Thanks for the review. I updated the MR to move the added coverage from a Functional test to a Kernel test using ViewsKernelTestBase.
The test covers the same missing filter group scenario by loading the core test_filter_groups view, setting one filter to reference a group that no longer exists, and confirming the Views UI edit page still renders successfully. Moving back to Needs review.

Thank you for putting in the extra effort to make sure our test suite stays lean and fast.

Unfortunately, there is a problem with the test that I didn't catch yesterday. The test doesn't demonstrate the issue when executed without the fix. I discovered the problem because I wanted to write steps to reproduce the issue using only Core. Theoretically this should be possible by doing what the test does: edit a view, import it, then visit the view's edit page. So I did that. There was no error. I ran the test-only job to see if it has the same problem. It does. The test-only job passes when it ought to fail.

@dcam Good thinking. I did look at the test myself as I wondered why we would need a contrib module for Steps to reproduce. It did look pretty simple and I also found it difficult agree with the idea of involving the facets module. This could be postponed pending further info. But fair to give @akhilsoni time to address these things.

Good catch @dcam, and thanks @oily.

I looked into why the test passed without the fix: in ViewEditForm::getFormBucket(), the intra-group operator (AND/OR) is only rendered when there are two or more filters in the same group. With only one filter, that code path is skipped, so $group_info['groups'][0] is never accessed.

Once two or more filters share a missing group, Views UI tries to look up the operator for group 0, which doesn't exist, and throws Undefined array key 0. That matches the original report about needing "two or more facets" to trigger it.

Core-only steps to reproduce:

1. Edit any view with grouped filters (e.g. groups 1 and 2 configured).
2. Export the config and edit the YAML so two filters point to group: 3 (a non-existent group).
3. Import the view and visit the edit page.
4. On unpatched core, it throws Undefined array key 0 in ViewEditForm.php. With the MR, it falls back cleanly to the first group.
5. I've updated the MR's kernel test to set two filters to the missing group so the test-only run will now fail without the fix as expected.

Moving back to Needs review.

Hi, Thank you for the work akhilsoni.

But concerning

Export the config and edit the YAML so two filters point to group: 3 (a non-existent group).

if you start editing exported YAML's all kinds of things will happen that do not mean there is a bug..