Skip to content

refactor(layouts): resolve products from data, not hardcoded lists - #7573

Open
jstirnaman wants to merge 2 commits into
refactor-search-labels-from-productsfrom
refactor-layouts-product-data
Open

refactor(layouts): resolve products from data, not hardcoded lists#7573
jstirnaman wants to merge 2 commits into
refactor-search-labels-from-productsfrom
refactor-layouts-product-data

Conversation

@jstirnaman

Copy link
Copy Markdown
Contributor

Stacked on #7571, which is stacked on #7569. Review those first; this PR's
base is refactor-search-labels-from-products.

What changed

Five templates stopped inferring the product from the URL path and stopped
branching on hardcoded lists of product names.

  • Added layouts/partials/product/get-context.html. It resolves the product
    from the page's cascade product param, with a path fallback for product
    hub pages, which sit above the versioned sections that carry the cascade.

  • Added layouts/partials/product/is-latest.html. One rule for "does this
    page document the current version", shared by both search systems.

  • Moved the branching facts into data/products.yml:

    Field Set on
    supports_flux influxdb, influxdb_cloud, enterprise_influxdb
    search_includes_resources false on the six InfluxDB 3 products
    has_support_contract false on chronograf, kapacitor
  • Set latest on telegraf_controller and telegraf_enterprise to their
    version path segment.

  • Second commit: documented the rule in .agents/instructions/layouts.md,
    the hugo-template-dev skill, and AGENTS.md.

No product names remain in the touched templates.

Why

header/coveo-meta-data.html and header/search-attributes.html both
answered the same question, each with its own hardcoded list, and the lists
drifted:

                     coveo   algolia
/influxdb3/explorer/  false    true
/telegraf/controller/ false    true

Two search systems disagreeing about whether the same page is current.

The lists existed to paper over a broken lookup. Both templates did
index .Site.Data.products $product where $product is the first path
segment. Under /influxdb3/ that segment is influxdb3, which is not a
products.yml key — the keys are influxdb3_core, influxdb3_cloud. The
lookup always missed, so the real comparison never fired and someone listed
the version segments by hand instead.

The data already answered it. influxdb3_core has latest: core,
influxdb3_explorer has latest: explorer. Every product section already
declares its products.yml key through cascade, and
layouts/partials/product/get-data.html already resolved it.

Impact

Coveo and Algolia now agree on every product. Search tags are unchanged, so
the Algolia index is untouched:

/influxdb3/core/         tag=influxdb3-core         res=false  flux=false
/influxdb3/cloud/        tag=influxdb3-cloud        res=true   flux=false
/influxdb/v2/            tag=influxdb-v2            res=true   flux=true
/telegraf/controller/    tag=telegraf-controller    res=true   flux=false
/enterprise_influxdb/v1/ tag=enterprise_influxdb-v1 res=true   flux=true

The flux and resources flags reproduce the deleted lists exactly.

Two behavior changes need a second opinion:

  1. telegraf_controller and telegraf_enterprise had latest: 1.0
    unquoted. YAML parses that as a float, and Hugo renders it as "1" — the
    .0 is gone before any regex runs, and eq against a string is always
    false. Verified with a Hugo probe:

    PROBE latest=1 type=float64 | latest_patch=1.0.1 type=string
          | replaceRE="1" | eqString=false
    

    They are the only two products whose version field is not a string. The
    value was dead — no template read .latest for either product — but the
    currency rule needs it, so both are now controller and enterprise,
    matching the convention every other product follows: latest is the URL
    version segment, latest_patch is the release. latest_patch: 1.0.1 is
    unchanged. If release tooling outside this repo reads
    telegraf_controller.latest expecting 1.0, say so and I will find
    another way.

  2. /platform/ and /resources/ now mark as current for both systems.
    Replacing the hardcoded eq $product "platform" clause with a rule means
    stating one: a page outside any versioned product has no older
    counterpart. Previously Coveo said stale for both and Algolia said current
    for platform only.

Verification

npx hugo --quiet                                    # exit 0
node .ci/scripts/check-feedback-links.js            # all checks passed
node --test 'assets/js/__tests__/*.test.mjs'        # 13 pass, 0 fail
run-e2e-specs --spec cypress/e2e/content/article-feedback.cy.js   # 16/16
run-e2e-specs --spec cypress/e2e/content/page-context.cy.js       # 13/13
yarn validate:agent-instructions                    # valid

Checked the rendered public/ output for all 16 product sections plus
/platform/ and /resources/, comparing the latest, docsearch:latest,
docsearch:searchTag, data-search-tag, data-include-flux, and
data-include-resources values against the pre-refactor build.

Note for anyone diffing rendered HTML here: Hugo minifies in production and
drops quotes around attribute names, so grep '<meta name="latest"' finds
nothing. Match name="?latest"? instead.

One exception, deliberate

The Algolia search tag in header/search-attributes.html stays path-derived
and is commented as such. It is the key Algolia indexed all 53,135 records
under, and content_path does not reproduce it for the five products whose
content path omits the version segment (telegraf, chronograf, kapacitor,
flux, enterprise_influxdb). The documented rule carries this exception so a
later cleanup does not orphan those records.

@jstirnaman
jstirnaman requested a review from a team as a code owner July 27, 2026 22:16
@jstirnaman
jstirnaman requested review from sanderson and removed request for a team July 27, 2026 22:16
@github-actions

Copy link
Copy Markdown
Contributor

Vale Style Check Results

Metric Count
Errors 0
Warnings 0

Check passed

@github-actions

