We've rolled out considerable changes and updates to the media editor inside the CMS's Media Area. The new update brings changes to editing images, and introduces in-CMS video editing.

If you need to edit an uploaded image, you can use the built-in editor to crop, rotate, apply predefined color filters, tweak colors, and resize images:

Similarly, if you need to edit an uploaded video, you can also do this in the CMS now, with options to trim, add filters, and other similar edits.

After you're done editing your asset, you can choose to save it as a duplicate (available under a new URL), or replace the original asset and retain the URL.

We've rolled out big changes to how editors and content creators can interact with content in DatoCMS. Instead of navigating through forms and fields in the CMS interface, editors can now see their content exactly as it appears on the live site, click directly on any element to edit it, and watch changes appear instantly.​​​​

Visual Editing lets your content editors click directly on any element of your website and edit it in DatoCMS — no more hunting through record forms, switching tabs, or guessing which field maps to which headline. Available on every plan, including Free.

Visual Editing supports two workflows. Use either one, or both depending on which approach suits your content editors best.

Click-to-edit: Content Link on your website

This is the simplest setup. Editors visit your website in draft mode, hover over content to see what's editable, and click to open DatoCMS in a new tab. It works entirely on your frontend.

This also works entirely on your website, no DatoCMS plugin required. It's a great starting point that already provides significant value to editors.

Visual Mode: Side-by-side editing in the CMS

We made major updates to the Web Preview plugin to give editors the ideal setup: preview on the left, edit panel on the right, click anything, edit immediately, see it update live.

When they click on content, the edit panel opens instantly in the same view with no tab switching required.

This plugin also enables you to have preview links in the CMS sidebar, have bidirectional navigation (scroll either panel, the other panel will keep up with context), and give you full-screen Visual Editing mode.

Getting started

We're making it as easy as possible for you to get started with Visual Editing.

We have dedicated SDKs and in-depth integration guides for React/Next.js, Astro, Svelte/SvelteKit, and Vue/Nuxt. Each provides its own <ContentLink /> component (or equivalent) that handles detection, overlay rendering, and keyboard shortcuts. Drop it into your layout, and you're done.

Want to see them in action first? Clone one of our starter kits — they come pre-configured with Draft Mode, Real-time Updates, Content Link, and Web Previews already wired together!

You can now choose whether editors can link to records, embed them inline, or both, independently controlling each option in your Structured Text fields.

The problem

Structured Text fields let editors reference other records in two ways: as clickable links or as embedded inline content. Until now, these were bundled together. If you enabled record references, editors got both options in the menu, even if you only wanted one. This meant developers had to handle two different content structures in their code when they only needed one.

What's new?

The Presentation tab in your field settings now includes separate toggles for Link to record and Inline record, alongside other editor features like Blockquote and Heading.

This gives you cleaner content structures. If you only want editors to link to products without embedding them inline, just disable Inline record. Your GraphQL queries and rendering logic only need to handle the shape you actually use.

Compatibility

All existing Structured Text fields will have both options enabled by default, so everything continues working exactly as before. To change the behavior for a field, open its settings and adjust the toggles in the Presentation tab.

We've added an opt-in configuration option to include milliseconds in date serialization across both the Content Delivery API (CDA) and Content Management API (CMA).

The problem

Until now, DatoCMS APIs serialized dates without milliseconds (e.g., 2025-12-05T00:01:00-05:00), even though the underlying data stores full millisecond precision.

When customers sort records by date, items with the same timestamp (when rounded to seconds) appear out of order. This looks like a sorting bug, but it's actually correct behavior—the records have different millisecond values that simply aren't visible in the API response.

What's new

You can now opt-in to include milliseconds in date serialization. Once enabled, both APIs return full precision:

GraphQL CDA:

{
  allBlogPosts(orderBy: createdAt_DESC) {
    createdAt  # Returns "2025-12-05T14:30:00.345+00:00"
  }
}

REST CMA:

{
  "data": {
    "attributes": {
      "created_at": "2025-12-05T14:30:00.345+00:00"
    }
  }
}

This allows you to see the full precision of date fields, makes sorting behavior transparent and predictable, and ensures consistent date formats across both APIs.

How to enable it

The change is opt-in at the project level to ensure backward compatibility. Navigate to Configuration / Available Updates and enable the "Include milliseconds in date serialization" option.

This has been one of our most requested features, and it’s finally here: you can now replace assets in your DatoCMS project while keeping the original URL.

When replacing an asset, you now have two options:

• Create new URL (existing behavior): The new asset is available immediately, but with a fresh URL. The old URL will be purged from cache and will disappear after complete propagation. Use this when you need immediate availability of the new file.

• Keep the original URL (new!): Existing links will continue to work automatically, but changes may take 5-10 minutes to appear everywhere due to CDN and browser cache propagation. Some users may temporarily see the old version. Use this when you have many existing references and want to avoid updating URLs.

