Strapi Version: 3.4.6
Operating System: Windows 10 (installed vis WSL2)
Node Version: 12.18.1
NPM Version: 6.14.5
Yarn Version: 1.22.10
A feature I desperately need is the ability to write drafts.
I am aware that there is a “draft and publish” feature within Strapi, however this works similar to an enabled/disabled or available/unavailable state.
We need a live published page and a draft page to sit in tandem.
Scenarios where this is useful:
A homepage / landing page of a website is usually quite flexible and the content can be moved/edited around most of the page.
The marketing department may want to build out the page in preparation for a big launch of something but then save this as “draft” (while the current content is saved and live) and then release the draft on a specific date.
Being able to preview a draft state
The current “draft and publish feature” doesn’t accomplish this as it simply turns the page “on” and “off”.
My current work-around
The only way I can think of solving this is by changing the homepage into a collection not a single type, and then having a field to say which one should be the live homepage.
This isn’t ideal, but it would work.
Has anyone else ran into a similar problem, and how did you solve this?
How can I have a live published page, while also saving draft content to view on a preview url (using something like next preview) and replace live content at a later date?
Hi Ben, I recently ran into the same need. I’ve solved it for now with a bit of Strapi customization, but I’m not sure how well it will scale in the long run. Disclaimer aside, what I did was create a table (we’re using postgresql) for “revisions” that stores some timestamps along with a json representation and lastly the corresponding model name. Then I customized the content-manger plugin to create a snapshot of the content on create, update, publish, unpublish (kind of like an audit table). With that, I tweaked the admin ui such that any time a user edits and saves content while it’s in the published state, it then goes to a new “revised” state. While in revised state, the api serves the most recent revision if the _publicationState=preview (or not specified), but if the _publicationState=live, it serves the last published version. I don’t know if that makes sense, but this is the general approach I took, and it seems to be working for the time being. I’d love to see this as a fully supported feature someday. Hope that’s somewhat helpful!
Yes I’ve just run into this problem!
I went through this using a different means … cloned the record and saved it as an unpublished draft copy. Note: you can not query by ID after this fact - the new record has a new ID, however, if you persist a tag like “home-page” on the record, you can switch to the unpublished when ready and remove the tag on the published or unpublish that. The draft becomes the production when ready and published.
At the moment we don’t currently have this feature but we are planning to build a “Content Versioning” system. The primary reason we needed to develop Strapi v4 was as a pre-req to this type of feature.
@DMehaffy I’m looking into using strapi and this is one of the required features my client asked for.
Is this something that will be release with version 4 or is it further down the line, like say version 5?
Thank you for all your work!
We do plan to add content-versioning I believe within v4 (although not initially on first release).
Most of the major backend changes that are happening in v4 right now are pre-reqs for us building content-versioning. (this is also easily the most requested feature we have right now, trust me it’s high on our priority list but we don’t have an ETA yet)
any news here? this feature would be really useful.