You can take a look at a real-world example of this hook in the upgraded Web Previews plugin, which now can offer your editors side-by-side previews of unpublished/draft content, directly within DatoCMS:
The second hook enables you to customize the presentation of your records according to your specific needs. This level of flexibility empowers you to create a unique and tailored user experience that aligns with your goals.
The buildItemPresentationInfo
hook can be used in numerous ways. For example, you can:
Combine multiple fields to present a record;
Generate a preview image on the fly;
Perform asynchronous API requests to third parties to compose the presentation.
Both locale:
and fallbackLocales:
arguments can be passed to multi-locale fields, but both arguments are completely ignored:
query {allBlogPosts {_allTitleLocales(locale: it_IT, fallbackLocales: [it, en]) {localevalue}}}
Similarly, the fallbackLocales:
argument can be passed down to meta fields, but it's ignored:
query {_allBlogPostsMeta(fallbackLocales: [it, en]) {count}}
Both the locale:
argument in multi-locale fields, and the fallbackLocales:
argument in meta fields are removed, as they make no sense.
The fallbackLocales:
argument in multi-locale fields is now taken into consideration when a value for a particular locale is missing:
query {allBlogPosts {noFallbacks: _allTitleLocales {localevalue}withFallbacks: _allTitleLocales(fallbackLocales: [en]) {localevalue}}_allBlogPostsMeta {count}}
{"allBlogPosts" {noFallbacks: [{ locale: "it", value: "" },{ locale: "es", value: "Título" },{ locale: "en", value: "Title" },],withFallbacks: [{ locale: "it", value: "Title" },{ locale: "es", value: "Título" },{ locale: "en", value: "Title" },],},"_allBlogPostsMeta": {"count": 3}}
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 recently released a tiny, tiny improvement that should help people frequently working with the media gallery: as of now, when filling in a media field that validates the type of file that can be uploaded, the media gallery is open with a filter already set.
So, the initial list of media displayed when the gallery appears is limited to the usable uploads. The filter can be removed to access all the contents of the media gallery.
Since today it's possible to assign a creator when an item is created via API. The creator can be anyone that belongs to the site or the organization. The call must be made using a token with permission to edit the creator.
API users can assign the creator by declaring the type and the ID of the desired creator in the relationship
field of the creation request:
POST https://site-api.datocms.com/items HTTP/1.1X-Api-Version: 3Authorization: Bearer YOUR-API-TOKENAccept: application/jsonContent-Type: application/vnd.api+json{"data": {"type": "item","attributes": { [...] }},"meta": { [...] },"relationships": {"item_type": {"data": {"type": "item_type","id": "44"}},"creator": {"data": {"type": "account","id": "312"}}}}}
Filter expression conditions have always been implicitly combined using a logical AND
. However, there are situations where explicitly incorporating an AND expression can greatly improve the filtering experience:
query {allArtists(filter: {AND: [{ name: { matches: { pattern: "Blank" } },{ name: { matches: { pattern: "Banshee" } }]}) {idnamegenre}}
In the example provided, the same filter type is required multiple times within the same expression. Without an explicit AND operator, this would not be achievable.
We're excited to announce that alongside the pre-existing OR operator, you can now seamlessly incorporate explicit AND operators into your GraphQL queries for optimal flexibility and customization.
To make integrating with your front-end easier, we decided to have the CDA returning a handy string containing the rgb()
functional notation of a color field, expressed with the current standard syntax.
As an example, the following query:
{leaf {color {cssRgb}}}
Returns a string containing three space-separated values, representing respectively values for red, green, and blue. Optionally, it may also include a slash / followed by a fourth value, representing alpha.
{"data": {"leaf": {"color": {"cssRgb": "rgb(213 185 185 / .43)"}}}}