Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am just wondering if there are any future plans to provide integration with the Domain Access module?
Comment | File | Size | Author |
---|---|---|---|
#14 | metatag-domain-config-overrides-2881295.patch | 683 bytes | paulmckibben |
|
Comments
Comment #2
DamienMcKennaNothing currently.
Comment #3
theroyal CreditAttribution: theroyal commentedany other solution for Domain Access ?
Comment #4
Yazzbe CreditAttribution: Yazzbe commentedWould be nice to have Metag working with Domain Access.
Comment #5
froboyAdding 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
Comment #6
froboyComment #7
DamienMcKennaComment #8
dqdTell 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.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.
Comment #9
Lukas von BlarerI just tested this and it works perfectly for me after adding these paths at
/admin/config/domain/config-ui
:Comment #10
Lukas von BlarerSorry, that was a bit too fast. Importing config fails with this error:
Comment #11
Lukas von BlarerThe 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?
Comment #12
paulmckibbenI 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.
Comment #13
paulmckibbenOr, 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..
Comment #14
paulmckibbenAs 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.
Comment #15
dqdAs 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?
Possibly a side by side finding here which maybe needs another issue to be opened.
It rarely is.
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:
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 withremember 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.
Comment #16
paulmckibben@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.