Content type volatility and content redundancy, silent data losses

Developing with Prismic
1

We are generally happy with how versioning works for the content itself, however the way the content-types are supposed to be modified creates a major concern for scaling our usage of Prismic. There is no built-in version control (I'm aware of manual copy-paste recommendation), no publishing/scheduling process, no rollbacks, - basically nothing. And since any kind of development basically requires you to constantly modify the content types, the lack of any kind of built-in redundancy for content types is a very obvious point of a very probable failure.

Suppose we have hundreds of pages of a given content type. If a developer makes a mistake and removes/breaks some definitions, and let's say the situation is unnoticed for a week (common for larger teams), and during this time a bunch of pages get updates/republished - the data associated with those removed definitions is silently dropped, - is that correct? Are there any plans to improve this situation?

It basically makes it really hard to maintain even a medium scale, - like having multiple developers working on the implementation (they can easily overwrite each other's changes), or having hundreds of pages.

Why does the content gets silently dropped? Wouldn't it better to block the republish that will cause the loss of content with a warning? Shouldn't there be some some validations during the content type saving as well? Why there's no versioning for content types? No audit logs, no trace of what's changed.

IMO, this is weakest point of the otherwise great product and I hope you'll find these questions valid and we can have a productive discussion here

1 Like
4

Hi there,

Thank you for your extensive review. We really appreciate it.

I will try to go through all the points you have brought in details
Regarding:

Well, Prismic implemented a developer-oriented components based solution that is called SliceMachine.

By using Slice Machine, you basically build your slices locally with their model in JSON (the slice custom type), test them using Slice Machine, and then push them along with your slice code to your preferred versioning solution such as Git and your code will be the source of truth.

But I'm not sure of what you mean by the scheduling process? Do you mean the scheduling process of the deployment of those custom types?

Another feature that is being implemented is an API of Custom types where you can pull/push the entire Custom types, you can follow the progress of this feature in our Product board

I think SliceMachine can solve a bunch of the questions that you wondered about, including dev collaborations and regarding:

I think it is a good idea to have some audit logs of custom types and I create a feature requestion and send it to our @features-team.

And another valid remark that I will create feature request/improvement for is:

And I totally agree with giving some sort of warning when deleting a field in a custom type if used from any documents.

Note that the data don't get lost when deleting a field in the custom type, but it will be hidden when publishing, and if you add it again, it will reappear.

I hope that I have answered some of your questions, and feel free to reach out to us if you have more questions.

Best,
Fares

5

Hey Fares, thanks for your response, - appreciate the communication.

Slice Machine is nice and all, but it already broke our repository once (after which we stepped away from it) and I don't see it not happening in the future. Custom Types API can be tricky when several developers having parallel workflows, unless some magic merging mechanism would take care of that. IMO, the fundamental issue here is the core design, rather than lack of features. Custom type is a mutable singleton, - it would still have a high potential to break and I don't really see how (otherwise welcome) features in development would really solve that.

One real (and relatively simple) mending step that could be done is to add some sort of a version signature in custom type body, which will be verified and changed every update. Similar to what databases do with "optimistic locking", - a new update signature must match existing version, otherwise the update will fail. This will at least prevent conflicting updates to custom types and enforce sequential updates. But even in this case, some rollback / audit trail functionality is a must IMO.

I did some testing and I see that content is still visible in "rollback" versions of pages if I restore the content type, which at least makes it somewhat recoverable (although lack of content type versions can make it untraceable). Is there any situation or combination of factors that can occur currently that will result in unrecoverable content loss? If so, what can we do to avoid that?

1 Like
8

Hi there,

I have discussed this with our dev team about having some sort of versioning system of Custom Types, and I think this is a very good idea, so I will create a feature request and send it to our @features-team.

Please also note that the Slice machine is still in a Beta phase, and we don't recommend it for a production project.

Please let us know if you need any other clarifications.

9

This is being tracked as an open feature request.

If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the :heart: button to show your support for the feature and check out our Feature Request Guidelines.