Invalid config structures can result in exceptions when saving a config entity

@Berdir
Did you figured out which part of the configuration was wrong in the first place? Ideally update.php should have finished already at that point int ime.

I rerolled the patch in #6 for Drupal 8.6.x.

rerunning tests putting in needs review

PHP message: Uncaught PHP Exception InvalidArgumentException: "The configuration property display.default.display_options.filters.field_xxx_target_id.value.min doesn't exist." at /core/lib/Drupal/Core/Config/Schema/ArrayElement.php line 76"

After applying the patch #10, i can save my view and error has gone !

Drupal 8.7.3

Thank you all

I can confirm this fixes the issue. I'm on Drupal 8.8. The patch also applies to 9.0.x.

I'd love to know how fix the underlying issue causing the exception.
EDIT: Figured it out. I provided a Views filter plugin that extended the Date one, but did not also provide config for it.

I'm not sure that the approach in this patch is correct. The problem is that is we stop processing the schema then the rest of the values in the view will not be correctly cast.

I think in order to do this correctly we should:

• Change the exception thrown by \Drupal\Core\Config\Schema\ArrayElement::get() to be something more specific.
• Catch this exception in \Drupal\Core\Config\StorableConfigBase::castValue()

Same problem trying to update views_bulk_operations module - Update #8034

Failed: InvalidArgumentException: The configuration property display.edita_elements.display_options.fields.views_bulk_operations_bulk_form.selected_actions.0.action_id.action_id doesn't exist. a Drupal\Core\Config\Schema\ArrayElement->get()

Not only works with invalid structures also protects for missing configs. Issue still needs work but in my case this patch fixes the problem without side effects.

The patch that takes the approach proposed in #14.

The patch from #18 fixes the bug for me. Thanks!

@BR0kEN thanks for the change in implementation.

We still need automated test coverage here.

