Domain Access support for Metatag D8/9/10

Nothing currently.

any other solution for Domain Access ?

Would be nice to have Metag working with Domain Access.

Adding D7 port as a related issue as that might be useful for anyone who decides to take this on. Also the Domains Metatag module might also make sense to consider. #3017612: Drupal 8 port

Tell me if I am wrong but since the new Drupal core config layer, as far as I know the Domain API module for Drupal 8,9 and above works as a flexible config layer "splitter" to choose config paths to become domain depending or not. It maybe does not work everywhere but I tested it already for some config paths successfully. Which means you should actually try/test to choose/add the metatag path to the domain config form management and test if it already works OOTB. Maybe there is no additional support of metatag project required to make it work. If every module needs to add domain access support would be a huge amount of work in the whole contrib area. So I hope that I am not mistaken. Domain access is in a huge conceptual progress forward this idea (disclaimer: I am involved) and maybe this issue here should be moved to the domain access issue queue if the user tests fail.

Example settings I tested already successfully under /admin/config/domain/config-ui with "remember domain selection" checkbox checked while editing configs.

/admin/config/system/site-information
/admin/appearance
/admin/appearance/settings/bootstrap

Take a careful look at the last line, which is an individual project installation depending theme settings path of the Bootstrap theme. Domain Access cannot know before, if it will exist in this installation or not. And Bootstrap has no particular domain access support added. But the domain depending settings work when its path is added. Each domain has its own theme settings of the same installed Bootstrap theme now. Even a review tab exist for checking if the configs have been saved for the given domains.

I just tested this and it works perfectly for me after adding these paths at /admin/config/domain/config-ui:

/admin/config/search/metatag
/admin/config/search/metatag/*

Sorry, that was a bit too fast. Importing config fails with this error:

The import failed due to the following reasons:
Entity type mismatch on rename. metatag_defaults not equal to  for existing configuration metatag.metatag_defaults.global and staged configuration domain.config.DOMAIN.metatag.metatag_defaults.global.

The uuid of the new config file was identical to the existing config one of the default domain. Changing it to a new uuid fixed the config import for me.

What is needed to make this to work properly?

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, #3222413: Using Domain Config UI creates *.yml files with duplicate UUIDs..

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.

As I sad already: I am not sure if Metatag can do much. Domain is conceptuated in a way that other modules actually do not need to actively do something to support Domain. Otherwise issue queues would be full of patches to support Domain. Contributing to the progress of Domain at the moment and from my last tests I tend to say that it works OOTB. Surely not 100% since Domain is in Beta for 9/10 but it works with some little issues. Otherwise maybe I miss something on the Metatag side since I am not actively following this atm. Is Metatag still in progress changing to the new config system of Drupal yet?

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.

One Question: Maybe it's me but this could be somewhat misreadable and I am not sure what you mean. What "configuration EDIT forms" you refer to? Or is edit a typo? Are you referring to the Drupal admin setting edit forms which contribute to the configuration data system in general (I guess not) or do you refer to the configuration files/forms? 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?

Apart from that, this helps to get a birds eye view:

drush config-list
drush config-get system.performance --include-overridden

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.

Domain at its actual state overrides configuration based on the added admin paths at admin/config/domain/config-ui which should be watched by domain. From chats in Slack with other users and maintainers and some exchange of latest experiences it seems that it does not work on all given paths entered. It would be interesting to investigate the circumstances when it reacts and when not. My personal experience is that it works best with remember domain activated for that moment of changes for certain domains.

Needless to say that all reports and work on patch attempts etc. are appreciated as always and my thoughts just try to contribute to a solution.

@diqidoc, thank you for weighing in on this.

There is indeed already an issue for the UUID concern, #3222413: Using Domain Config UI creates *.yml files with duplicate UUIDs..

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 #2408549: There is no indication on configuration forms if there are overridden values, which definitely pertains to this issue.