include unify script - #1279
Conversation
bpander
left a comment
bpander
left a comment
There was a problem hiding this comment.
Main issue is I think the meta name value is wrong, but I also think we could maybe put more of this logic on the ts/astro side (for better devex and compile-time checking).
| {%- endcomment -%} | ||
| {%- for unify_path in site.data["unify-enabled-pages"] -%} | ||
| {%- if page.url contains unify_path %} | ||
| <meta name="enable-unify" content="true" /> |
There was a problem hiding this comment.
Should be name="unify" right?
That's what cookie-consent.js looks for:
if (document.querySelector('meta[name="unify"]')) {
There was a problem hiding this comment.
right, thanks! updated
| @@ -0,0 +1,37 @@ | |||
| # Docs pages that load Unify (visitor de-anonymization for outbound). | |||
There was a problem hiding this comment.
I think we can/should put more of this logic on the ts/astro side. There's also a whole bunch of comments, some of which I don't think belong in the places they're at currently, and we're also probably moving _docs out of version control soon so they'll probably be outdated soon.
Maybe something like this?
There was a problem hiding this comment.
yeah, it looks much cleaner, I'll take it :)
c7bd0f9 to
9d930fc
Compare
9d930fc to
8bd617f
Compare
8bd617f to
c13b113
Compare
|
|
||
| const lq = getLiquidRenderer({ page, dirname }); | ||
|
|
||
| const unify = UNIFY_ENABLED_PAGES.includes(Astro.url.pathname); |
There was a problem hiding this comment.
Sorry, I steered you slightly wrong. I forgot there was some dev server/full-build weirdness with Astro.url (inconsistent trailing slashes). I should've told you to use page.url which is the normalized url.
| const unify = UNIFY_ENABLED_PAGES.includes(Astro.url.pathname); | |
| const unify = UNIFY_ENABLED_PAGES.includes(page.url); |
It'll also need url: string; added to this template's Props page type to make TS happy (it won't trigger any other TS errors). Sorry about that.
2 participants
part of https://linear.app/metabase/issue/GRO-808/restore-unify-tracking-on-migrated-marketing-pages
website PR https://github.com/metabase/metabase.github.io/pull/6344
What
Docs pages opt into Unify through
_data/unify-enabled-pages.yml._includes/head.htmlstamps<meta name="enable-unify">on any page whose URL contains a listed path; the marketing site'scookie-consent.js(website PR above) reads that tag and injects/js/unify.js, but only after the visitor grants marketing consent. Inert until that PR ships, so merge order doesn't matter.Why
Docs pages load no Unify at all today. The
{% if %}chain in_includes/footer-scripts.htmlonly ran viafooter.html, which docs layouts never include — so the four embedding URLs marketing tracks have been dark, and that block also loaded the script without consent. Both are gone.js/unify.jsis deleted rather than fixed: the marketing build owns/js/*on www.metabase.com and shadows this repo's copy, so aunify.jshere is never served.Docs paths live only in this list; the marketing list holds only non-docs pages, so the two are disjoint and there is nothing to keep in sync. Nothing verifies the list automatically, so the paths need a manual re-check when embedding docs move.
Verification
Full
astro build: exactly 4 of 14,125 pages carry the tag (the four intended ones), versioned copies and controls are untagged, and no page referencesjs/unify.js. The Liquid block renders identically under Jekyll's Ruby Liquid and the liquidjs renderer that now builds doc pages.