Replies: 1 comment
-
I've just been reminded of this because this discussion thread has just been generated from an issue that I opened some time ago. As far as I know the underlying issue is still there, though bugs appear to be uncommon in production. Thought I'd just comment now to say that the Pressreader service also consumes content from the Fronts API via collection IDs. If the way collections are identified does ever change, it'd be worth checking for impacts on this service. (Though I don't think that provides a reason either for or against addressing the main issue here; Pressreader has some alerting set up for this, and it should be easy enough to update if needed.) |
Beta Was this translation helpful? Give feedback.
-
One of the data sources we use for Onwards containers is what we call 'curated content'. The content itself is drawn from pressed collections, and we determine which collection to use from a hard-coded list which maps pillars and editions onto container ids.
e.g. an article with the
news
pillar, coming from a UK edition request, will show 'curated content' from theHeadlines
container on the UK front.Generally speaking, these collection ids seem to be fairly stable. But (as far as I'm aware) the collection id is not set explicitly by editors but rather generated by the Fronts tool. So it's inherently pretty fragile to rely on a hard-coded list here, because the collection id could change at any time without anyone realising. This has caused at least one known bug in production, which lasted for many weeks and possibly a lot longer.
Ideally it would be possible for editors to specify which collection should be treated as the source of
curated content
for a given pillar and edition. However, this would take a non-trivial amount of work on the tools and platform sides, as well as introducing a new workflow for editors. So it would be good to hear opinions on how big an issue people feel this to be.Beta Was this translation helpful? Give feedback.
All reactions