Workflow

  1. Apply the Custom Type changes from development to production (copy the JSON definition of your Custom Types in dev, and paste it into prod).
  2. Populate the new content using the updated Custom Types directly into the production repository (after you've updated the Custom Types). These updates can be grouped in a Release, this way you'll be able to preview them all at once in your front-end environments/applications you've configured in the Previews.
  3. Once you've pushed the code that renders the new fields or slices in production, you can publish the content (individually or as a content Release).

 

Impact of updating the Custom Types in production

Adding new fields

After adding a new field in a Custom Type, it will appear in the API response with default values the first time something is published in the repository.

To illustrate this, let's say we have a simple Custom Type made up of 2 fields: title and content. Before making any changes, here is the data we receive from the API for that document:

"data": {
    "title": "My article title",
    "content": "My article content"
}


After adding a new excerpt  field to the custom types, the API response will remain the same until we publish anything in the repository. After the first publication in the repository, if no content has been populated for that new field, the API will return this field with a default value:

"data": {
    "title": "My article title",
    "excerpt": null,
    "content": "My article content"
}

 

Removing or renaming the API ID of a field

You cannot rename the API ID of a field, it will be considered as deleting the old field and creating a new one and the content won't be ported. Read more here: What happens if I remove or rename the API ID of a field on a custom type.

Did this answer your question?