Convert conditions into deployable config files

[jenlampton]

Right now all the conditions on fields are stored in the database. it would be nice to convert this to config so that these configurations can be deployed across sites.

[laryn]

This sounds like a good idea to me.

[laryn]

Here's what the database structure looks like currently:

So we'll need to figure out a new way of referencing the ID of the conditional, such as a concatenation of values that will be unique (and can maybe be used in the config file name structure).

Maybe entitytype.bundle.dependee.dependent -- but one thing to consider is that currently multiple conditionals could apply to this structure, as shown above, and currently each dependency has its own ID and row in the database. If we did it this way we'd need to combine multiple conditionals that deal with the same fields into the same config file somehow.

Another alternative would be to ask for a machine name when creating a new dependency, perhaps?

@jenlampton Do you have any thoughts on approach here?

[yorkshire-pudding]

I wonder whether just grouping by content type (entitytype.bundle) would be simpler (e.g conditional_fields.entitytype.bundle as the filename) and then allow multiple conditions keyed by the id in each. We do a similar thing in layouts config I think.

[laryn]

@yorkshire-pudding Do we have a way of generating IDs? Or would we need to ask for a name/machine_name when adding a conditional?

[yorkshire-pudding]

@laryn - I had two thoughts for the id:

1. simple incremental integer per content type (for existing sites you could just take the existing ID field so interconnections work). As the AND / OR would only apply within a content type, you shouldn't have any clashes.
2. Use a UUID like blocks do in the layout config.

[argiepiano]

@laryn, I would organize this as follows:

• Name of file: conditional_field.<entity_type>.<bundle>.<dependent_field_name>.json. For example, for a field field_field_c attached to node bundle lemonade, that depends on field_field_a attached to the same bundle, the file name would be conditional_field.node.lemonade.field_field_c.json. This makes the loading easy. I assume that, in the current code, when you load the conditions for a field attached to an entity type and bundle, you want to load ALL the conditions for that field.
• Content of the file as follows (each condition is keyed by UUID). Each condition has its own UUID. I wouldn't use the dependee field to key this, since you can have more than one condition for a given field with the same dependee field. The options are basically the same as the ones saved in the DB.

{
  "<UUID>" : {
    "dependee": "node.lemonade.field_field_a",
    "dependent": "node.lemonade.field_field_c",
    "options": {
      "state": "visible",
      "condition": "value",
      "grouping": "AND",
      "effect": "show",
      "effect_options": [],
      "element_view": {
        "1": "1",
        "2": "2",
        "5": 0,
        "3": 0,
        "4": 0
      },
      "element_view_per_role": 0,
      "element_view_roles": {
        "anonymous": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "authenticated": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "editor": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "administrator": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        }
      },
      "element_edit": {
        "1": "1",
        "3": 0
      },
      "element_edit_per_role": 0,
      "element_edit_roles": {
        "anonymous": {
          "1": "1",
          "3": 0
        },
        "authenticated": {
          "1": "1",
          "3": 0
        },
        "editor": {
          "1": "1",
          "3": 0
        },
        "administrator": {
          "1": "1",
          "3": 0
        }
      },
      "selector": "",
      "values_set": "1",
      "value_form": null,
      "value": [
        {
          "value": null
        }
      ],
      "values": []
    }
  }
}

Technically you don't need "dependent": "node.lemonade.field_field_c", since that's in the file name, and will be repeated for each condition in the file.

This also means you can get rid of the numerical IDs. Numerical IDs don't make sense when storing config.

[argiepiano]

A bit more detail here. I'd add the root keys label and type to allow the Config API to create individual entries in the Export page.

{
  "_config_name" : "conditional_field.node.lemonade.field_field_c",
  "label": "Conditions for field Field C - Entity: Node, Bundle: Lemonade",
  "type": "node.lemonade.field_field_c",
  "<UUID>" : {
    "dependee": "node.lemonade.field_field_a",
    "dependent": "node.lemonade.field_field_c",
    "options": {
      "state": "visible",
      "condition": "value",
      "grouping": "AND",
      "effect": "show",
      "effect_options": [],
      "element_view": {
        "1": "1",
        "2": "2",
        "5": 0,
        "3": 0,
        "4": 0
      },
      "element_view_per_role": 0,
      "element_view_roles": {
        "anonymous": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "authenticated": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "editor": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        },
        "administrator": {
          "1": "1",
          "2": "2",
          "5": 0,
          "3": 0,
          "4": 0
        }
      },
      "element_edit": {
        "1": "1",
        "3": 0
      },
      "element_edit_per_role": 0,
      "element_edit_roles": {
        "anonymous": {
          "1": "1",
          "3": 0
        },
        "authenticated": {
          "1": "1",
          "3": 0
        },
        "editor": {
          "1": "1",
          "3": 0
        },
        "administrator": {
          "1": "1",
          "3": 0
        }
      },
      "selector": "",
      "values_set": "1",
      "value_form": null,
      "value": [
        {
          "value": null
        }
      ],
      "values": []
    }
  }
}

The config hook would look like:

function conditional_fields_config_info() {
  $prefixes['conditional_field'] = array(
    'name_key' => 'type',
    'label_key' => 'label',
    'group' => t('Conditional Fields'),
  );
  return $prefixes;
}

[yorkshire-pudding]

What @argiepiano says makes a lot of sense

[herbdool]

That looks pretty good. I was going to suggest looking at the config structure for module in D9 for ideas.

[laryn]

@herbdool Interestingly it looks like in D9/D10 it doesn't create its own config file but inserts it into a core config file (e.g. in this test case core.entity_form_display.node.page.default.yml). Excerpt:

content:
  body:
    type: text_textarea_with_summary
    weight: 7
    region: content
    settings:
      rows: 9
      summary_rows: 3
      placeholder: ''
      show_summary: false
    third_party_settings:
      conditional_fields:
        21a940de-bd68-40f8-b718-6a305c8d4d2e:
          entity_type: node
          bundle: page
          dependee: field_toggle_test
          settings:
            state: visible
            reset: false
            condition: checked
            grouping: AND
            values_set: 1
            value: ''
            values: {  }
            value_form:
              value: false
            effect: show
            effect_options: {  }
            selector: ''
        2c1b27de-d10f-4c25-b00f-e25e1baf91ad:
          entity_type: node
          bundle: page
          dependee: field_toggle_test
          settings:
            state: '!empty'
            reset: false
            condition: checked
            grouping: AND
            values_set: 1
            value: ''
            values: {  }
            value_form:
              value: false
            effect: fill
            effect_options:
              fill:
                value: asdf
                reset: 1
            selector: ''