The DatoCMS Marketplace now shows you which plugins are "officially" developed by us with a little icon next to each one.
While this definitely makes it easier to find, official plugins are also our responsibility to maintain and keep up to date: so if something breaks or works unexpectedly, just give us a ping.
They're all categorized as a section within the Marketplace on the website and in the CMS.
And you can easily tell it is an official plugin with the little icon.
Until now, using Visual Editing meant clicking something in your preview and jumping straight to the record that renders it. It only lived in the iframe inside the plugin's Visual tab.
Now you can turn it on in the sidebar preview in the Content tab as well 👀
Click an element in the preview and you land right on /editor/item_types/<id>/items/<id> within the exact field behind it without hunting through the tree.
A few things worth knowing:
It's a per-user toggle, off by default: each editor flips it on for themselves, so it won't change anyone else's setup.
When the toggle is on, the sidebar loads the draft-mode preview URL (that's what visual editing needs to hook into).
If the selected preview link's frontend doesn't support visual editing, the toggle stays visible but disabled, with a tooltip explaining why.
Under the hood it's the same Content Link machinery that already powers the Visual tab, just wired into the sidebar frame, so refer to the docs to set up Visual Editing.
Sometimes all you get from a terminal output is a Record ID and nothing else. Made it kinda hard to find that record in the UI if you wanted to check for something. The filter by ID wasn't the best way, especially if you didn't know the item type.
So we've rolled out the ability to search by ID ✨
Open the UI, click the 🔍, enter the Record ID, and it'll surface right in the UI.
You can now disable Content Link (visual editing) encoding on a per-field basis, right from the field settings. Fields whose exact value matters — slugs, external IDs, keys, anything compared verbatim — can opt out, so the Content Delivery API never wraps their value in invisible visual-editing metadata.
A quick refresher on how Content Link works
Visual editing lets editors click directly on any element of your live site and jump straight to the field that controls it. It works through steganography: when you request draft content with Content Link enabled, the Content Delivery API embeds invisible Unicode characters into your text fields, encoding which record and field produced each string. Your <ContentLink /> component reads that metadata and paints the clickable overlays. Visually, nothing changes, but that invisible metadata is exactly what you don't want on certain fields.
The problem
Because the encoded value carries extra (invisible) characters, it's no longer byte-for-byte identical to what you typed. That's harmless for prose, but it breaks anything that treats a field as a literal:
A slug field with the value about no longer ==="about", so routing and equality checks fail.
IDs, keys, and tokens used in comparisons, switch statements, CSS selectors, or data- attributes silently misbehave.
Until now, the fix meant calling stripStega() on the values that needed it. That still works, but it's easy to forget and easy to miss one.
What's new
Open any string, multiple-paragraph text, or structured text field's settings, and you'll find a new toggle:
Leave it on for the fields your editors want to click into. Turn it off for the fields that need to stay verbatim, and the CDA will exclude that field from Content Link encoding entirely and the value ships clean, no stripStega() required.
The toggle is enabled by default, so nothing changes for your existing projects unless you opt a field out.
Under the hood
A new content_link_enabled attribute is exposed on the field, defaulting to true.
The opt-out is available on the field types that participate in Content Link encoding today: string, text, and structured_text.
When disabled, the exclusion happens server-side in the Content Delivery API, so it applies no matter which client or framework SDK you use.
We've added a small but meaningful safeguard to DatoCMS accounts: email verification. Before a handful of sensitive actions, we now make sure the email address on your account really belongs to you. It runs quietly in the background, and most of the time you won't even notice it.
When it kicks in
We only ask for a verified email before actions that affect other people or move projects between accounts:
Inviting someone to your organization
Transferring a project to another account or organization
Accepting a project that's being transferred to you
Joining a project or organization you've been invited to
How it works
When you sign up, we send a confirmation email. Click the link inside and you're verified for good.
If you reach one of these actions before you've verified, we'll pause and send that email for you automatically (or resend it, if it's been a while). Click the link, and we'll pick up right where you left off, with nothing to redo and nothing to start over. You'll only go through this once.
Dark mode is now available in your DatoCMS dashboard, too. Manage your account, projects, and billing in a theme that's easier on the eyes during long sessions.
Choose System, Light, or Dark from the menu under your avatar. Your preference is saved to your account, and the dashboard follows your OS setting until you pick a side.
The version history of a record now doubles as a publication timeline. Every version tells you not just when it was created, but the exact window it was actually published (and a green dot shows you which version is currently published).
Before this, the version history panel only showed when a version was saved and by whom. This change makes it simpler to understand when they were published.
Asset history
What's new
Open any record's history, and each version now carries its publication info under the timestamp:
Live since X — this version is published and currently live, with no end in sight.
Live from X → Y — this version was public for a stretch, then superseded.
Live on X, HH:MM → HH:MM — published and replaced the same day, down to the minute.
A redesigned visual indication ties it all together:
A green "live" dot marks the version that's currently published.
A muted dot marks versions that were live at some point in the past.
Each entry now credits the editor who made the change with a "Edited by …" so the timeline reads as a full audit trail at a glance.
Under the hood
The publication ranges are backed by new metadata on item versions — published_from and published_until — exposed through the Content Management API. The dashboard reads them via @datocms/cma-client 5.5.1 or higher.
This is a forward-looking history: we don't retroactively reconstruct intervals for versions that were already live when the feature shipped.
If you publish a version, unpublish, then re-publish that same version with no edit in between, the new published_from overwrites the previous one and published_until is cleared. The version reflects its latest interval rather than a full multi-interval log. In practice most workflows save an intermediate version before re-publishing, which produces a fresh row and preserves the earlier one.
Heavy on video usage and want to set a specific frame as the thumbnail from within the CMS itself? Now you can.
TL;DR: You can now choose the poster frame for any video right from the asset editor. Choose the perfect moment, pin it, and that frame becomes the video's thumbnail everywhere. No re-encoding, no external tools, no guessing which frame the player will grab.
How it works
Open a video asset and you'll find a poster picker built right into the player:
Head to the frame you want. A pin on the seek bar marks the current poster frame, aligned precisely to the player's timeline so what you see is what you get.
Hover the pin and a large, high-resolution thumbnail shows exactly how that frame will look as the poster, sized to fit whether you're in the media area, a modal, or the sidebar.
Select Use current frame as poster and your choice saves instantly.
Under the hood
The chosen frame is stored as poster_time (in seconds) inside the upload's default_field_metadata, the direct video analogue of focal_point. Like the focal point, it's a non-localized, per-asset default, so it travels with the asset and is available through the Content Management API for your front end to consume when rendering posters.
Thumbnail selection is precise to the hundredth of a second. The time readout shows m:ss.cs, so you can land on an exact frame rather than a rough area — 1:04.27, not "somewhere around 1:04".
Getting correctly-sized responsive images used to mean adding a sizes prop that mirrored your CSS layout, and keeping it in sync as the design changed. No more. Update any DatoCMS framework SDK and you can stop dealing with that.
Responsive images were a burden
The whole point of a responsive srcset is to let the browser pick the smallest image that still looks sharp. But to choose, it has to know how wide the image will actually render, and it needs that number up front, while parsing the HTML, before any CSS or layout exists.
It can't measure the element itself, so the job fell on you: hand-write a sizes value mirroring your CSS layout, and keep it in sync every time the design changed.
Hello, sizes=auto!
Browsers now have a proper fix: sizes="auto". On a lazily-loaded image, it tells the browser to use the element's real, laid-out width when choosing a srcset candidate. Because a lazy image is fetched after layout, the box is already measured by the time the request goes out, so the choice is exact, not estimated.
When you don't pass an explicit sizes prop, all four framework SDKs: react-datocms, vue-datocms, @datocms/svelte, and @datocms/astro, now emit sizes="auto" (with 100vw kept as a fallback) together with loading="lazy":
Upgrade the package and your existing <Image> components start requesting right-sized files on their own.
Under the hood
If you pass an explicit sizes prop, or your responsiveImage GraphQL query already returns a sizes value, we never override it.
Images marked with the priority prop load eagerly, and sizes="auto" requires loading="lazy", so they keep their current behavior.
Every SDK component already sets aspect-ratio + width: 100% + a max-width, which is exactly what auto needs to resolve to the correct box, so the default styling already does the right thing.
Browser support and graceful fallback
sizes="auto" is supported in Chrome and Edge 126+, Opera, Samsung Internet, and Firefox 150+. Safari doesn't support it yet.
That's why we emit sizes="auto, 100vw" rather than a bare auto: browsers that don't understand auto skip it and fall back to 100vw — the safe default that's been the de-facto, so there's no regression anywhere.