Limitations

Assets can only be replaced keeping the original URL if:

• The new asset has the same file format as the original (for example, JPEG → JPEG).

• You are using DatoCMS’s default asset manager. This feature is not supported when using custom Enterprise asset storage (S3/GCP).

For full details on the related API changes, see the CMA documentation.

We're changing the default behavior when you list all records in the Content Management API to better reflect modern content workflows. The default version parameter will change from published to current, giving you access to the latest version of your content by default.

What's changing

When you list all records without explicitly specifying a version parameter:

• Previously: The endpoint returned only published records (version: "published").

• Now: The endpoint will return the latest available version of each record (version: "current"), which may include drafts, updated content, or published records.

Who is affected by this change?

This change will apply to all brand new DatoCMS projects created from today onwards. If you have an existing project that you'd like to update, you can manually opt-in to this behavior in the Environment Settings.

Please note that this change cannot be undone, so we strongly recommend testing the effects in a sandbox environment before applying the change to your primary environment.

Existing projects that do not opt-in will maintain the current default behavior (published).

Why we're making this change

This new default aligns better with common use cases:

• API consistency: When you retrieve a record, it already returns the latest version by default (current). This change makes listing all records behave consistently with retrieving a single record.

• Developer expectations: This matches the behavior developers typically expect when fetching content programmatically.

What you need to do

For new projects created from today onwards: If you want to receive only published content instead of the latest version, simply add the version parameter explicitly:

const records = await client.items.list({
  version: "published", // Explicitly request only published records
  filter: {
    type: "blog_post"
  }
});

For existing projects: Your project will continue to use the current default (published) unless you manually opt-in to the new behavior via Environment Settings. We recommend testing the change in a sandbox environment first.

More information

For complete details on the version parameter and how to filter by publication status, see our List all records documentation.
If you have questions or concerns about this change, please reach out to our support team.

Its now easier to understand the usage of API tokens associated with your project.

We've made their "Last Used Time" visible across your project settings, making it helpful for projects with many tokens to see each one's activity on the CMA and CDA.

If a token was last used months ago, its probably safe to get rid of them.

To see tokens and their usage, head over to Project Settings > API Tokens and select the token you want to see the associated activity for.

We've just rolled out a significant improvement to the plugin scope: as of today, plugin settings are synced across multiple users in real time, just as we do for records and other entities.

What's new

Until today, plugin data were loaded into DatoCMS at a few predefined moments: when opening the CMS, after installing a new plugin, and... that was pretty much it. That caused issues in some non-trivial cases involving plugins with complex parameters: if multiple users updated a plugin's settings at the same time, they risked overwriting each other's changes.

We solved the problem with the same approach with many other entities of DatoCMS: now the changes to plugin parameters are propagated to other users instantly, so that they always see the last version of it.

You can now run any DatoCMS API method straight from our CLI with the new cma:call command. No need to write custom scripts anymore, just call the method you need directly from your terminal.

The command dynamically discovers all available resources and methods from @datocms/cma-client, so you're always working with the latest API surface.

Key features:

• Dynamic discovery: All resources and methods are automatically available

• Smart validation: Validates request body requirements and prompts for --data when needed

• Flexible parameters: Supports URL placeholders via positional arguments and query parameters via --params

• Helpful errors: Clear error messages with suggestions when something goes wrong

Perfect for quick API calls, testing, automation scripts, or when you just need to run a one-off command without spinning up a full script!

We've just rolled major changes to the Site Search feature: settings for how to index websites now have a dedicated section in the Project settings, while build triggers have become leaner.

What's new

Until today, Site Search was buried deep within build triggers and tightly integrated with the build system: you could crawl a website only if you had a build trigger.

That wasn't always what you needed. Maybe on a non-static website, there's no build phase at all, but you rightly want to leverage the Site Search functions.

So we improved it to bring about a few major changes:

• Site Search is now independent of Build Triggers being used. to benefit from Site Search, you simply have to create a Search Index, and you're good to go. No more artificial coupling.

• Site Search logs split apart from Build Triggers logs. Build triggers and indexing logs are now two different sections in your Project settings.

• Independent control over indexing.  You can control when and how your sites are indexed for search purposes independently of their build process (even if you don't have one).

ℹ️ If you had Site Search enabled, your setup has been migrated to the new configuration: for each build trigger with indexing enabled, we created a search index and linked it to the build trigger.

How does it work?

Navigate to the Search Indexes section in Project settings to create or manage your search indexes:

Why the change? 

Decoupling search indexes from build triggers gives customers explicit control over when indexing happens and provides independent failure reporting and logging for indexing.

Plus, it opens up new possibilities: you can now add a custom suffix to the user-agent we use when crawling websites. With that, you can work on your robots.txt and sitemaps to get different search indexes for various sections of your website (for example, one for the blog, another for the documentation, and another for the FAQs).