To give a more predictable and consistent timing in our GraphQL responses we had to introduce a limit in the query complexity.

To each field required we attach a weight of 1. To fields that need additional queries under the hood, like links, rich_text fields and uploads we attach a weigth of 10.

We have currently limited the complexity to 550, which should be enough for most cases, but if you have any specific concern support@datocms.com is happy to help.

Today we just released some new requested enhacements to our deployment adapters!

The most important one is related to Netlify: you can now specify the Git branch you want to build. This means you no longer have to create two different Netlify sites, one for production and one for staging.

Remember that you can add a netlify.toml file in your repository to customize the headers on a per-branch basis:

# Staging context: all deploys from the staging
# branch will inherit these environment variables:

[context.staging.environment]
  SHOW_DRAFT_CONTENT = "true"

With CircleCI, you can now add custom environment variables to use to be available during the build:

And if you're using our custom webhook deployment method, you are now free to specify the exact headers and JSON payload to be sent:

We (finally) made a much requested change to DatoCMS: you can now select existing records in the Embedded forms mode of the Link(s) fields:

While we were at it, we thought it could be cool to add the same From library button also on the compact visualization mode, so you don't always have to rely on auto-completion when you have many items:

Enjoy!

We've just made some Quality of Life improvements to your Media Area on DatoCMS!

Small, Medium or Large? Assets can now be previewed in three different sizes, for starters:

Fancy an early spring cleaning? Now you can delete multiple assets in one go (fear not, my friend, all assets related to a record can't be deleted this way):

If you are looking for a more drastic solution, you can select the "Not Used" filter in the Media Area and delete them all with the click of a button:

If you have questions, feedback, or recommendations for the next updates, drop us a line!

Following a great discussion over our Slack channel (thanks Daniel!), we've just improved our SEO field. This is how it looks now:

As you can see, you can now instantly preview how your record will show up on Google, Twitter and Facebook.

The preview is generated based on the values present in the record's SEO meta tags field together with the global SEO settings of your project. Even if the SEO field is not configured, we try to guess reasonable values by inspecting the value of the other record's field.

On your frontend, you can the pull the correct meta tags from our GraphQL CDA with the _seoMetaTags helper method. A similar method exists in all our SSG plugins.

A small but handy change just landed: when you add a slug field to a model, if the model already contained some records, they will get a proper slug generated!

We just introduced a new meta field to records which represents the first time a record gets published: perfect to use in blogs as the publication date of an article, for example.

You can fetch, filter and order records using _firstPublishedAt on our GraphQL Content Delivery API:

{
  allBlogPosts(orderBy: [_firstPublishedAt_DESC]) {
    title
    slug
    author { name }
    _firstPublishedAt
  }
}

The meta field is also present in our CMA, and in the administrative interface:

We just made possible to specify which API endpoints an API token can access:

This will prevent from using your ie. production API token to read temporary/draft content using the GraphQL preview endpoint.

On February 4, at 11:00 CEST we'll publish a small change to the GraphQL types of our Content Delivery API.

If you want to get the value of a field for every locale of the project, you can use the following query:

query {
  allBlogPosts {
    _allTitleLocales {
      locale
      value
    }
  }
}

Right now the type for the _allTitleLocales field is [PageModelSlugMultiLocaleField]. After the change, the name of the type will simply be [SlugMultiLocaleField]. That is, the prefix {MODEL_NAME}Model will be dropped.

This change will drastically reduce the overall number of GraphQL types on multi-language project, reducing both our response times (by up to ~25%) and time to process the schema on your side.

The large majority of our users won't need to do anything, but if your codebase do relies on GraphQL type names, please make sure to do the necessary adjustments before February 4 or contact us if you need more help/information.

We've just made possible to see the log of a Netlify build related to a DatoCMS publication from under the Activity Log section of your administrative area:

Quite handy to quickly investigate why some build failed without having to leave the DatoCMS interface!