In CraftCMS, there is an option to disable a matrix field (similar to a Modular Content block with multiple entries). This feature allows users to temporarily disable content within a field while keeping the data visible in the CMS.
This functionality is highly beneficial for our customers as it enables them to prepare content in advance, and easily publish or temporarily disable it without losing the data or having to sift through multiple revisions.
It would be a valuable enhancement if a similar feature could be integrated into DatoCMS.
Proposed Functionality:
Toggle Switch: Within the Modular Content field, add a toggle that disables a selected field.
Visual Indicators: When the toggle is activated, the field container should collapse, be marked with a red indicator, and the content will remain in the CMS but will not be visible in GraphQL queries.
Persistence: If the user reloads or revisits the page in the CMS, the disabled field should remain collapsed and marked in red. Users can manually expand it if needed.
Re-enabling Content: Users can re-enable the field by toggling the switch again. When re-enabled, the field will expand, and the data will be included in GraphQL queries.
Below is a screencapture demonstrating how CraftCMS implements this feature.
Hmm, interesting. Could you please help us better understand the use case here? I don’t fully understand what it’s doing behind the scenes (and why).
So an editor disables the field. What happens then? Does it cause any sort of actual data change (i.e. does the field disappear from API responses, or is purely a cosmetic UI change that only affects editors?)
How is it different from just collapsing the field and scrolling past it? There’s no security concern either, right (i.e. any editor can enable/disable the field at will, right? it’s not a roles/permission thing)?
If the idea is to allow editors to draft and preview changes without affecting the live site, we have other systems for that (such as the draft/published system, live previews, etc.) – let me know if you want any docs on that stuff. But I feel like this is something different, and maybe I’m just misunderstanding what the actual use case is?
The feature we’re discussing isn’t just about drafting or previewing changes (which works great in our current system), but rather it’s focused on content management—specifically, the ability to temporarily disable and re-enable content without having to go through older revisions or manually recreate it from scratch.
This feature allows users to disable content in the CMS without losing the data in that field. When a field is disabled, it will be marked in red, and the data won’t be included in the API response. However, the data remains in the CMS, ready to be re-enabled if needed.
Our customers appreciate this functionality because it provides them with more control over content management. They can easily re-enable data without the hassle of retrieving old revisions, making it easier to experiment with layouts and content rendering.
Here are some simplified examples:
Problem: Each year, we hold an event with a lineup of artists visible on the homepage. After the event, this lineup needs to be hidden, but the following year, we need to display it again with new artists. Currently, you would have to sift through a year’s worth of revisions to find and reuse the previous lineup elements. Solution: With the new feature, you can simply disable the block after the event. It remains in the CMS, but is collapsed and marked in red, allowing you to retain the content for future use without obstructing further edits to the page.
Problem: Occasionally, changes made by a customer in the CMS can cause the site to malfunction, requiring immediate developer intervention to identify the issue. Solution: With the ability to temporarily disable specific fields, you can quickly isolate the problematic content, allowing the site to remain operational while the issue is investigated. Once resolved, the field can be re-enabled, and the customer’s data will render instantly, as it was never lost.
I see now, thank you for the explanation! That makes a lot of sense. As with the other request, whether this gets implemented will depend on its popularity. But I think it’s a great suggestion, and thank you for clearly outlining its use
As a workaround, maybe you can implement similar functionality on the frontend? e.g. something like:
Assume you have an Articleblocks MCF field, which contains one or more Articleblock blocks.
Add a new “Enabled” boolean field to the Articleblock schema, something like showBlock
In the UI, editors can freely toggle that boolean inside each Articleblock (it’d just be a normal field in the block, not part of the encompassing UI).
In the frontend, a simple conditional like showBlock && <BlockComponent/> would only display that block if it’s enabled.
Adding a toggle to the Articleblocks MCF field and handling the rendering/hiding on the frontend is definitely a workable temporary solution.
However, there are some drawbacks to this approach:
API Data Exposure: Unwanted or disabled fields still send data in the API response, which means it can be accessed through the network tab, potentially leading to unintended data exposure.
UI Clutter: Adding a boolean option to a field increases the whitespace, making the field longer and less clear. This issue is similar to what I mentioned in my other feature request for enhanced content editor layout with customizable field widths.
Field Collapse Management: Since the default collapsed state is managed by the MCF field, control over field visibility is limited.
When all fields are open by default, disabled fields will also be open, which can create confusion and clutter.
Conversely, if fields are collapsed by default, there’s no visible indication of whether a field is disabled, as this is hidden within the collapsed field, forcing users to manually expand each field to find the one they need.
While the frontend solution is a sufficient workaround for now, I do keep my fingers crossed and hope we will see this feature in a future DatoCMS update.
