Skip to content

Latest commit

 

History

History
49 lines (30 loc) · 3.63 KB

rfc-036-stop-preserving-order-for-links.md

File metadata and controls

49 lines (30 loc) · 3.63 KB
Raw

Problem

A links hash in a content item looks like this:

"links": {
  "lead_organisation": ['ORG-CONTENT-ID'],
  "organisations": ['ORG-CONTENT-ID', 'ANOTHER-ORG-CONTENT-ID'],
  "topics": ['TOPIC-CONTENT-ID'],
  "available_translations": [... automatically generated ...]
}

The array of links is currently guaranteed to preserve its order when sent to the publishing-api. From the content-store documentation:

The list_of_links is an array of content items, order is preserved.

https://github.com/alphagov/content-store/blob/4b4a82a279de11a2af27b05dfc61d5f18a250c75/doc/content_item_fields.md#links

The order preserving complicates the following things:

  1. Complicates tagging tools. We are building a generic tagging tool that defines the relationships between content items. It shouldn't be concerned with how these relationships are presented on the site.
  2. Complicates implementation.  The publishing-api currently saves the links array and forwards it without manipulating it. To build a more flexible system, the links are being extracted into it's own table (https://trello.com/c/zppxFP6p). We'll lose the "free" preservation with that change and will have to add code specifically to preserve the ordering.
  3. In most cases, the ordering of the links should be a presentation concern anyway. For example, the collections-publisher app sorts the related topics by title before sending the links to the publishing-api, which effectively reserves the related_topics for this use. Contrived example: if we were to use the related_topics on a prototype sorted chronologically, it would need to "override" the ordering specified in collections-publisher. It would be confusing that sometimes the ordering is defined on the frontend, and sometimes by the publisher.
  4. It's easily abused to add meaning. We use the first item in the sections tag in govuk_content_models for the breadcrumb (code). This means we can't easily query "pages that have x as their breadcrumb".
  5. It may make  bulk tagging  more difficult. (we don't have a specific plan for that, but I can imagine a case where a bulk-action of "remove mainstream browse page tag x from these content items" would change the breadcrumb for some items, but not others)

Proposal

  • We stop guaranteeing the order of the links.
  • During the tagging migration we get rid of the usage of the first item as breadcrumb.  

Impact

  • Audit pages using links to make sure nothing is using it.

Impact on breadrumbs

Our proposal is to add a parent tag-type and populate it during the tagging migration with the primary mainstream browse page. We also make sure this tag is merged back into the section tags (in the TagUpdater) to keep current breadcrumbs intact.

This parent type would then be usable by all apps to populate a breadcrumb. Content-store would recursively resolve all the parents to return this in the item: