Sub-task of #2231059: [meta] Find out what config schemas are still missing and add them
Problem/Motivation
[#1910624]introduced configuration schema + test coverage for schema for default configuration in core. However there are still few areas that doesn't have schema coverage.
Proposed resolution
Provide config schema for below configurations:
language.settings
content_translation.settings
Comment | File | Size | Author |
---|---|---|---|
#17 | 2245721-diff-12-17.txt | 1.45 KB | vijaycs85 |
#17 | 2245721-language-config-schema-17.patch | 5.06 KB | vijaycs85 |
#12 | language-config-schema.png | 125.72 KB | vijaycs85 |
#12 | 2245721-language-config-schema-12.patch | 4.67 KB | vijaycs85 |
#12 | 2245721-language-config-schema-12-test_only.patch | 2.06 KB | vijaycs85 |
Comments
Comment #1
vijaycs85I see why we don't have schema for these configs. They don't have a file, but created at run time.
language.settings look like:
and content_translation.settings looks like this:
Updating schema for them.
Comment #2
YesCT CreditAttribution: YesCT commentedI read through all the lines. Looks fine.
How do we want to do these reviews? with the config inspector like before?
Or should we combine this patch with the one from #2231059: [meta] Find out what config schemas are still missing and add them as a testing.patch ? And see what fails go away with this?
Comment #3
vijaycs85Removing content_translation.schema.yml as it is part of #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration
Comment #4
YesCT CreditAttribution: YesCT commenteduploading same patch as in the meta from comment #23, and a patch with #3 and #23 from the meta to compare the difference in fails. (combined patch should fail less, and the fails should be related to language schema)
Comment #7
vijaycs85After the discussion at #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration, it looks like language.settings.*.* doesn't work(as pointed by @alexpott). We have to use the configuration name (i.e. language.settings). However we need #2248709: The root type of a configuration object can not be a sequence in, to make this change. For now the options are:
1. We may not need to write config schema from the decisions at meta of this issue.
2. Wait to get #2248709: The root type of a configuration object can not be a sequence and update schema with sequence.
3. Introduce one more mapping level like 'language.settings.entity' and update schema.
Comment #8
alexpott#2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration is going to end up handling the schema changes for this so we should postpone this on that - just so we check once that one is done that we've got the schema covered.
Comment #9
xjmThis issue is a beta blocker on its own, per discussion with @alexpott and @Gábor Hojtsy. Eventually it can probably be marked as a duplicate of #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration, but leaving as an explicit issue for now to be sure.
Comment #10
xjmComment #11
Gábor Hojtsy@vijaycs85: I think its best to avoid needing to do #2248709: The root type of a configuration object can not be a sequence and instead introduce one level of mapping in the file here. It is not a bad point that if we want to introduce further settings later in the file, that would let us do it as an API addition vs. an API change. More future compatible. Then #2248709: The root type of a configuration object can not be a sequence remains theoretical for contrib scenarios. Since this would be the only one needing it now that #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration is shooting for an entirely different approach.
Comment #12
vijaycs85thanks @Gábor Hojtsy for the direction. Here is a patch with below items:
1. Updated config & config schema with 'entities' at top
2. Added test case to validate the configuration settings.
3. Validated with config inspector.
Comment #13
Gábor HojtsyThe two layers of custom language settings looks odd. I think we have that so we are future compatible with more settings. However that is neither added nor changed here, so looks to me like it would be out of scope. Therefore let's get this in.
Comment #15
Gábor HojtsyThe fail was expected from the test only patch. This is still looking good :)
Comment #16
alexpottConsidering that you've made changes to the form I've it worth asserting that the config values have been saved correctly - just so we know the schema has something to test against. If the config was empty it would still pass :)
This looks odd since we're not doing it for the other entity types that could end up in this configuration object. We should replace this with
language_entity_bundle_delete()
but lets do that in a new issue.Comment #17
vijaycs85#16.1 - Updated test case to check.
#16.2 - Created followup - #2259175: Delete language specific configuration on uninstall/ entity type /bundle delete
Comment #18
Gábor HojtsyThanks for resolving those concerns. The delete question came up with the field instances as well earlier from @catch. So good point here as well :)
Comment #19
alexpottCommitted 26eb01c and pushed to 8.x. Thanks!
Comment #21
Gábor HojtsySuperb, thanks!