In an attempt to enhance the discoverability of the diverse editors available for each field type, we've just rolled out a minor visual tweak to the field editing form.

Now, for all the various editor types that Dato natively offers for each field, there's a small illustration that exemplifies the final result on the content editing side:

In case a plugin that has been installed adds extra editor types, these will be shown in the user interface with a universal Plugin icon:

In future versions of the Plugin SDK we might allow customization of the illustration associated with each field editor... but one thing at a time! 😉

We understand the importance of safeguarding critical environments, and based on valuable feedback from our users, we're introducing a significant enhancement.

With the addition of the new flag "Force the use of sandbox environments" under Project settings > Global properties, admins now have the option block any change to the schema and configuration of the primary environment:

Developers can now work confidently, knowing that destructive actions are disabled, while users still retain the ability to navigate and edit content in the Content and Media Area tabs.

Activating this feature enforces best practices such as migration scripts and sandbox environments, minimizing the likelihood of unintentional changes or footgun situations in production.

After receiving feedback from our customers, we have decided to make improvements to our translation approach.

Currently, the entire CMS interface is translated into 15 different languages. However, upon reflection, we realized that this may not have brought significant benefits; in fact, it might have posed some inconveniences.

Our developers' documentation is only provided in English, which means that the DatoCMS glossary and terminology specific to our domain is expressed in English. If the localization settings in the CMS are different, developers may struggle to follow our docs, and find the same entries in the CMS interface.

We also know for a fact that developers are fairly comfortable with English, and translations primarily benefit content writers and editors, who may feel disoriented with English.

As a result, we have chosen to maintain the sections of the app that can only be accessed by developers exclusively in the English language. This includes the Schema, CDA Playground, and Project Settings tabs.

The translation work will also be much easier with the significant decrease in the number of strings to be translated. Our translation process for DatoCMS relies on our wonderful community of users, so if you would like to help us by improving existing translations in your language or suggesting additional ones, please contact us via email. We provide €500 in platform credits for a complete localization.

A slug field previously needed a mandatory string field as its reference field. However, from today onward, slug fields no longer enforce this requirement.

No changes have been made to existing slug fields.

The schema UI will continue to suggest using a reference field because it is the most common option, but you now have the ability to uncheck the validation:

A simple but very welcome validation just landed for Single-asset, Asset Gallery and SEO and Social fields: the ability to require a specific aspect ratio for the uploaded images:

By enforcing a specific aspect ratio, you can ensure that all images displayed have a uniform appearance, thus maintaining consistency and aesthetics in the presentation of assets on your website or platform.

We're delighted to announce the release of an improved navigation system inside DatoCMS projects. It offers the same simplicity you are familiar with, but with an improved user experience.

Here are the main changes:

✅ The new Project Settings area lists all the global settings

✅ Environment-specific configuration happens in the Configuration tab

✅ Models and blocks are now under the Schema tab

This result comes from our commitment to continuous improvement: it is just the beginning of larger changes, always guided by user testing sessions and your precious feedback.

We are excited to announce the public beta release of one of our most requested features: Deep Filtering!

Deep Filtering enables the Content Delivery API to filter records based on the content within their blocks. This functionality is supported in both Modular Content and Structured Text fields.

To learn how to activate deep filtering, and learn everything about the filtering options it enables, please refer to its documentation page.

We've heard your feedback and understand the frustration of not having, for example, alphanumeric Model IDs included in webhook updates about records.

It makes it difficult to identify the model involved, forces you to make additional API calls, slows down the response.. well worry not, because we have a solution! Please welcome Enhanced Webhook Payloads.

DatoCMS now includes a new key called "related_entities" in the payload of all webhooks. This key contains an array of all the entities that are linked to the main entity (that is, the one that triggers the event itself).

As an example, let's see the new webhook payload sent for a "record update" event:

1
{
2
  "environment": "foo-bar",
3
  "entity_type": "item",
4
  "event_type": "update",
5
  "entity": { "type": "item", "id": "348295724", ... },
6
  "previous_entity": { "type": "item", "id": "348295724", ... },
7
  "related_entities": [
8
    { "type": "item_type", "id": "7690234", ... },
9
    { "type": "user", "id": "69003345", ... },
10
  ],
11
}

Since the Record entity offers relationships with its model and its creator, both objects will be fully included in the webhook payload. This makes it really easy to consume them, and for example, extract the information about the Model ID.

In the case of webhook events caused by changes in Models, the number of related entities will be far larger, as the Model entity offers relationships with all of its fields, fieldsets, etc. Again, very useful data when you need to interact with a model!

