Follow-up to PR #7211 (Markdown autodiscovery). The autodiscovery work surfaced an inconsistency in `data/products.yml`:
- For some products, `content_path` is the versioned path (e.g., `influxdb3/core`, `influxdb/v2`).
- For others, `content_path` is the parent product directory and the version segment is implicit (e.g., `telegraf` but content lives at `content/telegraf/v1/`).
This inconsistency forces every downstream consumer to derive the versioned path with combine-content_path-plus-versions logic. PR #7211 added one such derivation utility at `scripts/lib/corpus-paths.js` and mirrored the same logic in Hugo templates. Other consumers (`.github/scripts/workflow-utils.js`, `assets/js/utils/product-mappings.ts`, sidebar/topnav layouts) handle the inconsistency in their own ways.
Proposed fix
Rationalize `content_path` so it always points to the versioned content path:
| Product |
Current `content_path` |
Proposed |
| telegraf |
`telegraf` |
`telegraf/v1` |
| chronograf |
`chronograf` |
`chronograf/v1` |
| kapacitor |
`kapacitor` |
`kapacitor/v1` |
| enterprise_influxdb |
`enterprise_influxdb` |
`enterprise_influxdb/v1` |
| flux |
`flux` |
`flux/v0` |
Products with versioned `content_path` (`influxdb3/core`, `influxdb/v2`, etc.) stay unchanged. Products with object-form `content_path` (e.g., `influxdb` with `{v2, v1}`) stay unchanged.
Audit checklist before changing
Each `content_path` consumer needs to be verified:
For each, ask: does the consumer expect `content_path` to be the parent or the versioned path? Update consumers that expect parent-form (or that strip a trailing version, etc.).
Why this is a follow-up rather than part of #7211
PR #7211 introduces a derivation utility (`scripts/lib/corpus-paths.js`) that handles both conventions. The autodiscovery feature works correctly either way. Rationalizing `content_path` is a cross-cutting refactor that benefits more than just autodiscovery, but it's not required for autodiscovery to ship.
Once `content_path` is rationalized, `scripts/lib/corpus-paths.js` simplifies dramatically (just iterate, no version-appending heuristic) and `workflow-utils.js` becomes simpler too.
Follow-up to PR #7211 (Markdown autodiscovery). The autodiscovery work surfaced an inconsistency in `data/products.yml`:
This inconsistency forces every downstream consumer to derive the versioned path with combine-content_path-plus-versions logic. PR #7211 added one such derivation utility at `scripts/lib/corpus-paths.js` and mirrored the same logic in Hugo templates. Other consumers (`.github/scripts/workflow-utils.js`, `assets/js/utils/product-mappings.ts`, sidebar/topnav layouts) handle the inconsistency in their own ways.
Proposed fix
Rationalize `content_path` so it always points to the versioned content path:
Products with versioned `content_path` (`influxdb3/core`, `influxdb/v2`, etc.) stay unchanged. Products with object-form `content_path` (e.g., `influxdb` with `{v2, v1}`) stay unchanged.
Audit checklist before changing
Each `content_path` consumer needs to be verified:
For each, ask: does the consumer expect `content_path` to be the parent or the versioned path? Update consumers that expect parent-form (or that strip a trailing version, etc.).
Why this is a follow-up rather than part of #7211
PR #7211 introduces a derivation utility (`scripts/lib/corpus-paths.js`) that handles both conventions. The autodiscovery feature works correctly either way. Rationalizing `content_path` is a cross-cutting refactor that benefits more than just autodiscovery, but it's not required for autodiscovery to ship.
Once `content_path` is rationalized, `scripts/lib/corpus-paths.js` simplifies dramatically (just iterate, no version-appending heuristic) and `workflow-utils.js` becomes simpler too.