(BUG) Archived Pages Republished, Duplicated, Mutated with Broken History

Hi there

I'm a developer (with 3+ years experience developing in Prismic) working along side content management teams and go to market teams.

We had a release the other week where we were supplicating some pages on our website with new documents (e.g page on 'this-url' of type blog_post was being switched over so the page at 'this-url' was of a new_type with more features in it).

Needing to maintain the links on production (no down time between the new document living at that url and old document being archived), the following steps were taken:

  1. During development of the new type, the documents were never published (except for one test post that was deleted) and existed in draft mode with the same URLs as the current ones, but with a '1' appended to the end (as obviously live urls cannot be reused).

  2. After development had completed and we were ready to go live, I switched off all of our Build Hooks while we made the switch

  3. I changed the uids of the old posts (appending zz to the end of their URLs before archiving them). It is important to note these old posts never had 1s appended to them. This only happened on the new type.

  4. I then updated the uids of the new posts to old ones (removing the '1') and published them.

  5. confirming the old ones were archived and the new ones were published on the correct urls, I turned the build hooks back on, and we figured we'd washed our hands of it

Instead, a content enterer pointed out today that the old posts were in fact still live and still published in Prismic.
Important NOTES:

  • the published old posts now had a '1' appended to their UIDs. We never added '1's to the old posts, only the unpublished drafts of the new type.
  • The old posts had 'zz' appended to them before they were archived. I went into Prismic to check I wasn't crazy because I had archived them myself. I found that in addition to the old posts being published/live with uids we never assigned to them, they were ALSO still appearing in the archive with the correct zz uids.
  • In addition to this, they were resolving on the live site with the original uid (without 1), but on different path (our paths are based on the type, so makes sense once the logic was removed that it changed path, but not uid though).
    • E.g it once lived here: 'blog/something/type/uid', and now lived at 'blog/something/uid' without the '1' at the end, despite their uids in Prismic containing one.

After it being flagged, I checked that no one had accidentally re-published them (they didn't), and the History indicated that it was never archived at all (despite the old posts with the correct 'zz' ids being in the archive) and had no trace of the UIDs being changed to include the '1'.

So I archived the old posts AGAIN and checked the archive, expecting two copies of the old posts (one with 'zz' and one with '1' for each). Sure enough, there is no trace that there was any duplication and only the uids with '1' show up in there now.

We will have been punished by Google now for duplicate content as a result, and we're keen to figure out how to ensure this never happens again.

For me personally as a developer, it's been really disappointing to see the direction Prismic has taken over the last 2 years. I'd been a staunch advocate (and agency partner previously) of how simple and usable it was for both developers + content managers. The Custom Types API / Legacy Builder was a simple, clean, excellent DX/CX. Since moving to Slice Machine and seeing a few other changes take place, it has definitely felt like a less reliable, more buggy and less professional experience overall. I've lost faith in Prismic and can't recommend y'all moving forward as my favourite Headless CMS :frowning: Pls help me regain confidence!

C

Hello @cassandra

Thanks for reaching out to us, and I apologize for the late response.

This is expected behavior, and it is happening because the UID field stores all previous values and allows you to query the document with these, even after the value has been changed. It was designed this way so that the old link using the old UID value would still work (you wouldn't end up with broken links everywhere when you change the UID value).

So we recommend adding a check that compares the UID used to the current UID value. You redirect to the page using the new value if it's an old UID value.

I hope I have answered your question. Let me know if you have any further questions.

Thanks,
Priyanka