Context specific tag insertion (e.g. CMS only, pages)

[chillu]

Overview

I'm just trying to use this module to embed author-managed tags in the CMS, namely to track CMS behaviour through Google Analytics.

Goals

• Explicit definition of contexts (not implied by different extension points)
• Custom contexts can be defined by developers (e.g. "logged-in app pages")
• Optional knowledge of contexts in snippet providers
• Snippet providers do not need to know about contexts

Potential Contexts

• Controller
• Page type
• URL path
• URL parameter (e.g. campaign)
• User information

Triggers

Option 1: Path-matching middleware

Contexts are determined by URL matching. This is how most tag managers deal with it, since they can't make any assumptions about the systems used to generate the responses. This would most naturally fit as a HTTPMiddleware, and replace the current TagInserter extension which is applied to ContentController (page content only).

Pro: Cleanest solution (no tangling with controllers), can read session info. Has access to the full response (incl. modifications from other extensions). More portable for headless systems where this patch matching might happen on the client, without full server-side controller context. Con: No knowledge of some contexts, such as controller or page type. Harder to build page-specific CMS UIs, weak connection between context and page (can break when page URL changes).

Option 2: Multiple controller extensions

Contexts are determined by inspecting controller state, such as Controller->getRequest() and ContentController->dataRecord() and LeftAndMain->getRecord().

But: The current extension point on ContentController->afterCallActionHandler() isn't triggered by LeftAndMain, since the hasMethod() check in Controller->handleAction() short circuits this logic. Maybe that's a bug?

Pro: Full access to controller state for deriving context, most flexibility. Con: No generic solution for all controllers (at the moment).

Notes

We could add SnippetProvider->appliesForContext(<SnippetContextInterface>), which would allow snippets to declare when they're not compatible with well known contexts (such as breaking the CMS UI, and hence returning false for appliesToContext(CMSSnippetContext). This would only makes sense if we also delegate application of snippets to the context, so the CMS one could choose to run on LeftAndMain->init().

This ticket highlights the difference between our very limited definition of a "tag manager", and a real tag manager like GTM. It's about more than just inserting <script> tags. GTM defines triggers for when tags are embedded. "Add Google Analytics and fire off a page view on page load" is just the simplest use case. There's other triggers which are naturally determined client-side, such as element clicks, form submissions, etc.

[sminnee]

Your specific case overlaps with #4, although "add this tag only on certain pages, sections, or pagetypes" and "add this tag only for logged-in users" are other use-cases that may be supported by a context feature.

However, for admin tags, as well as a different set of tags inserted in a different context, there's also the question of whether that should be done through a tags UI or config yaml, since it's the developer putting them in place, rather than the author.

That said, it's possible that any context could introduce "developer-defined tags", and there might be some affordance for these such as read-only display in the UI.

[sminnee]

I'm a little skeptical about the idea of SnippetProvider->appliesForContext. The point of this module was to abstract away the need for Snippets to build logic such as context-sensitive application (such as page- or pagetype-specific tags) – by adding such a feature to tagmanager, all snippets can benefit from it.

By asking for SnippetProvider->appliesForContext you're suggesting that some of this behaviour would necessarily be snippet-specific.

This ticket highlights the difference between our very limited definition of a "tag manager", and a real tag manager like GTM.

Yeah, the module was very 0.0.1.