Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As mentioned in #1648930-228: Introduce configuration schema and use for translation, we have to support multiple %parents to access data from different levels. However it is not working. Sample of not working is at https://gist.github.com/vijaycs85/5402151
Comment | File | Size | Author |
---|---|---|---|
#14 | config_schema_parent-1972816-14.patch | 6.13 KB | yched |
#14 | interdiff.txt | 796 bytes | yched |
#13 | config_schema_parent-1972816-13.patch | 6.13 KB | yched |
#13 | interdiff.txt | 5.02 KB | yched |
#12 | config_schema_parent-1972816-12.patch | 1.18 KB | yched |
Comments
Comment #1
vijaycs85Comment #2
Gábor HojtsyI don't think we can call this a regression, we did not touch the parsing much since it was committed and this was not even in Drupal 7. Should be investigated nonetheless. I don't even know if this was supposed to work in the first place.
Comment #3
Gábor HojtsyComment #4
Gábor HojtsyLooks like one can cross-post with himself...
Comment #5
Gábor HojtsyLooking at the committed patch for schemas (http://drupal.org/files/1866610.47.config-schema_0.patch), there is no documentation nor code to make the kind of things like %parent.%parent work. The replacement handling code would replace any instance of %parent with only the immediate parent, there is no concept of going further up in nesting levels.
Therefore I'd consider this a task or feature request, not a bug (also retitled for this). Maybe some discussion indicated this would be useful to add, but this was not added or expected in the initial patch. My understanding in #1953404: Add config schema to field and instance config entities is that we can at least temporarily avoid doing this and have a little more verbose schemas as a result.
Comment #6
yched CreditAttribution: yched commentedA little more verbose but also architecturally incorrect, since this forces schema snippets to redefine over and over again some schema properties about a structure that's actually enforced by the container structure.
So we have to trust 10s of schema snippets to properly expose a schema that's actually not their responsibility but the one of the container - only the container cannnot expose it itself because of syntactic limitations in the include mechanism.
This definitely qualifies as a bug IMO. A bug for which there is a known workaround, but still a bug.
Comment #7
vijaycs85Current implementation of %parent and %key only concern about immediate parents rather history. Also it saves the whole level-1 data in $replace[%parent]. so not sure how effective it would be to have $replace[%parent][%parent] with multiple set of data. Here is a work around for this problem: https://gist.github.com/vijaycs85/5433410
1. As per https://gist.github.com/vijaycs85/5433410#file-field-instance-default-ym... would have field_type in individual default value.
2. https://gist.github.com/vijaycs85/5433410#file-field-instance-default-ym... - Sequence will be part of main schema definition
flip side, would ask individual default value to provide field_type and same would happen for any other instance.
Comment #8
Gábor HojtsyI think we should be able to replace repeated instances of %parent with %parent0, %parent1, etc, and then traverse the config tree to build up the replacement array with parents?
Comment #9
vijaycs85Comment #10
Gábor HojtsyIt is a lie that we have people working on this.
Comment #11
jair CreditAttribution: jair commentedMoving back to active, since there doesn't seem to be a patch yet.
Comment #12
yched CreditAttribution: yched commentedPatch "should" work.
Did not test it on an actual example yet, plus the %parent replacement logic doesn't seem to be covered by tests currently.
ConfigSchemaTest only checks "typed definitions" that still contain unreplaced [%parent.id] tokens. It still passes if I comment out the code that does the actual replacement in TypedConfigManager.
Hints welcome: how do you retrieve the fully resolved schema for a config file, so that you can you can check replacements were correct ?
Comment #13
yched CreditAttribution: yched commentedOK, figured it out.
Now with tests. I think we're good here.
Comment #14
yched CreditAttribution: yched commentedOf course, you only notice typos after posting the patch...
Comment #15
vijaycs85Thanks @yched, patch in #14 looks good to me. RTBC from my side.
Comment #16
Gábor HojtsyWoot, this looks amazing. I did not even expect this may be resolved without a huge refactoring. Wow :) Thanks!
Comment #17
catchLooks good. Committed/pushed to 8.x, thanks!
Comment #18
Gábor HojtsyYay thanks!