On fields of type Single-line string, Multi-paragraph text, and Structured Text, we used to allow both null value and empty strings (""), but in both cases the API would return an empty string.

The exists filter, which selects values different from null, would then return empty strings instead of null values. This behavior is confusing and unpredictable, so we decided to deprecate the exists filter for these types of field.

We created a new filter, called isPresent, that selects values that are neither null nor empty strings. It behaves as the opposite of isBlank. The exists filter will continue to work, but is now deprecated, and will be removed in future versions of our API.

Today we are thrilled to announce the launch of Organizations: a powerful new feature that makes it easier — and more secure — to share ownership of projects with other team members!

Please read the complete announcement in our blog!

On Monday, 30th of January at 10AM (UTC+1), we are changing the default value of string fields from empty string ("") to null. We are doing this for consistency with other field types and because it was generating confusion over record filtering.

Please, check your code if this change impacts your projects in any way!

Write to our support team if you need any assistance.

We decided not to proceed with this and to find another solution.

We made some UI improvements in how locales are presented and managed in the tabular visualization of a collection, when you have a model with the option "All locales required?" disabled.

The locale switch dropdown now automatically filters out records that do not contain the selected locale — previously, it would only have the effect of showing content in the table in the selected locale, if it was available:

This change should already improve 99% of use cases, but if you need to make some more complex queries on your record list, you can use the new "Locales" advanced filter:

We want our APIs to be as clean as possible, but we also do not want to disrupt the work of our customers. With that in mind, we have decided to apply some changes to the API only for the websites created from January 1st, 2023 onwards. Therefore, websites created in the new year will have a slightly different API:

• createdAt and updatedAt fields will be available on the content management API as part of the meta object of the item and item_type entities;

• the fields createdAt and updatedAt won’t be available via GraphQL in the CDA: the existing _createdAt and _updatedAt will remain as they currently are (quick take-away: in our GraphQL API, meta fields always start with an underscore 😉);

• legacy fields with wrong spelling like appeareance and collection_appeareance , already marked as deprecated, won't be available anymore.

The changes will only impact new websites: nothing will change for existing ones or their duplicates. For any further info, please get in touch with our customer support.

On plugins, it is now possible to intercept when the user wants to perform a specific action on one (or multiple) records, via a new set of event hooks:

• onBeforeItemUpsert: when the user wants to save a record (both creation and update);

• onBeforeItemsDestroy: when the user wants to delete one (or more) records;

• onBeforeItemsPublish: when the user wants to publish one (or more) records;

• onBeforeItemsUnpublish: when the user wants to unpublish one (or more) records;

Please read our updated documentation to learn how to use them!

It is now possible to automatically provision DatoCMS users using your centralized Google Workspace. Group memberships are supported too.

Read all the details on how to configure the integration. Single Sign-On is an enterprise feature: if you're interested, please contact our Sales team to activate a free 15 days trial.

The new version of vue-datocms — v4.0.0 — makes available to Vue users an important improvement that we released some days ago for the people working with React.

Here is the news: with this new version, you can reduce responsiveImage() GraphQL queries down to:

responsiveImage(imgixParams: { auto: format }) {
  src width height alt base64
}

• You can avoid requesting srcSet in the responsiveImage GraphQL query, as if it's missing, the Vue <Image /> component knows how to build it from src.

• You can avoid requesting webpSrcSet as well, because the { auto: format } Imgix transformation parameter offers even more performant optimizations (AVIF), without increasing the GraphQL response size.

• You can avoid requesting sizes, and use the sizes prop on the Image component itself.

These changes can sensibly reduce the overall GraphQL response size, particularly when dealing with many images at once.

New props for Image component:

• priority: When true, the image will be considered high priority. Lazy loading is automatically disabled, and fetchpriority="high" is added to the image.

  You should use the priority property on any image detected as the Largest Contentful Paint (LCP) element. It may be appropriate to have multiple priority images, as different images may be the LCP element for different viewport sizes. Should only be used when the image is visible above the fold.

• sizes: If you're using this prop, you can avoid requesting sizes in the responsiveImage query.

• src-set-candidates: If you're not requesting srcSet in the responsiveImage query, src-set-candidates will be used to generate the different srcset candidate strings at various widths. Default candidates are: [0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4].

Despite being somewhat scary, regular expressions are a very powerful tool. DatoCMS supports regex for filtering patterns in GraphQL queries. We just improved how we report syntax errors in regex to ease their usage and provide more precise feedback.

Now, providing a query like this:

{
  allBlogPosts(filter: {name: {matches: {pattern: "^+123"}}}) {
    id
  }
}

will get you the following error:

1
{
2
  "data": null,
3
  "errors": [
4
    {
5
      "message": "Invalid regular expression: quantifier operand invalid (provided regular expression: \"^+123\")",
6
      "locations": [
7
        {
8
          "line": 2,
9
          "column": 3
10
        }
11
      ],
12
      "path": [
13
        "allBlogPosts"
14
      ]
15
    }
16
  ]
17
}

Basically, with react-datocms v4.0.0 your responsiveImage() GraphQL queries can be reduced down to:

responsiveImage(imgixParams: { auto: format }) {
  src width height alt base64
}

• You can avoid requesting srcSet in the responsiveImage GraphQL query, as if it's missing, the React <Image /> component knows how to build it from src.

• You can avoid requesting webpSrcSet as well, because the { auto: format } Imgix transformation parameter offers even more performant optimizations (AVIF), without increasing the GraphQL response size.

• You can avoid requesting sizes, and just use the sizes prop on the Image component itself.

Overall, these changes can reduce the overall GraphQL response size significantly, especially when dealing with many images at once.

New props for Image component:

• priority: When true, the image will be considered high priority. Lazy loading is automatically disabled, and fetchpriority="high" is added to the image.

  You should use the priority property on any image detected as the Largest Contentful Paint (LCP) element. It may be appropriate to have multiple priority images, as different images may be the LCP element for different viewport sizes. Should only be used when the image is visible above the fold.

• sizes: If you're using this prop, you can avoid requesting sizes in the responsiveImage query.

• srcSetCandidates: If you're not requesting srcSet in the responsiveImage query, srcSetCandidates will be used to generate the different srcset candidate strings at various widths. Default candidates are: [0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4].