As a designer/developer for client websites I’m curious to know how you handle different requested developer/design changes on a single website.
At the moment I’m developing a news slider based on a new CMS collection (request A), and an update on an existing CMS collection (request B).
The update (request B) is approved, so I can update the site. But the request (A), while still in development and viewable on the staging site (website.webflow.io) is not yet approved.
When I update changes to the live site the update B goes live, but it also updates request A. But I don’t want to update the part that is still in development/design (request A).
And because request A is based on a new CMS Collection, I thought I’d add a switch to that collection: ‘Approved’ (answer is Yes or No), and make a filter (a.k.a Conditional logic) to not show that collection as long as that switch is set to ‘No’. Sounds doable, but I don’t want that switch on every single item in the Collection. I would like that to be a Collection general/wide switch.
Is there a way to set such a general switch on the entire collection. So when I switch that general switch to ‘Approved = No’, I can update the live site without that Collection and everything associated with it being published, so I can still keep developing within that specific part (Request A) of the website.
And after the client approves to the changes I developed and designed, I can set that switch to ‘Approved = Yes’, so when I publish to the live site all development/design changes in request A will become visible and usable.
I think a general switch, as suggested, on a CMS Collection (Approved: Yes | No) could be a great help for developers/designers when working on a live website that is actively in progress.
p.s.: I would like to post this idea for Webflow improvements, but I don’t know where.
While I am not sure if a general switch ability is possible as of now for a collection, but I found this interesting tutorial by Michael which shows how to push the CMS to staging site but still retain the old status on the live site.
Maybe you can select all items from the new collection (request A) and Queue it to publish and just push it for the staging site, so necessarily that action is done in bulk but not sure if the publishing it to live domain can be done in bulk though. I have not tested this out, but thought that tutorial might give you some ideas.
That being said, you can probably submit your idea to Webflow Wishlist here or see if some user has already requested a similar feature and upvote it.
Hi Toon, I’m not certain I’m 100% clear on the setup but in sub-Enterprise plans the general approach is to have a single person “gatekeeper” ( often you, the service provider / SP ) who handles publishing.
That way all changes are coordinated through you and when you publish, you know what’s in flux where and can lock down any loose ends at the end of a sprint.
Here you have a loose end [ A ] which you need to suppress before clicking publish. Generally there are a few ways I approach that;
For major static page redesigns, I’ve cloned and drafted the original page, and all work is being done on the drafted page. when it’s done, I’ll do a page swap and publish. The page swap is usually done by wrapping the original page content in a div and making it visibility - hidden. Then copy all of the content over from the drafted page. This avoids nav and redirect complications- otherwise you might have a lot of link checking to do.
For new section-based features, I simply suppress them with visibility-hidden, or wrap them in a DIV and suppress that div. Keeps everything right where it is but no HTML is generated.
For section rebuilds, I’ll keep the old and new sections adjacent. The old section will only be removed completely once the new section is fully published and has had a week or so to be proven.
Components. If your feature is a section or piece ( like a calculator, or a modal ) that can be isolated into a component, I’ll completely build that feature on another page, then just drop it in directly as a Component wherever I want it. Typically I’ll put those pages under a /test/ folder and password protect it, so that the client can view and test the features fully, on phones, etc. before I bring it live.
Unfortunately there isn’t any built-in feature flag capability, which is what you’re realistically describing. It can be done sort of using Optimize, but managing pre-release features is not really what it’s designed for. You could also do a reverse proxy or use a tool like Posthog, but you’d be reliant on added infrastructure and a strong adherence to specific custom attributes.
I’ve also experimented in doing this type of thing with code components. For example I have an admin component that I put all of my models inside of. It allows me to see the modals in the designer, for easy access at the bottom of the page, but only in the designer. In the published site the modals behave as normal.
Those kinds of tricks are handy but it’s an extra mechanic that probably isn’t needed, and it forces you into a component-first design approach since you can only slot other components.
In short, there are a lot of ways to crack this nut, but go for the simplest ones.
Note, if you’re using the visibility feature a lot, I recommend-
Add the Sygnal Name Helper app in the designer. It’s just a simple way to grab emoticons. Use that with Webflow’s custom names feature so that you can easily see in the nav which areas are “under development” and which are “awaiting approval” etc.
If you use Chrome, consider adding the Sygnal WFX ( webflow extensions ) browser extension from the Chrome store. It adds a few conveniences, most important one here is that items that are hidden are more obvious in the nav. They’re a darker gray and have a strikethrough so you can spot them easily.