Starting October 10th, a couple of changes will be made to the CMA endpoints related to Workflows.
Workflows are a feature enabled in our Enterprise plans, so most of our users won't be affected by this change. All accounts actively using Workflows have already been notified via email about this change. If you did not receive an email, then you have nothing to worry about. 😉
Let's see how the workflow entity will change:
// Until October 10th:{"type": "workflow","id": "approval_by_editors","attributes": {"name": "Approval by editors","stages": [...]}}// From October 10th:{"type": "workflow","id": "123902133","attributes": {"name": "Approval by editors","api_key": "approval_by_editors","stages": [...]}}
As you can see:
The old ID is now present in the new payload as attributes.api_key;
The ID becomes a regular DatoCMS ID, immutable during environment forks.
Please note that it will still be possible to fetch, update and delete workflows by passing the API key in the URL, although it is suggested to use the ID.
It will be required to pass the new ID instead of the API key every time a workflow is referenced in another entity relationship (ie. when creating/updating a Model) and inside roles permission rules.
We have recently increased to everybody the maximum number of blocks you can have in a record. The limit have been increased by 50%, from 400 to 600 blocks per record.
This upgrade has been applied as the new minimum to everyone, old and new users.
If you need more blocks for a special use case, please reach out at support@datocms.com
The limit seems high enough, but if you start building complex nested structures that are also translated you can quickly reach the limit. Unfortunately it's not a pricing issue but it's more of a technical limit as we need to run validations on all the new blocks that have been added. To avoid timeouts and long waits on the user's side we have added this limit, but if it's a blocker for you be in touch and we can test higher limits together.
Closely following the release of the new CLI, we also released a new Contentful importer. You can install it as a CLI plugin, it provides faster import times and covers a number of new edge cases that the previous importer could not handle.
For all the information, take a look at the new documentation.
Until now, when forking an environment (or duplicating a project from the dashboard), resources under the newly created environment were assigned new IDs. This included models, fields, fieldsets, records, blocks, menu items, plugins, filters and media assets.
Starting from today, every resource will keep their original ID on the forked environment (or duplicated project). For instance, given a model "Blog Post" with ID "12345" in the primary environment, once the environment is forked, a new model "Blog Post" with the same ID "12345" will be present in the new sandbox environment.
We are so excited about this new feature, as it greatly enhances the developer experience. It makes the adoption of an environment-based workflow even easier, as the cloned environment is indistinguishable from the original one. Migrations are simpler to write, as you can safely rely on the IDs to pick resources, and the same applies to any third-party application that communicates with your DatoCMS project.
This change will also allow us to start working on another very requested feature by community: auto-generation of migration scripts by diffing two different environments!
⚠️ PS. Since now IDs are immutable cross-environment, take extra precaution at selecting the right environment when you're ie. deleting any resource via our Content Management API! The same ID is present on multiple environments, so your API call will work even if you're not targeting the environment you had in mind!
In the Presentation tab of Structured Text fields, it is now possible to enable only specific heading levels:
This will have the effect of hiding the relative slash commands on the editor (in this case, the Heading 1 option is not present):
For greater convenience, markdown shortcuts for heading levels that are not available will fall back to the nearest available level — that is, if Heading 1 is not available, pressing # will insert a Heading 2 — and tab and shift+tab keyboard shortcuts, which have the effect of decreasing/increasing the heading level, will skip the levels that are not available:
We are happy to announce that it is now possible to use all the transformation parameters made available by Imgix on SVG files as well!
It is important to note that as soon as a transformation parameter is added to the URL of an SVG file, Imgix will proceed to rasterize the SVG, and the transformations will be applied to the rasterized version of the image.
By default an SVG file with any transformation parameter will be converted in PNG format, but you can request a different output format with the fm parameter.
A small addition to our Plugin SDK: it is now possible to retrieve the number of blocks currently used inside a record via the ctx.blocksAnalysis property.
The information is exposed in every hook related to records editing, namely Field extensions, Sidebar panels, and Form outlets:
import React from 'react';import ReactDOM from 'react-dom';import { connect, RenderItemFormOutletCtx } from 'datocms-plugin-sdk';connect({itemFormOutlets(model, ctx) {return [{ id: 'myOutlet' }];},renderItemFormOutlet(outletId, ctx) {const {blocksAnalysis: {usage: {/** Total number of blocks present in form state */total,/** Total number of blocks present in non-localized fields */nonLocalized,/** Total number of blocks present in localized fields, per locale */perLocale,},/** Maximum number of blocks per item */maximumPerItem,},} = ctx;// render the outlet here},});
In the content navigation bar, it is now possible to associate menu items to specific shared filters, so that the user clicking on the item will see a predefined set of filters, table columns and ordering:
We have extended the capabilities of our record filters, which now behave like fully fledged views!
A filter can now store also a preference of ordering, and the table columns most suitable to consume that specific filtering:
We just introduced a new parameter that can be added to the filter parameter of site search to enable a fuzzy search. When the parameter fuzzy filter is present, our search engine will find strings that approximately match the query provided.
Here is an example of how to use the feature:
const searchResults = await client.searchResults.list({page: {offset: 200,limit: 20},filter: {fuzzy: 'true',query: 'florance',build_trigger_id: '44',locale: 'en'}});searchResults.forEach((searchResult) => {console.log(searchResult);});
In this example, strings like florence will be matched, even if the query is florance.
Please refer to the site search page in the Content Management API documentation for a complete example.