Remove epp default dependency in all fields config sync files

#6 adds a custom submit handler that avoids storing anything if no EPP config was set.

I elected to keep the config if either setting (value or on_update) is non-empty, rather than just the value as originally proposed. Easy enough to change if desired.

In my testing, this solves the issue for new installations (empty data is never saved), and removes existing 'empty' config data if the field config is updated/re-saved. I guess an ideal resolution would also implement an update hook to clean up any existing 'empty' config data. The data isn't really doing any harm, but maybe some kind soul wants to write that update hook. 😀

I edited the IS summary and steps to reproduce a bit. All field config files are not modified immediately upon enabling EPP. Only when a field is added or edited.

Ugh, forgot to set to NR.

Thanks for working on this!
I agree with how to handle the "empty" check.
I'm fine with having the update hook in a followup issue (can you open that?).

The MR needs work in one point:
Using "submit" is too brittle, we've had issues with that, and there is a way better alternative:
Look into \Drupal\Core\Entity\EntityForm::buildEntity, there you see how #entity_builders is used.
Add your #entity_builders instance, and adjust the fieldConfig->getThirdPartySetting() value that was copied there by ::copyFormValuesToEntity.

Nice! Thanks for pointing me in the right direction.

Last change uses an entity builder instead of a submit handler. I didn't want to over complicate things, so I explicitly check the two current settings. I can switch to iterating over the settings instead if you think others might be added later making this approach too brittle.

Yes that's the direction. But you should only refer to $fieldConfig (not $formState) in the entity_builder, and can unsetThirdPartySetting('epp') so we won't have an empty array left. And nice if you can do a manual test.

Sorry, just to be clear, which direction: 1) the current approach with explicit setting, or 2) iterate over the settings?

Also, unsetThirdPartySetting() requires a setting key as the second parameter, but ConfigEntityBase::unsetThirdPartySetting removes the empty array if all settings are unset.

> Also, unsetThirdPartySetting() requires a setting key as the second parameter, but ConfigEntityBase::unsetThirdPartySetting removes the empty array if all settings are unset.

Yes you are right, i forgot that.

> which direction: 1) the current approach with explicit settings,

Yes, this is well-chosen!

Great, thanks! Latest change removes usage of $form_state.

I've tested this manually on a clean Drupal 9 instance by:

1. Setting one, both or neither value on a plain text field
2. Export config
3. Check the resulting changes to field.field.[content-type].[bundle].[field_name].yml

Works as expected. Relevant bits of the config file excerpted below:

Both values set:

dependencies:
  config:
    - field.storage.node.field_test_epp_1
    - node.type.page
  module:
    - epp
third_party_settings:
  epp:
    value: '[current-user:display-name]'
    on_update: 1

Only 'on_update' set:

dependencies:
  config:
    - field.storage.node.field_test_epp_1
    - node.type.page
  module:
    - epp
third_party_settings:
  epp:
    value: ''
    on_update: 1

Neither value set:

dependencies:
  config:
    - field.storage.node.field_test_epp_1
    - node.type.page

I did the same for a base field (body), with the same results.

Yup, we got it, code LGTM, and you did a manual test and described it well.

Thanks for the improvement. It was a pleasure!
Commited and tagged a new version.

🙌 Excellent, thanks! I enjoyed working with you.

Automatically closed - issue fixed for 2 weeks with no activity.