Is your feature request related to a problem? Please describe.
Seeing how the combination GTM + UserCentrics seems to be quite common for cookie consent, I was wondering whether it would be reasonable to add a little integration to https://github.com/inpsyde/google-tag-manager to add a data-attribute to the script tag it renders. UserCentrics’ documentation asks for the following:

<script type="text/plain" data-usercentrics="Google Analytics">
(function(i,s,o,g,r,a,m){....} etc
</script>

Describe the solution you'd like
The documentation for the wp_print_inline_script_tag() suggests to use the $attributes in combination with the wp_{inline}_script_attributes filter but since there's no context being passed, I wouldn't know how we would prevent attributes added through a filter from being added to other script tags that apply those filters.
A custom filter like inpsyde-google-tag-manager.script-attributes would give developers full control over the attributes for the GTM script tag alone, with the added benefit that something like a nonce in the script tag (#7) also becomes a possibility.

Describe alternatives you've considered

• Rolling out a custom plugin that handles all UserCentrics_ and GTM functionality is obviously not great. I think fixing it with an attributes filter is elegant and non-intrusive.

Additional context
UserCentrics docs: https://docs.usercentrics.com/#/direct-implementation-guide?id=step-2-adjust-existing-scripts

Is your feature request related to a problem? Please describe.
I always thought that the plugin already made it possible to add data from custom sources to the dataLayer, but - unless I'm mistaken - this is not the case. So an integration that needs different entries to be added to the dataLayer needs to render its own script tag with dataLayer.push(['customKey','CustomValue']), where ideally, this happens in the same place.

Describe the solution you'd like
Two additional filters in the dataLayerProvider::boot method:

• one for an array to provide the dataCollectors (array of dataCollectorInterfaces)
• one for an array of settingsSpecs (array of settingsSpec arrays)
  like so:

public function boot(GoogleTagManager $plugin)
    {
        $dataLayer = $plugin->get('DataLayer');

        $dataCollectors = apply_filters(
            'inpsyde.google-tag-manager.datalayer-data-collectors',
            [
                $plugin->get('DataLayer.User.UserDataCollector'),
                $plugin->get('DataLayer.Site.SiteInfoDataCollector')
            ]
        );

        foreach ($dataCollectors as $dataCollector) {
            $dataLayer->addData($dataCollector);
        }

        if (! is_admin()) {
            return;
        }

        $factory = $plugin->get('ChriCo.Fields.ElementFactory');

        $settings = apply_filters(
            'inpsyde.google-tag-manager.datalayer-data-collector-settings-specs',
            [
                $plugin->get('DataLayer')->settingsSpec(),
                $plugin->get('DataLayer.User.UserDataCollector')->settingsSpec(),
                $plugin->get('DataLayer.Site.SiteInfoDataCollector')->settingsSpec(),
            ]
        );

        $settingsPage = $plugin->get('Settings.Page');
        foreach ($settings as $spec) {
            $settingsPage->addElement(
                $factory->create($spec),
                $spec['filters'] ?? [],
                $spec['validators'] ?? []
            );
        }
    }

This way, a plugin that wants to add a compatible dataCollector can do so and optionally can add their own settings to the GTM settings panel.

Describe alternatives you've considered

• adding a filter to the datalayer script output (currently, only the attributes can be filtered): this may actually still be useful, but makes for a very hacky experience which seems unnecessary since all the interfaces to do this 'properly' are already provided by the plugin.
• refactoring the entire plugin to use inpsyde/modularity and so that it becomes possible to extend the dataLayerProvider (or whatever would be the best approach in that scenario 😏)

Additional context
Annoyingly, my usecase requires a bunch of things that are almost provided by the default settings, just in a different format and wrapped inside an object.

During a security check of one of the websites we were using this plugin SRI sub resource integrity and Content security policies were needed.

To be compliant gtm offers this solution -> https://developers.google.com/tag-manager/web/csp

We need a filter to be able to use the nonce version of the gtml loader script and a filter to pass a nonce when this option is active.

Hi @Chrico I missed this during my tests but after deploying this on a staging environment, one of our clients pointed out that we're rendering an additional '>' which has to be due to this line. I can obviously fix it in a PR once I'm out of this meeting but maybe you're quicker 😏