Starting from May 30th, 2022 10:00 CEST:

The site resource object returned by the CMA will no longer expose the following properties:

• attributes.frontend_url: this was deprecated years ago in favor of multiple build triggers per project;

• relationships.menu_items: use the dedicated endpoint to retrieve the list of menu items;

• relationships.users: use the dedicated endpoint to retrieve the list of collaborators;

• relationships.sso_users: use the dedicated endpoint to retrieve the list of SSO users;

• relationships.roles: use the dedicated endpoint to retrieve the list of roles;

• relationships.build_triggers: use the dedicated endpoint to retrieve the list of build triggers.

Today we're switching to a better management of timezones in datetime values stored in your projects!

Current behaviour

DateTime fields in your records do not carry timezone information.

If you use the Content Management API to create/update a record, and you provide an ISO8601 datetime complete with timezone to a DateTime field, the timezone part is completely ignored by the system. Just the date + time information will be stored in the field value, and the project timezone will be automatically applied to it when the API outputs the value.

const record = await client.items.update('324342', {
  dateTimeField: '2000-01-01T09:30+10:00',
});

console.log(record.dateTimeField);

In this example, if the timezone setting in your project is Europe/Rome, the returned datetime won't be 2000-01-01T09:30+10:00, but 2000-01-01T09:30+01:00 .

Also, if you change the timezone setting in the future to be ie. Pacific Time, the same date will immediately become 2000-01-01T09:30-08:00, and every other date stored in your records' fields will change similarly. This basically has the effect of moving dates in time.

Improved behavior

DateTime fields in your records DO carry timezone information with them.

The only effect of the global timezone setting is to return via API every datetime value coherently converted in the same timezone.

Following the same example used above, if the timezone setting in your project is Europe/Rome, and you update a datetime field value passing 2000-01-01T09:30+11:00, the datetime returned by the API will be 1999-12-31T23:30+01:00 — that is, same point-in-time, but expressed in the project timezone.

If you change the timezone setting in the future to be ie. Pacific Time, the same date will immediately be presented via API in the new timezone (1999-12-31T14:30-08:00), but the point-in-time will be kept intact.

Who is affected by this change?

Every brand new DatoCMS project created starting from today will be under the improved behavior. If you want to switch your existing project to the new behavior, you can manually do so in the Environment Settings:

PS: Be aware that the change cannot be undone, so be sure to test the effects in a sandbox environment before applying the change to your primary environment!

Sometimes the invitation email to participate in a project can get lost. In these cases, you can now send a new invitation email from the Collaborators section:

A new modal is now displayed when adding a new locale on a record, to ask if you want to copy the content present in the main language:

A welcome addition to speed up the editing of records:

• Cmd/Ctrl + S saves the record

• Cmd/Ctrl + Shift + S publishes the record

If you have other shortcuts to suggest, we're all ears!

We're happy to announce that we've completely rewritten the datetime component to make entering dates more intuitive, especially for teams that are in different timezones.

The first thing you'll notice is the timezone information, which is now always visible next to the date itself:

For added convenience, each user will always see dates converted into their system timezone, regardless of the project timezone setting.

You can always change your default timezone preference in the localization settings:

Another welcome change (we hope) is time shortcuts — ie. just type 15<Tab> and the system will interpret it as 15:00:00. We also got rid of the time selector dropdown, as it was rather annoying to work with:

Especially in projects with a large number of locales, it's important to keep an eye on the number of blocks used within a specific record, to avoid exceeding the limits on your plan.

We made a small change to the interface to display a bar showing the current usage of blocks. The same information is also present in the sidebar:

One tiny addition that may save a few seconds every day: we added a button on slug fields to regenerate the value of a slug.

A video is worth a thousand words in this case:

Another small convenience added on the Modular Content fields. There is now an option to make a complete copy of an existing block. Depending on the content, it can save a lot of time and most importantly give you the confidence that you haven't forgotten to carry anything over.

If the block contains some nested blocks, they'll be duplicated as well:

We're happy to announce we've enabled the support for 2FA backup codes! From now on, when enabling two-step verification, you'll receive 12 backup codes. Each 6-digit code can be used once to access your DatoCMS account in case of emergency.

Two-step verification (also known as two factor authentication or 2FA) is a highly recommended security feature that adds an extra layer of protection to your account. Enabling two-step verification means that DatoCMS will require a six-digit security code (in addition to your password) when you sign in to your account or link a new computer, phone, or tablet.

If you've already have 2FA set up on your account, you'll need to disable it and then re-enable it to get your backup codes.