That's correct. You should be able to set the hostname under the global module settings advanced tab and under the advanced tab on the individual container settings.
You can set the host name under the 'advanced' tab on both the global settings page and in the individual container settings pages. That should resolve the issue with the Google Tag Manager(s) not loading.
I just did a quick test with the Google Analytics module and the Google Tag Manager module and as far as I can tell there are no conflicts in loading the scripts.
For most implementations the host name will be 'www.googletagmanager.com'. This was also the default setting in older versions of this module.
I recently saw a similar issue. In my case the problem was that the 'hostname' value was not set, probably due to not (or not correctly) executing database update 8104 or due to a forgotten config export / import after update 8104. Manually setting the correct value resolved the issue.
@tim-diels, thank you for trying to understand the issue. Sorry for not being able to explain the issue more clearly.
The issue occurs when on a domain (lets say domain1.example.com and trying to access the current domain sitemap at domain1.example.com/sitemap.xml). The sitemaps at /domain1_example_com/sitemap.xml etc. are accessible and containing the expected links.
But behaviour I'am expecting is that the sitemap links applicable for the current domain will be returned at /sitemap.xml.
Does this explanation make more sense?
@lvishal can you add any further information regarding the issue?
PS The patch in #5 seems to resolve the issue (in my case) but some further testing will be appreciated.
The issue occurs when trying to access a domain specific sitemap (like domain1.example.com/sitemap.xml, domain1.example.com/sitemap.xml). The issue (in my case) occurs when accessing the sitemaps directly in combination with Redirect module. The expected outcome of accessing the sitemap on a Domain level is that the Domain variant will be returned (in other words, the Domain specific sitemap variant will be returned at domain1.example.com/sitemap.xml etc.).
I ran into a similar problem. The attached patch fixed the issue in my project.
Patch from #12 does not apply on v2.0.2. Attached patch does apply on v2.02.
Needs testing though :-).
Following up on #17. In my case, the issue seems more a memory issue than a Twig Tweak related issue. The issue occurs when working with limited memory and a lot of nester entity references.
Updated patch for use with '3.0.5' module version. Also applied some coding standards improvements.
Ported and tested changes from #9 to the v2 branch. This method seems to work as intended (in combination with the views_ajax_history module). Patch for changes in v2 branch attached.
I think that if we move the check into the controller we'll be prevent throwing the SVG's through all checks and prevent a conversion attempt. Can we use something like the attached patch as a starting point?
@paulmckibben Nice work on the patch!
It seems like the test are failing because the config schema is not update.
The attached patch should fix that :-).