WordPress multisite information

The following two data layer variables tell you which site of a WordPress Multisite network the visitor is on. Both are added on every page of the site.

Both have their own option on the plugin settings screen, in the Site data group of the Page variables section. Both are switched off by default, so turn them on before you look for the variables in your data layer.

This page describes GTM4WP 2.0.0 and newer. Features introduced by that release are marked New in 2.0.0 and are not available in the legacy 1.x versions. Where 1.x behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.

GTM4WP 1.x: the same two options lived in the Basic data tab of the settings screen.

siteID

The ID of the site that is currently shown, as a number. WordPress gives every site of a network an ID of its own: the site the network was created from reports 1, and every site added later reports the ID it was given. Use this variable when the sites of your network share one Google Tag Manager container and you need to keep their traffic apart in your reports.

siteName

The name of the site that is currently shown, as a string. This is the site title set in the general settings of that one site, not the name of the network.

The two options on a site that is not part of a network

The plugin reads both values with the get_blog_details() function, which WordPress only loads in a network installation. On a single site the variables are still added to the data layer once you enable the options, but siteID is then 0 and siteName is an empty string. Leave both options switched off unless your site runs in a network.

How GTM4WP works on a multisite network

GTM4WP runs on a WordPress Multisite network and treats every site of the network as a site of its own. WordPress stores the options of each site separately and the plugin follows that, so every site has its own settings screen, its own container ID and its own set of enabled data layer variables. There is no network wide settings screen.

Copying the settings from one site to the others

New in 2.0.0. The settings screen has an Export settings and an Import settings button next to Save changes. Set up one site of the network, export its options into a JSON file, then import that file on the other sites instead of repeating the work by hand. The import runs every value of the file through the same checks as a normal save and drops keys that the plugin does not know, so an edited file cannot put an unexpected value into your settings.

One container ID for the whole network

The wp-config.php file belongs to the whole network, so a container ID set in the GTM4WP_HARDCODED_GTM_ID constant applies to every site at once and overrides what is stored in the settings of the individual sites. The GTM4WP_HARDCODED_GTM_ENV_AUTH and GTM4WP_HARDCODED_GTM_ENV_PREVIEW constants work the same way for Google Tag Manager environments, and they replace the environment parameters of every container row. When both of them hold a value, the sites of the network load the first container ID only. The three constants are described on the hard coding page.

A value in one of the two environment constants that does not have the expected format is refused instead of being written into the loader URL of every container on every site, and the settings screen shows a warning that names the constant you need to correct.

GTM4WP 1.x: a value that did not have the expected format was written into the loader URL as it was, and no warning was shown.

Loading more than one container on a site

A site can load several containers, which is useful when a site of the network has a container of its own next to a container used across the network. List the container IDs in the settings of that site.

New in 2.0.0. Container IDs are managed in a table where each of them has its own environment parameters, custom domain and custom path. Every container listed there is loaded, including when environment parameters are set on the rows. The site wide constants in wp-config.php behave differently, as described above.

GTM4WP 1.x: the environment parameters were a single site wide pair rather than a per container setting, and with them configured only the first container was loaded.

Leaving the container out on some sites of the network

New in 2.0.0. The gtm4wp_output_container filter decides whether the container code is written into the page, and it returns true by default. A must use plugin loads on every site of a network, so you can hook the filter there and return false for the sites that should not load the container, based on the value of get_current_blog_id() for example. The data layer stays in place and only the container script and its noscript pair are left out.

See also the page and post attributes and user and visitor data pages, the hard coded container parameters page and the list of actions and filters.