Follow-up to #225
Currently, the Analytics implementation is duplicating some code from Site Kit to reuse its configuration, however, the implementation could also be done in a similar way to the AMP Plugin where Site Kit would use the existing web_stories_print_analytics action instead of Web Stories duplicating Site Kit's code.
See also Felix's related comment.
_Do not alter or remove anything below. The following sections will be managed by moderators only._
@miina I'm not sure where this is on the current priority list, just wanted to let you know I'll be happy to tackle this on the Site Kit front.
Regardless of whether or not this is being worked on soon, there's one thing I wanna point out that should be addressed: The web_stories_print_analytics action in the Web Stories plugin probably shouldn't be there as long as the plugin is taking care of rendering the snippet itself. By having both things being there, it will make it tricky in the long term to properly support any combinations of versions of Site Kit + Web Stories, for example if Site Kit adds the hook, it would also be added to the current codebase, which would then result in two snippets to be printed. We could still work around it with specific version checks, but that's a painful approach I'd prefer to avoid. Hence, I suggest removing the action for now, until we properly tackle the Site Kit integration.
cc @swissspidy
I don't see why we should temporarily remove the action from our code base while we're still in the middle of the development phase and haven't officially released anything.
We'll happily remove the current solution when a Site Kit enhancement is underway (which I assume should be possible within the next month). Then there shouldn't be any problems whatsoever regarding version combinations, as that's well before our stable release.
@swissspidy Right, I just wanna ensure this gets addressed before the release. If not, I think the action should be removed - and I thought it may make sense to do that now rather than to forget it later, since the current version (having both the action _and_ the internal implementation) shouldn't be released.
The action could, in theory, be used by something else other than Site Kit as well, so it's the Site Kit integration logic which is really temporary there, and not the action.
For avoiding duplicate scripts during the time when there's still the custom Site Kit script + the action, the web_stories_gtag filter could be used to return null and the custom Site Kit script would not be printed then at all, post-release or pre-release.
Note to potentially consider:
As of the current plan, there will also be a possibility to add custom GA analytics ID from the Global Settings of the Story editor if Site Kit is not used. This means that we might still need the analytics code to exist somewhere locally, too. See ACs of #570
@miina @swissspidy We are ready to ship this in Site Kit's upcoming 1.9.0 release (scheduled for next Tuesday), see https://github.com/google/site-kit-wp/pull/1596. Would be great if you could review the PR and test, and make the necessary changes on your end. Keep in mind that if we release this without the Web Stories plugin being updated itself, things will be broken.
Sounds good! Will do that tomorrow.