Proposal: Supporting External Canonical URLs

[meg-delaunay]

No description provided.

[gengel]

When fetching a document with an external_canonical_url from Content API, will the canonical_url field be automatically replaced with the external value if present?

It seems like there are a few ways of handling this, each with their own risks.

One approach is to answer No. The external canonical url will be a separate field and it is incumbent on the front-end implementation to make external canonical urls work, or not work. The risk here is that now you have a field in Composer and other tools that editorial users can "fill in" a field that does nothing. (Or, feeds can ingest content that does nothing.) Pro: Simple, non-breaking option for site visitors.
Con: Requires developer time to adopt. Every front end implementation

The second approach is to answer Yes. The external canonical url is a workflow field and should automatically populate where appropriate. The upshot is that users can immediately begin setting this field without changing any front-end code and get the benefit. (And arguably, this is a more seamless CA user experience, but perhaps also more "magic.") The risk is that if implementations have assumed a relative url, or are using an explicit pattern of appending a domain, this would likely be a breaking change.
Pro: Instant adoption. Non-breaking change for editorial. "Magic" API experience. (No need to explain how overrides work to front-end devs.)
Con: Potential breaking change for site visitors.

A third approach is to split the difference and create a new, projected field that is non-breaking but always has the "correct" SEO url when fetching a document. (Not sure what we'd name it, maybe seo_url?) This would return either the appended domain + relative url of in-house content or the absolute url of the override, and also be a non-breaking change to boot. So the new prescriptive Arc recommendation could then to be "Always use seo_url and it will have the Right Value."
Pro: Non-breaking, single field to use on rendering side. "Magic" API experience. (No need to explain how overrides work to front-end devs.)
Con: Legacy customers will requires developer time to adopt. Yet Another URL Field could lead to confusion.

Ultimately I think we need to have a committment to add this field on the Composer and Themes side, and understand how these three systems (including CA) will interact, before we can comfortably add to ANS.

[meg-delaunay]

Two thoughts:

1. I think there's another option, similar to your option 3, where external_canonical_url is always the field front-ends should use. The Content API "magic" here would be that if a user did NOT set external_canonical_url explicitly, to populate it to canonical_website+canonical_url. In this way, the front-end could always use the same field and there is some workflow behavior happening "magically", but without touching canonical_url. I will strongly advocate against anything automagically touching canonical_url.

2. Second:

One approach is to answer No. The external canonical url will be a separate field and it is incumbent on the front-end implementation to make external canonical urls work, or not work. The risk here is that now you have a field in Composer and other tools that editorial users can "fill in" a field that does nothing. (Or, feeds can ingest content that does nothing.) Pro: Simple, non-breaking option for site visitors.
Con: Requires developer time to adopt. Every front end implementation

This is the default option I was imagining in my mind. It makes this feature available but fully opt-in, which seems like the highest amount of flexibility for the platform. It can become the default option going forward, but avoids any risk of breaking current implementations. Whereas, for example, backfilling canonical_url c/would be a huge breaking change for many.

Regardless, totally agree that the conversation with PB and Editorial App representatives is required as those are the teams that would need to actually do any of the work.