I built a blog with Next.js and Strapi
I need to show archive section in blog page something like below
Did you find a solution for the archiving?
I think you need to create an endpoint for archives. Relationship with Articles.
I have some idea, for instance generate month in front (I dont know how? ) when user click on them send date(month) as filter to api.
or something automatically like when create a blog post each post archived base on month
I guess you could create a CRONJOB that will run once a month.
Or I mean each archive could just have the months, and then have a relationship
I remember someone else had brought up the need for a 3rd state too but I don’t remember where and what happened to that. I too think it’s a good idea but it would need to be handled with a bit of grace to ensure we don’t have breaking changes.
I do think this fits well into what our future plans are for Draft & Publish and hopefully what will become content versioning.
Why didn’t you include it from the beginning? Directus does include it actually.
Right now, we don’t required it, but It seems there are people requiring it at the moment.
Largely because we plan a more feature rich content versioning system and we generally try to iterate on features (albeit this one has been a while since we iterated, we are actually doing so right now).
At the moment the next iteration of this feature is what we call internally “Draft & Publish v2” which provides the ability to have a published version and a single draft you are working on, then you can publish that draft and overwrite the published one.
Once we have this iteration down I believe the next is to allow multiple drafts and a history so that you will be able to achive/revert to a previous version to completely fill the “content versioning” feature but the hardest part is around versioning relations.
If you want a little peak at how complex that can get here is a diagram we made internally that roughly covers the complexities (note that these are just exploratory diagrams, not official design diagrams):
Document, entity relationship with i18n:
Sketches including relations:
If these diagrams don’t show how complex things are, trust me it’s quite a challenge (though one we are willing to take on). Certainly adding another state sounds straight forward given the current implementation but it does pose some interesting questions as we look to the near future as well.
@DMehaffy Is there any update on progress for content versioning system?
One crucial feature we need to implement is the ability for users to preview changes before making them available to the public. Currently, this functionality is lacking when an article has already been published. If an article has already been published, any saved changes are immediately published, meaning there is no opportunity to preview the changes without unpublished the article. I believe a content versioning system would fix this issue.
Perhaps there is an existing way to achieve this without content versioning?
It’ll be a focus for v5, to be transparent the whole reason we need v5 is to build content versioning. We made quite a lot of changes in v4 to try and achieve what we wanted to do but hit some breaking change blockers that required some additional things so it got delayed til v5.
V5 dev is started and we already released some of the RFCs for comment: Pull requests · strapi/rfcs · GitHub
But this is the single most requested feature from all users, community and enterprise and is at the top of our list to develop. It won’t be in the initial release of v5 but as soon as v5 stable comes out we will begin immediately developing content versioning.
In your case once v5 stable is released we will have an iteration on the normal draft & publish feature allowing for 1 draft while something is live and expand on this with proper content versioning after.