No way to get the URL the visitor actually receives

[romain-pm]

Part of #749. There is no way to obtain the URL a visitor will actually receive.

anchor.href is a server-side intermediate. Core's URLFilter completes it after the render, and only for URLTraverser's tag/attribute pairs in an html template type. Anything else keeps the raw /cms/... form: an Island payload, a data-* attribute, an action's JSON response, a meta tag. The JSDoc says so; nothing offers a way out.

Three concrete consequences, all measured:

• Jahia/jahia.com's 15-year-old workaround survived the adoption verbatim: buildNodeUrl(target).replace("/cms/edit/", "/cms/editframe/") in NavBar.tsx, because its nav is Island-driven and the URL in the payload is never rewritten. Adopting <JLink> did not remove it and could not.

• data-element-url on that site still carries a different URL from its sibling href, for the same reason.

• Any module doing client-side navigation from server-supplied URLs has the same bug and no way to know.

• Decide the remedy: a mode: "editframe" on buildNodeUrl (buildNodeUrl gaps a link component cannot work around #756 already lists mode: "edit" emitting the wrong servlet path), an absolute option that resolves through the rewrite layer, or an explicit "final URL" call that runs the outbound rules the way response.encodeURL does.

• Whatever the answer, the guide must state which contexts get a rewritten URL and which do not — today a developer discovers it by shipping a broken edit-mode link.

• Check whether the /cms/edit/ -> /cms/editframe/ replace is even still needed on 8.2.3, or is cargo from an older core. If it is obsolete, most of this shrinks.

[romain-pm]

Answered on a running 8.2.3, and the answer shrinks this issue: the replace is still needed, but it is a library bug rather than core cargo.

Measured on jahia/jahia-ee:8.2.3 with the luxe site:

URL	Result
/cms/edit/default/en/sites/luxe/home.html	302 → /jahia/jcontent/luxe/en/pages/home
/cms/editframe/default/en/sites/luxe/home.html	200, the page

And the defect reproduced verbatim in the rendered edit-mode page: every <a href> carried /cms/editframe/…, while the LanguageSwitcher Island's JSON payload carried /cms/edit/…. The difference is not the outbound rewrite — it is which branch of buildNodeUrl ran. NavMenu calls buildNodeUrl(home), which takes the node.getUrl() branch and already returns the editframe path; LanguageSwitcher calls buildNodeUrl(node, { language }), which takes the manual branch and hardcodes /cms/edit/. EditModeFilter then patches the anchors (its traverser visits a[href] and nothing else) and leaves the payload alone.

So the remedy is one string, not a new API: the manual branch emits /cms/editframe/. Jahia/jahia.com's .replace("/cms/edit/", "/cms/editframe/") can be deleted, and this also ticks the mode: "edit" box of #756.

What is left is documentation, not API. There is no "final URL" call worth adding: the finishing pass is URLFilter walking assembled HTML, which does not exist while a view runs. Its two handlers are SiteParameterAdder (?jsite=) and UrlRewriteVisitor (vanity URLs, SEO server name), and URLTraverser visits exactly a[href], img[src|srcset|data-src|data-srcset], form[action], link[href], source[srcset], embed[src], param[value], on configurations page,gwt,module,wrappedcontent and template types html/html-*. The links guide now states that table, and says plainly that a data-* attribute of your own, an Island payload, an action's JSON, a <meta> tag and JSON-LD get none of it.

The vanity-URL and ?jsite= gap in an Island payload therefore remains open and unsolved — but it is now written down rather than discovered by shipping.

Implemented in javascript-modules#773.