Open chillu opened 5 years ago
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.
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.
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
Potential Contexts
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 currentTagInserter
extension which is applied toContentController
(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()
andContentController->dataRecord()
andLeftAndMain->getRecord()
.But: The current extension point on
ContentController->afterCallActionHandler()
isn't triggered byLeftAndMain
, since thehasMethod()
check inController->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 forappliesToContext(CMSSnippetContext)
. This would only makes sense if we also delegate application of snippets to the context, so the CMS one could choose to run onLeftAndMain->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.