First of all, let me thank you for a really awesome product. I’ve been searching for a long time for a suitable CMS for our React migration, and I think that I’ve finally found what I’m looking for. Squidex ticks all the boxes of what we require from a CMS and we’ll most likely be starting to implement it in our test environment soon.
As you can see, the functionality is pretty simple, as the actual preview functionality will reside in the application consuming the API. The only thing that Squidex needs to do is to tell the consuming application what specific content that the user wishes to preview.
If needed I could probably whip up a pull request for this. But it would probably take until after the new year before I would have time to do that.
the API also allows to retrieve unpublished content with the X-Unpublished header. What I did for me website was introducing a “secret” query parameter. So whenever I added “?SUPERSECRET” to the url I add this header to my requests and also see unpublished content.
Of course the preview urls are more convenient for content editors, I think contentful has them.
Yes, the X-Unpublished header is something that the consuming application would have to implement in it’s preview functionality, as long as it can get a reference of what content to preview.
I concur with Niklas, it would be a nice addition, even for a headless CMS.
In order to keep flexibility and the headless philosophy, the preview should be a collection of named urls with configurable routes since, in our use case, a content item could have multiple views/endpoints/urls, e.g. : web, mobile app, api, etc…
It could be implemented as a preview button with a caret + dropdown and a named list (web, mobile app, and so on)