Currently, developing plugins is a liiiitle more cumbersome than just "install it and configure it": you fork one to build a new version, pin an exact release, check it locally, adopt a package... etc., etc.,.

We've replaced all of that with a proper set of workflows, grouped under a new For developers menu on every plugin.

Here's what the new workflows enable:

Fork a plugin to develop against it safely. "Duplicate for development" creates a private copy of any plugin, ready to point at your dev server. It offers to disable the original at the same time, so you don't end up with two near-identical entries wherever plugins show up while you're mid-development. The copy isn't assigned to any field, so if you need to test it where the original is in use, reassign that field to the copy by hand.

Or skip duplicating altogether. "Point to local server" allows you to point the existing plugin straight at your dev server without making a copy, and start making your changes on it. It detaches the plugin from npm (it becomes private, and stops receiving Marketplace updates) until you point it back with "Switch to Marketplace version".

Bring a private plugin onto the Marketplace. "Switch to Marketplace version" points a private plugin instance at an already-published package allowing you to publish the plugin to the marketplace. Its configured parameters and field assignments are left exactly as they are.

"Switch to different version" pins any Marketplace plugin version (pre-releases included). It's how you'd stage the rollout of a new release for a popular plugin: publish it to npm without tagging it latest, pin that exact version here to try it yourself on a real project first, and once you're happy with it, tag it latest on npm so it propagates to every other project tracking the package.

Aside from these, plugins can now be disabled. A disabled plugin behaves as if it were never installed: no code loads, fields fall back to their default editor, nothing renders. The configuration of the disabled plugin stays untouched, so you can isolate a slow or misbehaving plugin and switch it back on later.

Filtering audit logs in the past meant creating queries with PartiQL, which is... not fun. No autocomplete, no syntax hinting, no inline validation, nada. Minor mistakes made queries fail, and that's not something you want when filtering out critical logs. I mean if you're filtering audit logs you're probably not having the best day to begin with, so why make it worse 😅

To make it a little more "fun", we've added a new GUI for building a filtered query, which should look very familiar to you.

No more guessing whatever a min_ulid() is, whether to single or double-quote, or what the correct query path for the record model is... (hint: it was request['payload']['data']['relationships']['item_type']['data']['id']... 😬?)

Now, just pick a date range and click to choose your filters, and we take care of the rest.

ℹ️ Audit Logs are only available on our Enterprise plans. If you want to add it to your project, get in touch!

It can get pretty tiring to scroll through all your record types when looking for something specific, so we've rolled out a new sidebar filter to make things easier.

Click on the search bar, start typing, and see a filtered list of models to create/edit content for.

What's changing

Starting from the 25 Aug, 2026, the custom palette under Configuration > Appearance won't be available as an option for new projects — it will only be possible to use monochromatic palettes. Pick a hue, and the rest of the palette (backgrounds, text, accents) is generated for you automatically, tuned for readability.

If your project was created before that date, nothing changes for you: custom palettes remain available, whether you're already using one or not.

Why we're making this change

Since early on, DatoCMS wanted to offer a way to customise the theme of a project's admin area, to give you as much creative freedom as possible over how your admin area looked. Over time, though, we heard from editors — the people actually spending their day inside these interfaces — that some custom palettes were tiring to read comfortably. After some research, we found that colour is harder to get right than it looks: contrast ratios, how a background reads against small text, how a palette holds up across every screen in the product.

That's the main reason we introduced the monochromatic system in 2024: it solves that problem by design. Every colour in the palette — text, backgrounds, accents — is engineered to meet WCAG AA contrast standards, so whatever hue you pick, the result stays comfortable to read. We've now decided to make it the standard for every project, keeping that quality bar guaranteed while still leaving room to personalize it.

We've added a small but useful enhancement into the CMS, allowing you to filter records by creator.

Simply add a new filter, and as with all others, find Creator available as a new option.

It was a bit difficult to find where your sidebar plugins ended up in the content record sidebars.

Earlier, you had to open the sidebar, find the little downward pointing arrow and then switch to the view that plugin offered.

It caused a lot of issues for many of you, and wasn't really the best UX, so we've improved it.

Now, simply open the sidebar if its collapsed, and you'll see a tab for each of your sidebar plugins neatly next to one another.

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.

If you've been building on our Real-time API, you know the drill: you fire a mutation, then wait ~1.5–2.5s before the change lands in the browser.

That wasn't very "real time", so we dug into speeding things up, and that wait is gone.

Updates now show up in roughly ⚡️ 100–500ms ⚡️

Get into the docs to implement the Real-time API.