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.

We're happy to announce that low-quality image placeholders (LQIP) offered by the GraphQL Content Delivery API via the responsiveImage and blurUpThumb queries, now fully support images with alpha channels!

You can read the complete announcement in our blog post.

Our GraphQL service is implementing a new change starting from June 12, 2023. GraphQL requests with a complexity score above 10,000,000 will return an error message. We have worked hard to develop a new algorithm that calculates the complexity score more precisely. It will help us prevent abuses and ensure that our GraphQL service remains fast and efficient for all customers.

The complexity score is calculated based on the number of fields requested and other factors contributing to the computational resources needed to process the query. You can read more about how we generate this score and where to obtain it on the updated doc page.

The maximum complexity score in your plan might be higher than the default. However, we encourage all customers to review their queries and optimize them to reduce their complexity score where possible. You can see what's your plan limit on your dashboard page.

As you know, our GraphQL server returns the HTTP header X-Complexity with the score of the given query. Today we have added a new header named X-Max-Complexity that shows your current plan limit. This pair of headers will help you identify which queries will start to return an error starting from June 12, and thus need a change.

If you have any questions or concerns about this change, please don't hesitate to contact our support team. We appreciate your understanding and cooperation as we make this important change.

We're excited to announce that we're upgrading the management of CSS hex color notation in color fields for the Content Delivery API. Starting today, we'll be using the 8-digits hex color notation, or #RRGGBBAA, which includes the alpha channel.

Current behavior

Currently, color fields return a CSS hex string that follows the 6 digits hex color notation. Unfortunately, this notation doesn't include the alpha channel. So when you query a color field, the hex value returned may not accurately represent the color you're looking for. For example, if you query a transparent color field, you may actually get the hex string for the color white.

Here's an example of the current behavior:

{
  "color": {
    "hex": "#FFFFFF",
    "alpha": 0,
    "blue": 255,
    "green": 255,
    "red": 255
  }
}

Improved behavior

To address this issue, we're adopting the widely-used 8-digits hex color notation in the Content Delivery API. By using this notation, you'll get a more accurate representation of the color you're querying, including the alpha channel.

Here's an example of the improved behavior:

{
  "color": {
    "hex": "#FFFFFF00",
    "alpha": 0,
    "blue": 255,
    "green": 255,
    "red": 255
  }
}

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 hope this change will improve your experience when working with color fields in the Content Delivery API. As always, if you have any questions or concerns, please don't hesitate to reach out to our support team.

We're excited to announce our latest feature: Fast Fork. For users working with large environments, forking an environment can be a time-consuming process. Fast Fork offers a solution that can be up to 20 times faster than a regular fork. The only downside is that during the fork process, the source environment will be kept in read-only mode, which means that other users won't be able to make any changes to its content — this is similar to turning on Maintenance Mode.

Using Fast Fork on the DatoCMS interface is easy. Simply select the "Fast Fork" option when creating a fork. If a user is currently making changes to a record in the source environment, they will be warned and asked if they want to proceed anyway. This gives users the option to coordinate with other team members and avoid conflicts:

For users who prefer to use the CLI, the migrations:run and environments:fork commands support an additional flag for the fast fork option. However, unlike the interface, if a user is currently making changes to a record, the CLI will stop the operation. To proceed in any case, the user has to explicitely pass the --force option.

We hope that this new feature will help our users save time and increase efficiency when working with large environments. Check out our documentation page for all the details on Fast Fork and how to use it. Happy forking!

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.