This is a sub-issue of #1910624: [META] Introduce and complete configuration schemas in all of core.
Problem/motivation
#1866610: Introduce Kwalify-inspired schema format for configuration introduced some config schema coverage for views, but it is not complete. The changelog leads to (hopefully extensive) documentation on the format at http://drupal.org/node/1905070. While there are little cleanups planned for the format overall, the current format is a result of months of back and forths, so it should be perfectly fine to apply it more widely to core.
Proposed solution
Figure out the missing pieces that are not yet covered. Write schema file sections for them. Clean up / fix any issues in current schema.
Create a configuration schema for entity type entity_display.
Comment | File | Size | Author |
---|---|---|---|
#21 | 2096365-entity_display-schema-21.patch | 13.71 KB | vijaycs85 |
#21 | 2096365-diff-17-21.txt | 7.96 KB | vijaycs85 |
#17 | another-longtextfield-instance.png | 144.84 KB | YesCT |
#17 | another-longtext-globalfieldsettings.png | 165.93 KB | YesCT |
#17 | another-longtextformatdefaultdisplaysettings.png | 143 KB | YesCT |
Comments
Comment #1
webflo CreditAttribution: webflo commentedComment #2
jsbalseraComment #3
jsbalseraFirst try to the schema, with images of the raw data and the form in config inspector.
I think that there is still work to do, because each content item should have the key, and same applies to settings into each content.
Comment #4
tstoecklerI think this should be just "Entity display"
I think these should just be "Target entity type", "Bundle" and "View or form mode"
I think this is a bit verbose as well. Maybe just "List of components"
Just discussed this with @GáborHojtsy, @vijaycs85 and @jsbalsera in person. This is going to be a little bit more complicated, as this mixes configurable fields and extra fields. So we will have to provide a generic "entity.display.component" schema type. Something like
Sad panda ;-)
Comment #5
jsbalseraComment #6
jsbalseraI've tried to create a generic component schema, but trying to use the type to let the specific schemas to be provided.
The raw data:
The Form tab in Config inspector:
It results in some warnings, because the settings are arrays and we try to process them like strings. Perhaps it makes sense to expand the generic schema like the normal file one and then the specific fields have to provide theirs, like in language. The proposed schema would be:
If I create the next schemas for text_default (in the same entity.schema.yml) and for image (image.schema.yml) as follows:
The resulting form screenshot is:
Comment #8
jsbalseraThe test doesn't fail in my local system, and it shouldn't be related, so marked as re-test
Comment #9
jsbalsera#6: entity_display_schema-2096365-6.patch queued for re-testing.
Comment #11
vijaycs85Adding all missing schema bits for entity_display. Checked few with config_inspector and looks fine.
Comment #12
YesCT CreditAttribution: YesCT commentedI'm not sure where this is in the UI or the config inspector. I cannot find it.
Maybe in config inspector at?
admin/reports/config-inspector/entity.display.comment.node__comment.default/form
hm. can't find this one either.
I'll wait a bit for a hint, and then come back to the review.
Oh, I missed the screenshot @vijaycs85 had. Ah, in entity.display.node.article.default
OK. Next to figure out how to actually put some comment settings there. And find the date format stuff too.
Comment #13
YesCT CreditAttribution: YesCT commentedwhere does schema for the list/sequence of strings get picked up from?
I think this generates
String: some_machine_name_of_setting
String:
or an empty set
Comment #14
YesCT CreditAttribution: YesCT commentedcut and paste duplication, was this meant to cover an additional text field type?
how do these text types map to the field types?
Comment #15
YesCT CreditAttribution: YesCT commentedAre the settings really per format, I thought they might be per field. the Label hidden, above, below is a setting per type... but the format specifies the format. Hm. I guess the Label setting is saved per format. But that's a bit weird.
I added a text field.
when I did this, an "unknown" showed up.
[edit: looking at the article ui page, and the config inspector form for article teaser]
Comment #16
YesCT CreditAttribution: YesCT commentedcorrected file.
Comment #17
YesCT CreditAttribution: YesCT commentedTook me a while to understand exactly what I'm looking at here.
field instance settings
global field settings
display mode (view or form, view in this case) settings
Initially, I added display format settings to the labels for clarity. (along with some spelling fixes and whitespace, https://drupal.org/files/interdiff-11-partial17.txt)
So, since in entity.display.node.article.default for example, they are all display format settings, and they are in the "fields" group, so I think just using the label that represents the field format name is fine. So I took out 'display format settings'. ... then changed my mind again! ack. So leaving it in.
Actually, maybe "Fields" is misleading. As it is really "Field Formats". Because it doesn't actually know which field it is, or the field type, it just knows which field format it is. There is a list of the field formats for each field, but the info of the field is not included in the format, which is being specified. Maybe the config inspector/translate form that gets build could list the field info with the format .. although I dont see many "Labels" or "text" types that would be translatable, these really are just config settings. The Above label used for the setting of the Label to be above is specified in a schema somewhere else. This is just recording that it is using the 'above' setting, just a string, the machine name for the setting, not the "Above" label for that setting shown in the content type ui. Tricky tricky.
I tried to add a form mode to users, and.. uh, the manage fields for accounts/users is gone. Opening an issue for that. #2109937: Manage fields local tasks not displayed at admin/config/people/accounts
I have to go, but will come back to this.
Comment #18
YesCT CreditAttribution: YesCT commentedI tried a couple different ways of trying to look at form mode display config.
entity.display.user.user.compact
entity.display.user.user.default
are for view display modes.
I cannot find the config for the form display modes for default and register.
Also, I added content form display modes, but cannot see the subtabs on article, or find config files.
What is the naming pattern for form display mode config files?
ah, in entity.form_display.user.user.register.yml
why is this not picked up in config inspector and shown in admin/reports/config-inspector ? #2110493: entity form display mode config files not showing in config inspector
Comment #19
vijaycs85Thanks @YesCT. We don't have entity.form_display.*.*.* because we haven't done et :) The task is #2096367: Provide config schema for Entity form displays. So
This is only for view mode. form mode is a separate issue.
All others looks good to me. +1 to RTBC.
Comment #20
vijaycs85Realised that we have got few plugins of form display in this patch. Going to remove them.
Comment #21
vijaycs85Updated patch with widget removed.
Comment #22
vijaycs85The patch on this issue has been updated as part of #2167623: Add test for all default configuration to ensure schema exists and is correct. As this issue doesn't have any test to confirm/validate the schema, making this change and closing this issue as duplicate of #2167623: Add test for all default configuration to ensure schema exists and is correct. The contributors of this issue (in commit message) is copied to #2167623: Add test for all default configuration to ensure schema exists and is correct.