+++ b/core/lib/Drupal/Core/Config/Schema/ArrayElement.php
@@ -72,9 +72,7 @@ public function get($name) {
-      throw new \InvalidArgumentException("The configuration property $name doesn't exist.");

+++ b/core/lib/Drupal/Core/Config/Schema/ConfigSchemaNoSuchPropertyException.php
@@ -0,0 +1,44 @@
+/**
+ * The exception to raise when the config schema has no given property.
+ */
+class ConfigSchemaNoSuchPropertyException extends \RuntimeException {

I think the new exception should extend \InvalidArgumentException for BC purposes.

@alexpott yeah, that makes sense.

Forgot to add the exception.

Needed this patch for the notify_to_slack module. Worked great on 9.1.6.

I tried the patch in #23 since I am in 9.2 and it fixed this issue.
In my case I was trying to save a search_api_language filter with the required option checked and a default language selected. (Just for reference).

While the view gets saved normally, I get the same error on config import.
Can someone else confirm this?

Edit: Not the same error (my bad)
The ConfigSchemaNoSuchPropertyException is the one I get, and since this is caught and logged in castValue, I guess it is normal to be shown in cli, so i guess this behaviour is intended. Is there any way to suppress this?

Otherwise I have no issue so far... +1 for RTBC.

@marios-anagnostopoulos - confirmed. I get the same behavior with patch #29 on 9.3.2

Edited to add: I seem to have solved the config-import error on my build by changing the plugin_id for the troublesome filter in views.view.VIEWNAME.yml from comment_ces_last_updated to numeric though I still need patch #29 to save the view via the UI (which does not overwrite the manually-updated plugin_id value).

Patch #29 works for me in 9.3.2

#33 this does not sound like an intended behavior.

I made an update for #29

Fixed CS errors.

The patch seems to be working, and the code changes look good.
Would it be possible to create a test, which fails without this patch?

Patch #29 works for me in 9.3.9

I was able to actually fix the config that was missing in my use case on Fatal error when trying to save a View, getting InvalidArgumentException (patch #33). With that fix in place, I was able to remove the patch from this thread.

Moving to NW for the tests.

Also since this bug was reported for 8.4 an issue summary update probably is needed.

Is this even still an issue?

I rerolled the patch in #10 for Drupal 9.4.x

Fixed errors after end test for Drupal 9.4.x

I has tested patches #37, #39 - its works, but strange behavior of them. After end of apply this patches they created 3 files:
- docroot/core/lib/Drupal/Core/Config/Schema/ConfigSchemaNoSuchPropertyException.php
- docroot/core/b/lib/Drupal/Core/Config/Schema/ConfigSchemaNoSuchPropertyException.php
- docroot/core/core/lib/Drupal/Core/Config/Schema/ConfigSchemaNoSuchPropertyException.php

@ankondrat4 when you upload a patch can you please upload an interdiff so we can see what changed.

#46 is failing testing and no interdiff was provided to help review.

Also needs IS update per the tag.

Sorry, interdiff 45-46

Started the IS update but if someone more familiar with the issue could fill in the missing pieces.

As far as the test failure in #46 with this change maybe that test should be updated?

@ankondrat4 you don't need to hide your files. If it's valid and helped move the issue forward leave up for others to help or comment on.

Took a shot at an updated IS.

Believe with this change the failing test case from #46 just needed to be updated.

Adding a tests-only patch as well from #46

@smustgrave, ok. Thank you.

That fix exception in config saving !

Test against 9.4.6 (php 8.1) => RTBC

as per #57

The patch in #54 is based on the patch in #45, but this a re-roll of the patch in #10 which undoes all of the work/feedback from #14 to #37.

I created an issue fork and pushed the changes up to #37 which apply to 10.1.x
I didn't include the tests provided #54 since the patch in that comment was based on the older implementations (as per #60) and because I was not sure if they would be relevant (as per #44)

If you think that they should be included, feel free to commit and update the issue.

The interdiff I provide is just the missing one between 29 and 37.

Confirmed patch #54 works for me on 9.5.3

Confirmed patch #54 works for me on 9.5.7

Confirmed patch #54 works for me on 10.1

Updated for 9.5.10

Updated for 9.5.11

#3347842: Deprecate the trusted data concept in configuration will remove the trusted data concept entirely, and I think what this issue is doing, ignoring config schema errors, is the complete opposite of all of the config schema validation work we've been doing lately.

This is because contrib/custom code doesn't always provide a correct schema, and instead of hiding the errors, I think we should guide maintainers to write correct and complete schema's.

For #65 watchdog_exception is deprecated. https://www.drupal.org/node/2932520

Updated for Drupal 10.3.0

@natnatalia Part for Config.php is present in version 10.3.0, so the patch cannot be applied. Maybe only the tests need updating

Re-roll #73 to remove the /site/ prefix that was preventing it from applying.

I can confirm that patch #75 works fine for Drupal 10.3.0. Thank you!

Hello,
#75 works with 11.0.4

Patch #75 works for 10.3.6, thank you! Putting more details here.

For our case, we are using a 'or' operator in views when filtering a taxonomy term.
Our config import was working in 10.2, but got error in 10.3.6

The configuration property display.block_1.display_options.filters.field_data_target_id.value.983 doesn't exist.

In the config yml, I removed the values with issues, and replaced with {} instead, and able to import. Then navigate to that view, tried to add back the 'or' filtering to that term and save:

InvalidArgumentException: The configuration property display.block_1.display_options.filters.field_data_target_id.value.983 doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 95 of core/lib/Drupal/Core/Config/Schema/ArrayElement.php).

Once patch #75 applied, both import and view saving are now working properly.

Patch #75 applies for 10.4.3.

Patch 75 no longer applies for 10.5.x - I've re-rolled it in https://git.drupalcode.org/project/drupal/-/merge_requests/12956/diffs and attached an updated patch.

Here is a re-rolled patch which works with Drupal 11.2.3.

Seems like it does not apply anymore, rerolled from #88

Patch for 10.5.3

Patch #85 (2925890-84.patch) works for me on Drupal 10.5.6