Add support for multiple containers (D7)

This patch doesn't apply cleanly (to 7.x-1.4+5-dev), on line 187 the line

- height="0" width="0" style="display:none;visibility:hidden" title="Google Tag Manager">Google Tag Manager</iframe></noscript>

should be:

- height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>

@Fernando Iglesias Your patch files indicate:

• only the container ID would differ in the configuration
• multiple containers would be included on each page response

A few questions.
Would you edit the issue summary to include the rationale for this request?

The 7.x module supports creating multiple containers in the context of variable realms. In this sense, each container may have separate configuration settings (e.g. container ID, insertion conditions, etc.). However, the page response would only include the container for the primary realm:key on that response. Does this feature support your use case?

Is your use case supported by the environment concept offered by Google Tag Manager?

@solotandem responding on behalf of Fernando:

We manage several hundred discrete websites at a large academic institution. Most of those sites report to at least two GA codes, but many of the sites do not use the same two codes. As platform owners, one is an internal code for aggregate tracking. The other codes are for sharing discretely with other groups in our organization.

We have a similar situation with GTM containers. The majority of sites use the same stable of base event tags, but there are a handful of sites that require additional event tagging that the hundreds of other sites don't need to load. In some cases we inherit a site with a legacy container that they are used to managing themselves, but they shouldn't have access to our core container.

A container-ception strategy in GTM could certainly work in theory, but managing (and mismanaging) all of those conditions could lead to problems, plus it adds a ton of bloat to every site that uses that one container.

If we were to start from scratch, we might do things differently but this is the architecture we have and it hasn't let us down yet!

Thanks for the details. Do you happen to use your patch in production? If not, what are you doing in the interim?

@Fernando-Iglesias Would you be able to test the 7.x-2.x branch which has support for multiple containers (in the same way as the 8.x branch)? For each container, you can define the container ID as well as all the other values (data layer, insertion conditions, etc.). There is an update hook to run that will migrate your container from variables to config table. You would need to run this without your custom patch.

I was not asking you to run 2.x in prod but on a dev environment. Your feedback would be useful before making the first release.

I tested it and I am getting this error

 Google_tag  7200  Migrate variables to settings and container config items.
Do you wish to run all pending updates? (y/n): y
\Migrate variables to settings and container config items             [ok]
Performed update: google_tag_update_7200                             [ok]

PHP Fatal error:  Declaration of GTMContainerManager::createAssets($container) must be compatible with ContainerManagerInterface::createAssets(GTMContainer $container) in /var/www/news/modules/contrib/google_tag/includes/entity/manager.inc on line 6

Thanks for testing this.
Latest commit removes the type hints from the interface file. Would you test again?

Curious, what PHP version are you running with this?

@Fernando Iglesias Take it with a grain of salt, but I am going to poke you on this. You file an issue asking for multiple container support. I add it and ask you to test the changes (implied on a test environment). You miss the point and, even after clarification, seem unwilling to participate in the open source process and test what you asked for. Am I missing something here or are you missing the concept of open source? community? etc.? How about it? [Granted the dev release does not have security support, but to claim it is unstable is a bit much, especially from someone who has not even tried it.]

@t00lie You remark that managing (and mismanaging) all of those conditions could lead to problems. With the 2.x branch you configure the default settings once, then create the individual containers (which inherit the default settings) and set the container ID. Where is the management difficulty in this? As to your claim it adds a ton of bloat to every site that uses that one container, what exactly are referring to?

@Fernando Why exactly does it need to be left out of 1.x? Because it is a kluge.