Since today, June 12th 2023, we are enforcing the GraphQL complexity limit we updated some months ago.

If one of your projects executed a query with a complexity higher than your plan's limit, you should have received an email in the past days.

If you have any questions or concerns about this change, please don't hesitate to contact our support team.

We are happy to inform you about a new feature that improves the browsing experience for models with optional locales.

Previously, when working with a model that allowed for optional locales, users were unable to browse all records simultaneously, as the interface required selecting a specific locale, limiting the ability to view content across all locales.

To address this limitation, we have now introduced the "All locales" filter option in the Locale switcher. This new feature empowers users to effortlessly browse records containing any locale, providing a comprehensive view of their content.

To ensure a seamless transition and avoid any confusion, we have maintained the default visualization settings. The interface will continue to display the primary locale of the project by default. This means that users who prefer the previous behavior can continue working without any disruptions.

With the addition of the "All locales" filter option, editors can now easily access and manage their records across multiple locales within a single interface, streamlining workflows and providing a more efficient content management experience.

We're pleased to announce that we have extracted the feature that allows you to generate an Entity-Relationship Diagram (ERD) of your project's schema into a separate plugin called Schema ERD.

By separating this feature into a plugin, we can now offer advanced capabilities and expand the range of export options available to you.

Enhanced Features

• Export Options: The new plugin offers a wider variety of export options. In addition to the existing ability to produce ERD diagrams as PDF files, you can now also export them in GraphViz DOT language and SVG format. This provides greater flexibility in integrating the ERD diagrams into your workflow and sharing them with others.

• Clearer and easy-to-read diagrams: The plugin improves the clarity and readability of your ERD diagrams. It better exposes the connections between fields and models, enabling you to understand the relationships in your schema more easily. This enhancement simplifies data analysis and fosters a deeper understanding of your project's data structure.

New Functionality

• Interactive interface: With the new plugin, you can now explore your ERD diagrams directly within the interface. The plugin provides a user-friendly and interactive experience, allowing you to browse, pan, and zoom the diagram effortlessly. This feature simplifies the analysis and navigation of complex schemas, enabling you to gain deeper insights into your project's data structure.

We are confident that the introduction of the Schema ERD plugin will enhance your experience and provide you with powerful tools to visualize and work with your project's schema!

We've super excited to announce we've added a couple of new very useful hooks in our Plugin SDK! 🥳

Custom sidebars

The first one lets you add custom sidebars next to your records form:

You can take a look at a real-world example of this hook in the upgraded Web Previews plugin, which now can offer your editors side-by-side previews of unpublished/draft content, directly within DatoCMS:

Custom record presentation

The second hook enables you to customize the presentation of your records according to your specific needs. This level of flexibility empowers you to create a unique and tailored user experience that aligns with your goals.

The buildItemPresentationInfo hook can be used in numerous ways. For example, you can:

• Combine multiple fields to present a record;

• Generate a preview image on the fly;

• Perform asynchronous API requests to third parties to compose the presentation.

Current behavior

Both locale: and fallbackLocales: arguments can be passed to multi-locale fields, but both arguments are completely ignored:

query {
  allBlogPosts {
    _allTitleLocales(locale: it_IT, fallbackLocales: [it, en]) {
      locale
      value
    }
  }
}

Similarly, the fallbackLocales: argument can be passed down to meta fields, but it's ignored:

query {
  _allBlogPostsMeta(fallbackLocales: [it, en]) {
    count
  }
}

Improved behavior

Both the locale: argument in multi-locale fields, and the fallbackLocales: argument in meta fields are removed, as they make no sense.

The fallbackLocales: argument in multi-locale fields is now taken into consideration when a value for a particular locale is missing:

1
query {
2
  allBlogPosts {
3
    noFallbacks: _allTitleLocales {
4
      locale
5
      value
6
    }
7
    withFallbacks: _allTitleLocales(fallbackLocales: [en]) {
8
      locale
9
      value
10
    }
11
  }
12
  _allBlogPostsMeta {
13
    count
14
  }
15
}