Copy link
Copy Markdown
Contributor

Release version check

No release-notes pages with a tracked version changed in this PR.

💡 Badge new features with the version

Documenting a new feature? Add a version badge in the page frontmatter — the
same mechanism used elsewhere in the docs:

  • metadata: [InfluxDB 3 Core v3.11+] — badge list under the page title
  • updated_in: v3.11 — an "Updated in v3.11" badge
  • introduced: v3.11 — a "‹Product› v3.11+" badge
  • menu.params.state: new — a "NEW" pill on the sidebar nav item

For inline version text, use {{< latest-patch >}} / {{< current-version >}},
which read the value from data/products.yml so it stays correct automatically.

@jstirnaman
jstirnaman force-pushed the refactor-search-labels-from-products branch from 0500a53 to 1dd0903 Compare July 28, 2026 13:57
Five templates inferred a product by parsing the URL path, then branched
on hardcoded lists of product and version names. The inference is wrong
under /influxdb3/, where the path segment is `influxdb3` but the
products.yml keys are `influxdb3_core`, `influxdb3_cloud`, and so on, so
the lookup always missed and each template papered over it with its own
list.

The lists drifted. `header/coveo-meta-data.html` and
`header/search-attributes.html` both decided "is this page current", with
different lists. InfluxDB 3 Explorer and Telegraf Controller were current
for Algolia and stale for Coveo.

Resolve the product from the cascade `product` param instead, which every
product section already declares. Add product/get-context.html for the
lookup and product/is-latest.html for the shared currency rule, so the two
search systems cannot disagree again.

Move the branching facts into data/products.yml:

  supports_flux              influxdb, influxdb_cloud, enterprise_influxdb
  search_includes_resources  false for the six InfluxDB 3 products
  has_support_contract       false for chronograf, kapacitor

Set `latest` on telegraf_controller and telegraf_enterprise to their
version path segment, matching every other product. Both had `latest: 1.0`
unquoted, which YAML parses as a float and Hugo renders as "1", so the
currency check could never match. `latest_patch: 1.0.1` still carries the
release version.

The search tag stays path-derived. It is the key Algolia indexed every
record under, and content_path does not reproduce it for the five products
whose content path omits the version segment.

No product names remain in the touched templates.
@jstirnaman
jstirnaman force-pushed the refactor-layouts-product-data branch from ca17b33 to 0bdeeb8 Compare July 28, 2026 13:57
Templates operate on data and stay ignorant of the values in that data.
A product name, version segment, or products.yml key must never appear as
a string literal in template logic, so renaming or adding a product never
requires a template edit.

Document the banned shapes, the three replacements (a per-product field in
data/products.yml, product/get-data.html or product/get-context.html for
resolution, one shared partial for a decision two templates make), and the
incident that motivated it: coveo-meta-data.html and search-attributes.html
each kept their own list for the same question, the lists drifted, and
InfluxDB 3 Explorer and Telegraf Controller were current for one search
system and stale for the other.

Carve out one exception. A value that must match an external system rather
than a product fact stays as it is, with a comment saying why. The Algolia
search tag is path-derived because Algolia indexed every record under the
crawled URL, and a well-meaning cleanup would orphan those records.

Rule lives in .agents/instructions/layouts.md, how-to in the
hugo-template-dev skill, one-line constraint in AGENTS.md. The three
adapters are regenerated by yarn build:agent:instructions.
@jstirnaman
jstirnaman force-pushed the refactor-layouts-product-data branch from 0bdeeb8 to bef595a Compare July 28, 2026 14:06
@github-actions

Copy link
Copy Markdown
Contributor

🔗 Link Check Results — Link Check Bot

All links are valid

Metric Value
Files Checked 8
Total Links 3056
Errors 0
Warnings 9
Success Rate 99.18194%
⚠️ 9 warning(s) (do not fail CI)
Source File URL Issue
content/enterprise_influxdb/v1/introduction/installation/single-server/_index.md https://support.influxdata.com/ Network error: SSL certificate not trusted. Use --insecure if site is trusted (e…
content/influxdb/v1/introduction/install/_index.md https://support.influxdata.com/ Network error: SSL certificate not trusted. Use --insecure if site is trusted (e…
content/influxdb/v2/install/_index.md https://docs.docker.com/engine/reference/run/#detached-vs-foreground Cannot find fragment: Cannot find fragment
content/influxdb/v2/install/_index.md https://support.influxdata.com/ Network error: SSL certificate not trusted. Use --insecure if site is trusted (e…
content/influxdb3/core/install/_index.md https://support.influxdata.com/ Network error: SSL certificate not trusted. Use --insecure if site is trusted (e…
content/influxdb3/enterprise/install/_index.md https://support.influxdata.com/ Error (cached): Error (cached)
content/influxdb3/explorer/install/_index.md https://support.influxdata.com/ Network error: SSL certificate not trusted. Use --insecure if site is trusted (e…
content/telegraf/v1/install/_index.md https://support.influxdata.com/ Error (cached): Error (cached)
content/telegraf/v1/install/_index.md https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/starting-windows-powershell… Cannot find fragment: Cannot find fragment

Full details: workflow run summary and artifact. Last updated: 2026-07-28 14:09:24 UTC

@github-actions

Copy link
Copy Markdown
Contributor

📦 PR Preview — Preview Bot

Status Details
Result ✅ DEPLOYED (full site)
Preview View preview
Build time 87s
Last updated 2026-07-28 14:13:42 UTC

Preview auto-deploys on push. Will be cleaned up when PR closes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant