docs(web/guides): add v4 Overriding Core Methods guide (#3343)

[bpamiri]

What / Why

The v4-0-0 guides tree had no "Overriding Core Methods" page — only the v3-0-0 page existed, and it over-promised the super<name> convention as general when it was model-only until the #3325 parity fix (PR #3357, merged 2026-08-04). This is the docs-only slice deferred from #3325.

Approach

• New page web/sites/guides/src/content/docs/v4-0-0/digging-deeper/overriding-core-methods.mdx:
  • Documents the super<name> convention for models AND controllers/view helpers (4.0.x parity via super<name> originals are only registered for model overrides — controller/view helper overrides get no superLinkTo() #3325).
  • Placement conventions: single controller CFC, app/controllers/Controller.cfc, app/views/helpers.cfm (included before framework mixins, so the app version wins and the original is aliased).
  • superLinkTo(argumentCollection = arguments) delegation matching vendor/wheels/tests/specs/controller/SuperOverrideSpec.cfc; model example uses superFindAll().
  • dataConfirm / data-* pass-through alternative (with delegated JS listener) for the jsconfirm use case — verified against $tagAttribute() hyphenization in vendor/wheels/view/miscellaneous.cfc.
  • Version callout: on 4.0.x builds predating the fix, controller/view super<name> errors; documented variables.coreLinkTo = CreateObject("component", "wheels.view.links").linkTo workaround.
  • Explicit note that router/mapper internals are NOT an override surface (deliberately excluded from fix(controller): register super<name> for app-level controller and view overrides #3357).
• Sidebar: registered in web/sites/guides/src/sidebars/v4-0-0.json (JSON validated) and added a LinkCard to the Digging Deeper section index — avoids the orphaned-page trap.
• v3-0-0 page: short version-scope note (convention is model-only in 3.x; parity arrived in 4.0.x via super<name> originals are only registered for model overrides — controller/view helper overrides get no superLinkTo() #3325).

Test evidence

• Guides site builds clean: pnpm run build — 445 pages, no errors; new page rendered and present in sibling pages' sidebars.
• verify-docs on the new page: 3 tagged blocks, 3 passed, 0 failed.
• Full core suite (Lucee 7 + SQLite, local): 4758 pass / 0 fail / 0 error (docs-only change; suite run per repo policy).

Fixes #3343

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer

TL;DR — This PR adds a v4 "Overriding Core Methods" guide documenting the super<name> convention for models, controllers, and view helpers, plus a version-scope note on the v3 page, a sidebar entry, and a LinkCard. The main content is accurate and well-anchored: the superLinkTo() / superFindAll() delegation, the "alias only created on a real override" behavior, and the model-vs-controller parity story all match vendor/wheels/tests/specs/controller/SuperOverrideSpec.cfc (whose own comments cite "exactly as the 'Overriding Core Methods' guide documents"). One block is a problem: the pre-fix workaround in the caution aside was never compile-verified and, as written, will not run. Verdict: request changes.

Correctness

overriding-core-methods.mdx:90-102 — the pre-fix workaround will throw at render time.

variables.coreLinkTo = CreateObject("component", "wheels.view.links").linkTo;
...
return coreLinkTo(argumentCollection = arguments);

wheels.view.links is declared component { with no extends (vendor/wheels/view/links.cfc:1), so a bare CreateObject instance holds only the methods physically declared in that file. But linkTo() immediately depends on framework methods that are not in links.cfc — $args() (links.cfc:39), uRLFor() (:61), $routeVariables() (:70), and $element() (:72, defined in view/miscellaneous.cfc). Those only exist on a controller/view instance after $integrateComponents("wheels.view") mixes them in (Controller.cfc:5). A CFML method reference stays bound to its owning component, so coreLinkTo() executes against the bare links.cfc instance and throws at the first internal call ($args) before it ever reaches uRLFor.

This slipped through because the block is fenced as plain ```cfm (line 90) rather than ```cfm {test:compile} like the three verified examples (lines 38, 58, 115) — which is exactly why the PR's own evidence reads "3 tagged blocks, 3 passed": verify-docs never looked at this one.

Suggested fix: either (a) drop the broken snippet and point pre-fix users at the data-* pass-through you already document (it needs no override at all), or (b) replace it with an approach you've actually run on a pre-fix build and tag it {test:compile} so verify-docs covers it. A code sample presented as a working fallback must be executable.

Docs

Nice touches worth calling out (not blocking): the v3 page now carries an accurate version-scope note (v3-0-0/.../overriding-core-methods.md), the page is registered in both the sidebar (v4-0-0.json) and the Digging Deeper index LinkCard so it isn't orphaned, and the dataConfirm → data-confirm claim is correct against view/miscellaneous.cfc:481-489 (the Left(name,4) == "data" → hyphenize() path, plus the data_ underscore branch).

Commits

docs(web/guides): add v4 Overriding Core Methods guide (#3343) — conforms to commitlint.config.js (type docs, scope web/guides, subject well under 100 chars). No issue.

Once the workaround block is fixed or removed (and ideally {test:compile}-tagged), this is good to merge.