▼
Streaming live at 10am (PST)

[BUG] Delete CMS Item via API

Community resources Bugs
#1

I have a CMS collection. I’m using Integromat to delete an item from the CMS Collection. In Integromat I’ve tried both the built in Webflow app in Integromat as well as bypassing the app and hitting the API directly. In both cases, it appears that the delete processes properly as the result of both calls return a “deleted=1”. All good…until you refresh the list of CMS collection items on a page and realize…it’s still there.

I thought, let me check the actual CMS collection list of items in the designer and see if it’s still there. Nope, it’s gone…

So, if it’s been deleted via the API and when I look at the same list in the designer and it’s not there, how can it still be showing on the front end of my website?

There is a bug. :slight_smile:

The only way to remove it from the list on my site is to re-publish my site again, which seems to clear things up. Clearly, that’s a problem.

Here is a detailed video showing the same:

No share link is provided as it’s not needed. I recorded it.

2 Likes
#2

I think you can edit “live cms item” instead of just “cms item” in Integromat. Have you tried that?

Deleting anything in the cms will need a fresh “publish” even if you do it right there in the designer. No changes will affect the live site without a publish.

#3

@Fonsume you can certainly edit live CMS items in Integromat (or even via a direct API hit). I’m deleting the CMS collection item. There should be no need to re-publish after deleting a CMS item from the API otherwise it would make deleting from the API pointless. Per my video, when I delete, it deletes it from the API and Designer point of view. It however does not “delete” it from any CMS collection output on the front end.

A workaround is to make a field called “is_deleted” or something in the CMS collection and “update a live item” to a “true” value and only output “is_deleted” is off. However, I’d have to perform that update, then actually process the delete on the item so that when on the next publish it actually clears the deletes.

Nonetheless, that’s a drastic workaround when the entire objective is to simply delete it entirely.

1 Like
#4

My point is that there’s a difference in the api between an unpublished/staged cms item and a live cms item. Not being able to delete something from the live site seems to be a safety measure, not a bug.

You can set Integromat to archive the live item, then delete it right after (meaning you’re staging it for the next publish). That way it’ll disappear from the live site right away. Alternatively you could make Integromat publish the site.

2020-03-03 20_39_10-Integration Webflow _ Integromat

I just tried this now and it’s working as intended.

#5

THAT SAID. The whole API is pretty lackluster. I’ve been tearing my hair out trying to delete old blog posts that have cross references with many other posts through multi references. I’d very much like a “force delete” option.

#6

I understand your point about it being a safety measure, but for whom? In my video, I point out clearly that once I run the delete an item, I can no longer access it from the API NOR the Designer. So, how do I recover it if it was a safety measure? I don’t, it’s gone…because I deleted it. Webflow has a bug that does not recognize deleted items in the same sense as a “live” CMS update. It’s as if it deleted it in a “staged” state but you still cannot access it.

The idea of saving as a draft first then deleting it provides no more safety than a straight delete, you just provided an extra step in the process to overcome the bug (…and transparently, what I’ll clearly have to do in order to overcome it for now).

Publishing the site, via API, is not even an option as it has several legit safety issues. The client may not want content to be published to the main domain, yet my auto-publish would do that.

Your example of API not deleting records if bound by other linked references is a legit safety measure, especially if the linked reference is a required field.

I do appreciate the thought on this (and the chat)! Thanks

1 Like
#7

It’s the same if you manually delete it in the CMS system. It’ll be removed from the staging area, not removed on the live site. I guess it’s a lame safety system for recoveries, but it seems intentional and is how pretty much every other staged thing works on Webflow.

Pretty sure you can define the domian you wish to pubish to in the query.

#8

Just doing a sniff around on integromat scenario issues. I wonder if you guys have tried uploading a file when creating an item with the create item module. I think there is a bug as I can’t get any file to upload. (restrict file access is off in webflow settings)

An Open Letter to Webflow
#9

I support that bug report and add a little bit more. I’m doing actual API calls via GCP functions and making sure things are right by calling the same using CURL. The issues are as follows:

  1. removeItem call does remove it from CMS, but you’d have to publish the change so that it propagates to the site. As it’s explained above, there are multiple scenarios when we’d rather not publish the site - there might be pending design changes etc.
  2. There’s no live option for removeItem call. So this entire functionality about removing an item has very limited use cases.
  3. updateItem and patchItem API endpoints as of yesterday stopped accepting live changes when you call it with explicit _archived: true with quite an ambiguous message

A live update cannot be applied to a drafted or archived item

which is I understand has to be read this way: “you can not change archived status in live mode”

Therefore, there’s no way to take an individual item off the life site via an API call without republishing the entire website. This is quite a severe overlook from the architectural/engineering point of view and should be classified as a bug.

2 Likes
#10

I’ve come across this too. Major design flaw (unless this an intended feature?).

#11

This can’t be intended as it is conceptually inconsistent. Also, observed behaviour has changed significantly over the past few days.

Is this the only way to reach Webflow support or technical team? I’m rather new to the platform, and it’s being actively promoted everywhere, but feels like API is not quite production-ready.

Pull data from Google sheet to display dynamic content
#12

You can try support@webflow.com. But I don’t think you will get very far, read this thread here with someone else’s recent experience trying to get answers.

#13

Yes, I too was bummed out when removeItem did not support “live” items. And like you, doing an auto-republish on item delete is NOT the way to go.

Our workaround was to set a switch field on each item, and then instead of deleting the item we live update the switch to false. Then in our presentation view we just filter the collection for switch = true.

That is not ideal in many ways, but there’s no sign of the Webflow Tech team stepping up and addressing the many flaws with the API… :frowning_face:

1 Like
#14

Just wait until you hit the issue of trying to delete an item which is referenced in another item. It quite simply does not work. You have to search through all other items to find the referenced item and remove it first. Takes me like 60-100 calls to the API where it should be 1.

1 Like
#15

Thanks for sharing your work around. I will give this a go next time, seems like it makes sense. Well, as much as it can.

#16

This might not be a bug as I’ve seen other content API’s treat this process in a similar way. Earlier this year we worked a pretty huge live intranet for example, and their backend people enforced a similar api approach to removing pages and articles.

We could delete an item from the CMS but it would only pick up on next publish cycle since the backend did sort of a garbage disposal on publish/build to make sure no orphan content would build up and no dead links would remain in the build. They did have a force field on the endpoint though, but we were discouraged from using that by default.

#17

updateItem and patchItem API endpoints as of yesterday stopped accepting live changes when you call it with explicit _archived: true with quite an ambiguous message

Thanks for the report! this change was unintentional and was reverted yesterday morning.

3 Likes
#18