AEM commerce links show internal paths on publish

An author may pick a commerce product in rich text and see a working link, while the published page exposes a long /content/... path. A CIF issue recorded that difference for CommerceLinksTransformerFactory. The issue is closed, so the useful question now is whether a particular deployed version or customization still produces the same customer-facing URL.

Compare author and publish output

Create a test link through the commerce link picker and inspect the saved author content, the rendered publish HTML, and the final browser destination. Record host, locale, category, and product path. A link that resolves internally can still be a poor public URL if the emitted href bypasses the site's mapping rules. The Apache Sling mapping guide distinguishes incoming resource resolution from outgoing path mapping; test the outgoing side directly.

Check the version before changing code

Review the deployed CIF component version, release notes, and any overlay of the RTE transformer. Since the source issue was closed as completed, do not assume its original behavior persists in current builds. If it does, reproduce it in a minimal component setup and compare ResourceResolver.map() output with the rendered href. A blanket rewrite at the CDN can mask an application-level link contract and create locale errors.

Define an editor acceptance check

Before rollout, test a product and category link across languages on both author and publish. Require the public URL to be short, stable, and resolvable. Keep a redirect plan for URLs already indexed under internal paths, with canonical checks on the destination.

Adovo’s view

The URL is part of the product experience, not a by-product of authoring. If an editor chooses the right product but publish emits the wrong address, the handoff is unfinished. Test the address customers actually receive.