1
{
2
  "allBlogPosts" {
3
    noFallbacks: [
4
      { locale: "it", value: "" },
5
      { locale: "es", value: "Título" },
6
      { locale: "en", value: "Title" },
7
    ],
8
    withFallbacks: [
9
      { locale: "it", value: "Title" },
10
      { locale: "es", value: "Título" },
11
      { locale: "en", value: "Title" },
12
    ],
13
  },
14
  "_allBlogPostsMeta": {
15
    "count": 3
16
  }
17
}

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 do so 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.

We recently released a tiny, tiny improvement that should help people frequently working with the media gallery: as of now, when filling in a media field that validates the type of file that can be uploaded, the media gallery is open with a filter already set.

So, the initial list of media displayed when the gallery appears is limited to the usable uploads. The filter can be removed to access all the contents of the media gallery.

Since today it's possible to assign a creator when an item is created via API. The creator can be anyone that belongs to the site or the organization. The call must be made using a token with permission to edit the creator.

API users can assign the creator by declaring the type and the ID of the desired creator in the relationship field of the creation request:

1
POST https://site-api.datocms.com/items HTTP/1.1
2

3
X-Api-Version: 3
4
Authorization: Bearer YOUR-API-TOKEN
5
Accept: application/json
6
Content-Type: application/vnd.api+json
7

8
{
9
  "data": {
10
    "type": "item",
11
    "attributes": { [...] }
12
    },
13
    "meta": { [...] },
14
    "relationships": {
15
      "item_type": {
16
        "data": {
17
          "type": "item_type",
18
          "id": "44"
19
        }
20
      },
21
      "creator": {
22
        "data": {
23
          "type": "account",
24
          "id": "312"
25
        }
26
      }
27
    }
28
  }
29
}

Filter expression conditions have always been implicitly combined using a logical AND. However, there are situations where explicitly incorporating an AND expression can greatly improve the filtering experience:

1
query {
2
  allArtists(
3
    filter: {
4
      AND: [
5
        { name: { matches: { pattern: "Blank" } },
6
        { name: { matches: { pattern: "Banshee" } }
7
      ]
8
    }
9
  ) {
10
    id
11
    name
12
    genre
13
  }
14
}

In the example provided, the same filter type is required multiple times within the same expression. Without an explicit AND operator, this would not be achievable.

We're excited to announce that alongside the pre-existing OR operator, you can now seamlessly incorporate explicit AND operators into your GraphQL queries for optimal flexibility and customization.

To make integrating with your front-end easier, we decided to have the CDA returning a handy string containing the rgb() functional notation of a color field, expressed with the current standard syntax.

As an example, the following query:

{
  leaf {
    color {
      cssRgb
    }
  }
}

Returns a string containing three space-separated values, representing respectively values for red, green, and blue. Optionally, it may also include a slash / followed by a fourth value, representing alpha.

{
  "data": {
    "leaf": {
      "color": {
        "cssRgb": "rgb(213 185 185 / .43)"
      }
    }
  }
}

We recently introduced the possibility of validating and sanitising HTML content in multiple-paragraph text fields.

The feature is made of 2 parts:

• By enabling the validation flag "Prevent the use of dangerous HTML attributes", the editors will be prevented from saving a record if potentially dangerous HTML is present in the field;

• When the "Remove potentially dangerous attributes" flag is enabled, sanitization will be applied before the validation: field content is potentially subject to changes during the validation phase.

Most of our customers that want to use the feature will probably want to enable both flags. Validation without sanitization is meant for customers who want to apply specific sanitization strategies by developing a custom plugin.

To fix and check the HTML, we used the beautiful sanitize library made by Ryan Grove. Specifically, we went for the relaxed configuration, that allows safe markup, including images and tables, as well as safe CSS. Links are limited to FTP, HTTP, HTTPS, and mailto protocols, while images are limited to HTTP and HTTPS. rel="nofollow" is not added to links.

The feature also affects our Content Management API.