Domain Access support for Metatag D8/9/10

I can confirm what @Lukas von Blarer is seeing. For each domain, for the same configuration, the UUID is the same.

Example:
domain.config.domain_a.metatag.metatag_defaults.node__article.yml
domain.config.domain_b.metatag.metatag_defaults.node__article.yml
metatag.metatag_defaults.node__article.yml

All three have the same UUID.

However, this is true for other configuration files outside of metatag, e.g. system.site.yml. So I don't think this is the root cause of the problem.

Or, maybe it does have something to do with the UUID after all. There is an open issue in the domain project, 🐛 Using Domain Config UI creates *.yml files with duplicate UUIDs. Needs work .

As best I can tell, the UUID issue is a red herring. Having unique UUIDs didn't fix the problem for me.

It appears that configuration edit forms, by default, ignore overrides. The domain_config module adds module overrides to the configuration behind the metatags_default configuration entity. The only fix I could come up with is for the entity form to buck the default behavior and actually take overrides into account.

Patch attached. I'm interested in others' thoughts on this approach. It addresses the issue, but I don't know if departure from the default behavior is the right answer.

Thanks for all the work here on this! +1

As best I can tell, the UUID issue is a red herring. Having unique UUIDs didn't fix the problem for me.

Possibly a side by side finding here which maybe needs another issue to be opened.

I don't know if departure from the default behavior is the right answer.

It rarely is.

It appears that configuration edit forms, by default, ignore overrides.

This is somewhat misreadable and I am not sure yet what you mean. What "configuration EDIT forms" you refer to? Are you referring to the Drupal admin setting edit forms which contribute to the configuration data system in general or do you refer to the configuration files? By default Drupal has only import and export config forms, no edit forms. The terminology edit form brings other associations to me (html input forms etc) than what you mean, I think. Can you help clarifying this term?

Drupal 8's configuration system handles configuration in a unified manner. By default, Drupal stores configuration data in the database, but it can be exported to YAML files, allowing the configuration to be managed by version control. There are cases however when configuration values need to be overridden for specific purposes. Drupal 7 had the global $conf variable that was usually populated in settings.php with conditional override values for the configuration. A big drawback of that system was that the overrides crept into actual configuration. When a configuration form that contained overridden values was saved, the conditional override got into the actual configuration storage. ~ Source: Drupal docs → (By the way, why people copy [steel] Drupal docs and call their own?)

Some contrib can help to investigate config. Do you had a read on this? https://www.previousnext.com.au/blog/configuration-override-inspector-re... -- This could be a good start to check what's going on with configuration.

@diqidoc, thank you for weighing in on this.

There is indeed already an issue for the UUID concern, 🐛 Using Domain Config UI creates *.yml files with duplicate UUIDs. Needs work .

To clarify what I meant by configuration edit forms, I probably should have written configuration entity edit forms, i.e. the form that is specified in the configuration entity annotation. In the case of metatag, the entity is Drupal\metatag\Entity\MetatagDefaults. This class has annotations that define form to add or edit the MetatagDefaults entity, among other definitions. For MetatagDefaults, the form is Drupal\metatag\Form\MetatagDefaultsForm.

For reasons I have yet to be able to figure out, the "entity" member of MetatagDefaultsForm gets set to the MetatagDefaults configuration entity without overrides. I am pretty sure I read somewhere that this is the default/desired behavior for entity forms, but of course, I can't find it now. :)

The patch loads the entity with overrides and populates the form with overridden values.

The patch overrides the default behavior, yes.
But without the patch:
- When you load the form, it loads the global settings.
- When you save the form, it saves the domain-specific settings.

That is a bug for sure. This patch at least makes the load and save behavior consistent by changing the first bullet to loading the domain-specific settings.

Thanks for the link to the PreviousNext article. That article references 🐛 There is no indication on configuration forms if there are overridden values Needs work , which definitely pertains to this issue.