Let me be straight up here.
You really, really don't want to do this. Really.
Just find a different solution. Replace your CMS with post-it notes. Change platforms if you must. Even quit web development altogether. Dance instructor sounds nice, yeah?
You'll understand why, soon enough.
So it turns out there's some very weird behavior in the way Webflow internally assigns field names in the CMS. For most of us, this behavior is invisible. But if you're using Webflow's CMS API directly, you'll run into this.
Here's how this weird internal field-naming behavior appears;
- If you create a field in the Designer CMS named Field 1, it will appear in the API JSON as a field key of field-1.
- If you then rename that field to Field 2, it will still appear in the API JSON as field-1. It will stay as field-1 no matter how many times you rename it.
- If you delete that field, save your CMS, and examine data through the API, you'll see that field-1 is now gone, as expected.
- But if you create a new field named Field 1, the new field will appear in the API JSON with a number appended, as in field-1-1.
There's actually an explanation for this weird behavior that makes sense. If you're interested, read this article to learn more.
Here, though, we want to look at the nuclear solution for fixing these fields- because the only way is to rebuild your Collection entirely.
I'm documenting this, because I've had to do this for clients before, and it just might save someone's butt someday.
But for the sake of your sanity, I'd encourage you to try every other solution first.
How painful is it?
If this is a LIVE site, with a big collection, bound to a lot of collection lists, and has lots of refs & multirefs into it from other Collections… then this is going to be a bit like 3am open-heart surgery.
If the site draws visitors globally 24/7, you’ll be doing that surgery on a moving train with people yelling at you.
I happen to do that kind of thing much too often.
Often enough that I've had to develop a process for it.
Here you go.
How to Rebuild a Webflow CMS Collection, Entirely
For ease of documentation, OC = old collection, and NC = new collection.
- Back up your site, in case of emergency.
- Pause any external systems or automations that are reading/writing data from OC.
- Block any FORMs or user actions that trigger those external automations.
- If this is a busy site at 3am, consider taking it “offline for maintenance.”
- Export your CMS Collection content as CSV
Phase 1- Move the old Collection
- Rename your OC’s Collection slug. I’d append an -x, to differentiate. There’s a chance users could see this, so you don’t want e.g. -old.
- To your OC’s Collection Page, add a <meta name="robots" content="noindex"> to the </head> custom code. We don’t want Google indexing this page at the temporary path.
- Publish live, to make sure everything is sync’d at Webflow’s back end.
- The site will still be 100% functional, just with that -x in Collection Page URLs.
Phase 2- Create the new Collection
- Create NC, your new CMS collection at the same slug OC was originally at.
- Be very careful to name the fields correctly, once, because the internal field-key that is generated will be permanent.
- Create one record in your CMS
- Verify the JSON through the API, to make sure you have exactly what you want
- Load the CSV into the new Collection
Phase 3- Switchover
- Fix any Reference or Multi-Reference fields in other collections that are referring to OC, they now need to refer to NC, and you’ll have to update that data.
- You can find these in part by deleting all of the items in OC. Any that are linked to from other Collections will throw errors, and help you find that linked item.
- Build out your NC Collection Page. On your OC Collection Page, you can unlink OC-bound items, and then copy those elements over to NC, and re-bind them. Yeah, I know. Agonizing.
- Finding these OC connections is made much easier by Webflow’s “View Connections” tool, which you can find at the bottom of OC’s Collection Settings page in the CMS.
- Copy over your custom HTML Head and Body code, but obviously not the noindex meta we created above.
- Publish to Staging ( webflow.io ) only. Verify that the new Collection Page is functioning properly, and the data looks good.
Phase 4- Switchover Cleanup & Validation
- Delete OC
- If anything is still bound, you’ll get errors… fix those bindings
- If any other collections reference OC, change those to reference NC.
- Publish to Staging, retest your changes
- Publish to Prod
It’s 6am now, go celebrate with a beer.
What about Rich Text fields?
Webflow’s Rich Text fields have a link-builder with the ability to link to a specific CMS item- however that link is not tracked.
If you rename that collection, or change the item slug, that link will not be updated and users clicking that link in your blog / press release / uni course will get a 404.
However, in this particular workflow, your NC will end up at the same slug, and with the same item paths that OC had - so at the end of the operation, all of those links will work fine again.
So why is this insanity needed?
Interesting stuff, but that part got too long, so I’ve done a blog post here.