We want DatoCMS to be simple and just work©, so we won't be adding any options to enable this behavior. Enhanced Webhook Payloads is already available to everyone, by default.

We hope this new feature saves you time and makes your workflow smoother. Happy coding!

Starting from October 18th, we'll be boosting security and capabilities by changing how we generate IDs for new entities in project environments. Instead of using numeric IDs, we'll switch to using base64-encoded UUIDs. This enhancement will bring significant improvements, with no impact on the vast majority of integrations.

The shift

Traditionally, when you've created new entities such as records or models, the auto-generated IDs have been in the form of incremental numeric strings (e.g., "43012949").

However, we are excited to share that starting from October 15th, there will be a transition in the format of these IDs for newly created entities. The new format will be a 16-byte string, closely following the RFC 4122 UUID (Universally Unique Identifier) standard. These new IDs will be expressed in URL-safe base64 format, without any padding, as defined in RFC 4648 (e.g.,"X9_l7IdvRq26r7e2wn353Q").

Benefits

The benefits of this change will be far-reaching, both immediately and in the long term:

• Enhanced Security and Data Privacy: Incremental numeric IDs, while functional, can sometimes inadvertently reveal patterns in data creation and usage. The utilization of UUIDs, which are essentially random and not predictable, will significantly bolster the security of your data.

• Future-Ready Decentralization: The adoption of UUIDs will enable us to introduce future enhancements to our API, allowing you to explicitly specify desired IDs when creating entities within environments. This advancement opens doors to exciting scenarios such as batch imports and more robust auto-migrations between environments, all achieved without centralized coordination.

What does this mean for you

What does this mean for your projects, and your integrations with DatoCMS APIs?

• Existing IDs Remain Unchanged: Your entities that were created prior to this transition will retain their current "numeric" format IDs (e.g., "43012949") indefinitely.

• Aesthetic Shift in New IDs: For newly created entities post-transition, the IDs will have an alphanumeric structure (e.g., "X9_l7IdvRq26r7e2wn353Q"), deviating from the purely numeric style.

• Coexistence of ID Formats: Existing projects will exhibit a blend of numeric and alphanumeric IDs — previously created entities retaining numeric IDs and newly created ones adopting the new alphanumeric format. Projects initiated after the transition will solely feature alphanumeric IDs.

• API Compatibility: Our APIs have consistently enforced a "IDs are strings" policy. Consequently, if your integration with DatoCMS APIs is based on existing API practices, which involve working with string IDs, you are already aligned with the upcoming change.

• Impact on Integrations: If your integration relies on interpreting string IDs as numerics or vice versa, we urge you to evaluate whether your solution can smoothly transition to the new alphanumeric format.

We believe that this transition will mark a significant step forward in ensuring the security, flexibility, and longevity of your data within DatoCMS environments.

Should you have any questions or concerns regarding this transition, please don't hesitate to reach out to our support team.

We are happy to announce the latest update to our integration resources and packages for Next.js!

Our team has been hard at work to enhance your developer experience and provide seamless integration with the new Next.js App Router (introduced in Next 13, and marked as stable from v13.4).

What's new?

Integration Resources — We have revamped our integration documentation to provide you with comprehensive guidance and support for the new App Router. Whether you are new to Next.js or an experienced developer, you'll find everything you need to seamlessly integrate your applications with Next.js.

Our updated documentation covers key topics, best practices, and step-by-step instructions, making it easier than ever to get started.

Starter Projects — As part of this update, we have also upgraded our Blog starter to run on Next 13, and released a new Photography Website starter. Both serve as a starting point for your Next.js projects, with built-in compatibility for App Router.

The Blog starter in particular offers the Web Previews and SEO/Readability Analysis plugins already pre-installed and configured, as well as a fully functioning Draft Mode for editors, with real-time previews of draft content.

Updated react-datocms npm Package — The latest version of our popular React integration toolkit has been optimized to work seamlessly with Server Components, and introduces a new helper specifically designed for the new Metadata API.

By upgrading to the latest version, you can enjoy a smooth developer experience with Next 13+, while leveraging the usual powerful capabilities of DatoCMS in your projects.

Onwards!

We are committed to continuously improving our tools and resources to make your development process smoother, more efficient, and enjoyable. These updates are designed to provide you with maximum flexibility, allowing you to leverage the benefits of App Router seamlessly within your Next.js applications.

To explore the updated integration resources and get started with the new project starter template and react-datocms package, head over to our documentation website.