Get help on Discord

Clarification on configuring the calendar integration in Sanity.io.

14 replies
Last updated: Sep 16, 2021
Hi all, I am looking at integrating the calendar https://www.sanity.io/plugins/content-calendar and I am stuck at the configuration in 
config/content-calendar.json
, specifically

"types": [
    {
      "type": "post",
      "field": "publishedAt",
      "titleField": "title"
    }
  ],
does type mean something like ‘document’ and what is the purpose of ‘titleField’ as there was no mention of it in
https://www.sanity.io/blog/calendar-plugin
AI Update

In the config/content-calendar.json configuration file:

"type" refers to your document type (schema name), not the word "document" itself. So if you have a document schema called post, article, or event, that's what goes in the type field.

"titleField" specifies which field from your document should be displayed as the title/name of the event in the calendar view. This helps you identify documents at a glance when looking at the calendar.

For example, in your configuration:

{
  "type": "post",
  "field": "publishedAt",
  "titleField": "title"
}
  • "type": "post" - This targets documents with the schema type post
  • "field": "publishedAt" - This is the date/datetime field used for scheduling
  • "titleField": "title" - This tells the calendar to display the value from the title field as the event name

The titleField also supports nested properties using dot notation, like "title.en" if you have localized fields.

Important note: This plugin is now deprecated. The Sanity team recommends using sanity-plugin-scheduled-publishing instead, which is the modern, actively maintained solution for scheduling content in Sanity Studio.

Hi Gibson. 
types
will be an array of objects, with each object providing a 
type
property (which document to display on the calendar), a 
field
property (which field to use from the aforementioned document to get the date for the calendar), and a 
titleField
property (which field to use from the aforementioned document to display a title on the calendar).
To answer your follow-up question—yes, the 
type
property should match the 
name
property from your document schema.
Thanks, Geoff. So that means if my schema is this
export default {
title: ‘Careers’,
name: ‘careers’,
type: ‘document’,
fields: [
{
title: ‘Header’,
name: ‘header’,
type: ‘string’,
validation: (Rule) => Rule.required(),
}
]
};

So my configuration for the calendar content will be
“types”: [
{
“type”: “careers”,
“field”: “publishedAt”,
“titleField”: “header”
}
],
am i correct?
As long as 
careers
has a 
publishedAt
field, then yes, that looks correct. 👍
ok, so i need to explicitly put a publishedAt field for all documents which i want to link to the calendar?
Given 
"field": "publishedAt",
, yes you do. You could name it whatever you want, but then would want to update your calendar config file to match.
Given 
"field": "publishedAt",
, yes you do. You could name it whatever you want, but then would want to update your calendar config file to match.
ah, i see
i there no mention of explicitly needed to create a 
publishedAt
field as i thought each document has an implicit 
publishedAt
field which is linked to the 
Publish
button
great, that works for me. Thanks
user A
great, that works for me. Thanks
user A
That’s a fair assumption. Apologies it’s not clearer. I’ll see about getting those two documents updated to point this out explicitly.
For your own Sanity journey, any fields starting with an underscore are added by Sanity. Anything else is specified in a schema. That’s
sort of alluded to here but could be clearer and I certainly wouldn’t expect you to peruse all the docs before diving in. We’ll work on this. Thanks for pointing this out and please continue to reach out. 🙂
great, that works for me. Thanks
user A
thanks a lot, Geoff, your explanation cleared up a lot of things

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?