My client’s workflow involves deleting records from their CMS, and then re-adding them when they have updates to the data. This has worked flawlessly for the past year, but now they are being prevented from doing so due to a “validation failure” due to identical slug. We do this all via API, but the behavior can be replicated through the designer/editor. That slug is important… it needs to remain consistent. And if we’re forced to do a publish to “erase” records from the database, then we fundamentally change the pages comprising the live site for whatever amount of time it takes to re-upload the new records and re-publish. We have this process down to less than a half hour, but I’m not comfortable with the knowledge that Google could be crawling the site during that period and encountering a large number of 404s. Is this an intentional change by Webflow, or is this a bug?
Hey Mark, you’d need to contact support.
I’ve seen some changes over the past year surrounding the CMS and item-publishing-states, and it looks like there’s a stronger distinction between the staging CMS vs the production CMS.
So depending on what you’re targeting in the API, that could create a weird conflict in a delete-create scenario.
Ideally an update would probably be your best bet, but you might be able to do something like delete/publish-change/re-add/publish-change.
Here’s my response from Weblow. TL:DR Webflow says the change is intentional.
I understand that you’re noticing that you’re now unable to recreate an item with the same slug after deleting it from the site.
This is related to new validation we have in place due to some of the recent CMS publishing enhancements we’ve made. Now when you delete an item that has already been published to the live site, it will need to be unpublished before recreating the item with the same slug.
If you’re using the API for this workflow, you can use the DELETE live item endpoint to remove the item temporarily from the live site so it can be recreated with the same slug.
We understand that this new requirement may not be ideal for some workflows and our team is considering additional enhancements we can make to make this user experience for intuitive.
General API V2 behaviour around drafts, publishing and archiving is now very buggy after working perfectly for months. We have registered and received confirmation of a handful of breaking changes that the WF development team has queued to fix. At moment we are manually checking products on an 8 hour schedule to be sure things are working and manually publishing as required to flush through errors.