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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webflo’s picture

Component: taxonomy.module » entity system
jsbalsera’s picture

Assigned: Unassigned » jsbalsera
jsbalsera’s picture

Assigned: jsbalsera » Unassigned
Status: Active » Needs review
FileSize
45.78 KB
134.94 KB
1.36 KB

First try to the schema, with images of the raw data and the form in config inspector.
Raw data.png

Raw configuration data for entity.display.node_.article.default | d8.local_.png

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.

tstoeckler’s picture

  1. +++ b/core/modules/entity/config/schema/entity.schema.yml
    @@ -0,0 +1,43 @@
    +  label: 'Entity Display settings'
    

    I think this should be just "Entity display"

  2. +++ b/core/modules/entity/config/schema/entity.schema.yml
    @@ -0,0 +1,43 @@
    +      label: 'Entity type to be displayed'
    ...
    +      label: 'Bundle to be displayed'
    ...
    +      label: 'View or form mode to be displayed'
    

    I think these should just be "Target entity type", "Bundle" and "View or form mode"

  3. +++ b/core/modules/entity/config/schema/entity.schema.yml
    @@ -0,0 +1,43 @@
    +      label: 'List of component display options, keyed by component name'
    

    I think this is a bit verbose as well. Maybe just "List of components"

  4. +++ b/core/modules/entity/config/schema/entity.schema.yml
    @@ -0,0 +1,43 @@
    +          mapping:
    +            label:
    +              type: label
    +              label: 'Label'
    +            type:
    +              type: string
    +              label: 'Type'
    +            settings:
    +              label: 'Setting'
    +              type: sequence
    +              sequence:
    +                - type: string
    +                  label: 'Setting'
    +            weight:
    +              type: integer
    +              label: 'Weight'
    

    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

    entity.display.component:
      type: mapping
      mapping:
        type:
          type: string
          label: 'Component type'
    

  5. +++ b/core/modules/entity/config/schema/entity.schema.yml
    @@ -0,0 +1,43 @@
    \ No newline at end of file
    

    Sad panda ;-)

jsbalsera’s picture

Assigned: Unassigned » jsbalsera
Status: Needs review » Needs work
jsbalsera’s picture

Assigned: jsbalsera » Unassigned
Status: Needs work » Needs review
FileSize
1.96 KB
1.02 KB
175.51 KB
185.9 KB

I'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:

id: node.article.default
uuid: 04764b49-2a0c-4ef1-ba13-1964411f0b3c
targetEntityType: node
bundle: article
mode: default
content:
  body:
    type: text_default
    weight: '2'
    settings: {  }
    label: hidden
  field_tags:
    type: taxonomy_term_reference_link
    weight: '1'
    settings: {  }
    label: above
  field_image:
    type: image
    weight: '0'
    settings:
      image_style: large
      image_link: ''
    label: hidden
  comment:
    type: comment_default
    weight: '3'
    settings: {  }
    label: hidden
  language:
    weight: '4'
    visible: '1'
status: '1'

The Form tab in Config inspector:
Form with generic schema_2.png

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:

entity.display.component.*:  
  type: mapping
  label: 'Text Default'
  mapping:
    label:
      label: 'Label'
      type: label
    type:
      label: 'Type'
      type: string
    settings:
      label: 'Settings'
      type: sequence
      sequence:
        - type: string
          label: 'Settings'
    weight:
      label: 'Weight'
      type: integer

If I create the next schemas for text_default (in the same entity.schema.yml) and for image (image.schema.yml) as follows:

entity.display.component.text_default:
  type: mapping
  label: 'Text Default'
  mapping:
    label:
      label: 'Label'
      type: label
    type:
      label: 'Type'
      type: string
    settings:
      label: 'Settings'
      type: sequence
      sequence:
        - type: string
          label: 'Settings'
    weight:
      label: 'Weight'
      type: integer
entity.display.component.image:
  type: mapping
  label: 'Image'
  mapping:
    label:
      label: 'Label'
      type: label
    type:
      label: 'Type'
      type: string
    settings:
      label: 'Settings'
      type: mapping
      mapping:
        image_style:
          type: string
          label: 'Image Style'
        image_link:
          type: string
          label: 'Image Link'
    weight:
      label: 'Weight'
      type: integer

The resulting form screenshot is:
Form with image and text_default schemas_2.png

Status: Needs review » Needs work

The last submitted patch, entity_display_schema-2096365-6.patch, failed testing.

jsbalsera’s picture

Status: Needs work » Needs review

The test doesn't fail in my local system, and it shouldn't be related, so marked as re-test

jsbalsera’s picture

Status: Needs review » Needs work
Issue tags: +Configuration system, +D8MI, +language-config, +Configuration schema

The last submitted patch, entity_display_schema-2096365-6.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
60.64 KB
18.62 KB
18.58 KB

Adding all missing schema bits for entity_display. Checked few with config_inspector and looks fine.

YesCT’s picture

  1. +++ b/core/modules/comment/config/schema/comment.schema.yml
    @@ -0,0 +1,11 @@
    +entity_display.field.comment_default:
    +  type: entity_field_display_base
    

    I'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

  2. +++ b/core/modules/datetime/config/schema/datetime.schema.yml
    @@ -0,0 +1,41 @@
    +entity_display.field.datetime_default:
    

    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.

YesCT’s picture

FileSize
14.52 KB
+++ b/core/modules/comment/config/schema/comment.schema.yml
@@ -0,0 +1,11 @@
+      label: 'Settings'
+      sequence:
+        - type: string

where 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
string-schema-configform.png

YesCT’s picture

FileSize
36.21 KB
+++ b/core/modules/text/config/schema/text.schema.yml
@@ -99,3 +99,105 @@ field.text_with_summary.value:
+entity_display.field.text_trimmed:
...
+entity_display.field.text_trimmed:

cut and paste duplication, was this meant to cover an additional text field type?

how do these text types map to the field types?
types-forschema.png

YesCT’s picture

FileSize
390.51 KB
139.49 KB

Are 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.
unknown-schema-display.png

[edit: looking at the article ui page, and the config inspector form for article teaser]
article-schema-configform.png

YesCT’s picture

FileSize
292.92 KB

corrected file.

YesCT’s picture

Took me a while to understand exactly what I'm looking at here.

field instance settings
another-longtextfield-instance.png

global field settings
another-longtext-globalfieldsettings.png

display mode (view or form, view in this case) settings
another-longtextformatdefaultdisplaysettings.png

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.

YesCT’s picture

I 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

vijaycs85’s picture

Thanks @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

+++ b/core/modules/entity/config/schema/entity.schema.yml
@@ -0,0 +1,30 @@
+# Overview configuration information for view mode or form mode displays.

This is only for view mode. form mode is a separate issue.

All others looks good to me. +1 to RTBC.

vijaycs85’s picture

Status: Needs review » Needs work

Realised that we have got few plugins of form display in this patch. Going to remove them.

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
7.96 KB
13.71 KB

Updated patch with widget removed.

vijaycs85’s picture

Issue summary: View changes
Status: Needs review » Closed (duplicate)
Related issues: +#2167623: Add test for all default configuration to ensure schema exists and is correct

The 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.