Creating Custom Previews

The NetlifyCMS exposes a window.CMS global object that you can use to register custom widgets, previews and editor plugins. The available customization methods are:

registerPreviewStyle: Register a custom stylesheet to use on the preview pane.
registerPreviewTemplate: Registers a template for a collection.

React Components inline interaction

NetlifyCMS is a collection of React components and exposes two constructs globally to allow you to create components inline: ‘createClass’ and ‘h’ (alias for React.createElement).
registerPreviewStyle

Register a custom stylesheet to use on the preview pane.

CMS.registerPreviewStyle(file);

Params:

file: css file path

Example:

// index.html
<script src=”https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js”></script>
<script>
CMS.registerPreviewStyle(“/example.css”);
</script>

/* example.css */

html,
body {
color: #444;
font-size: 14px;
font-family: ‘Helvetica Neue’, Helvetica, Arial, sans-serif;
}

body {
padding: 20px;
}

registerPreviewTemplate

Registers a template for a folder collection or an individual file in a file collection.

CMS.registerPreviewTemplate(name, react_component);

Params:

name: The name of the collection (or file for file collections) which this preview component will be used for.
Folder collections: Use the name of the collection
File collections: Use the name of the file

react_component: A React component that renders the collection data. Six props will be passed to your component during render:

entry: Immutable collection containing the entry data.

widgetFor: Returns the appropriate widget preview component for a given field.

widgetsFor: Returns an array of objects with widgets and associated field data. For use with list and object type entries.

getAsset: Returns the correct filePath or in-memory preview for uploaded images. Example:

<script src=”https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js”></script>
<script>
var PostPreview = createClass({
render: function() {
var entry = this.props.entry;
var image = entry.getIn([‘data’, ‘image’]);
var bg = this.props.getAsset(image);
return h(‘div’, {},
h(‘h1’, {}, entry.getIn([‘data’, ‘title’])),
h(‘img’, {src: bg.toString()}),
h(‘div’, {“className”: “text”}, this.props.widgetFor(‘body’))
);
}
});

CMS.registerPreviewTemplate(“posts”, PostPreview);
</script>

document: The preview pane iframe’s document instance.

window: The preview pane iframe’s window instance.
Lists and Objects

The API for accessing the individual fields of list- and object-type entries is similar to the API for accessing fields in standard entries, but there are a few key differences. Access to these nested fields is facilitated through the widgetsFor function, which is passed to the preview template component during render. Note: as is often the case with the NetlifyCMS API, arrays and objects are created with Immutable.js. If some of the methods that we use are unfamiliar, such as getIn, check out their docs to get a better understanding. List Example:

<script>
var AuthorsPreview = createClass({
// For list fields, the widgetFor function returns an array of objects
// that you can map over in your template. If our field is a list of
// authors containing two entries, with fields `name` and `description`,
// the return value of `widgetsFor` would look like this:
//
// [{
//   data: { name: ‘Mathias’, description: ‘Co-Founder’},
//   widgets: { name: (<WidgetComponent>), description: (WidgetComponent>)}
// },
// {
//   data: { name: ‘Chris’, description: ‘Co-Founder’},
//   widgets: { name: (<WidgetComponent>), description: (WidgetComponent>)}
// }]
//
// Templating would look something like this:

render: function() {
return h(‘div’, {},

// This is a static header that would only be rendered once for the entire list
h(‘h1’, {}, ‘Authors’),

// Here we provide a simple mapping function that will be applied to each
// object in the array of authors
this.props.widgetsFor(‘authors’).map(function(author, index) {
return h(‘div’, {key: index},
h(‘hr’, {}),
h(‘strong’, {}, author.getIn([‘data’, ‘name’])),
author.getIn([‘widgets’, ‘description’])
);
})
);
}
});
CMS.registerPreviewTemplate(“authors”, AuthorsPreview);
</script>

Object Example:

<script>
var GeneralPreview = createClass({
// Object fields are simpler than lists – instead of `widgetsFor` returning
// an array of objects, it returns a single object. Accessing the shape of
// that object is the same as the shape of objects returned for list fields:
//
// {
//   data: { front_limit: 0, author: ‘Chris’ },
//   widgets: { front_limit: (<WidgetComponent>), author: (WidgetComponent>)}
// }
render: function() {
var entry = this.props.entry;
var title = entry.getIn([‘data’, ‘site_title’]);
var posts = entry.getIn([‘data’, ‘posts’]);

return h(‘div’, {},
h(‘h1’, {}, title),
h(‘dl’, {},
h(‘dt’, {}, ‘Posts on Frontpage’),
h(‘dd’, {}, this.props.widgetsFor(‘posts’).getIn([‘widgets’, ‘front_limit’]) || 0),

h(‘dt’, {}, ‘Default Author’),
h(‘dd’, {}, this.props.widgetsFor(‘posts’).getIn([‘data’, ‘author’]) || ‘None’),
)
);
}
});

CMS.registerPreviewTemplate(“general”, GeneralPreview);
</script>

Accessing Metadata

Preview Components also receive an additional prop: fieldsMetaData. It contains aditional information (besides the plain textual value of each field) that can be useful for preview purposes. For example, the Relation widget passes the whole selected relation data in fieldsMetaData.

export default class ArticlePreview extends React.Component {
render() {
const {entry, fieldsMetaData} = this.props;
const author = fieldsMetaData.getIn([‘authors’, data.author]);

return <article><h2>{ entry.getIn([‘data’, ‘title’]) }</h2>
{author &&<AuthorBio author={author.toJS()}/>}
</article>
}
}

Examples

Do you have a great, open source example? Submit a pull request to this page!

Example  Tools  Type  Source  More info Gatsby & Netlify CMS Meetup Group Template  Gatsby  demo  robertcoopercode/gatsby-netlify-cms  blog post This Developing Journey  middleman  blog  bdougie/blog  blog post Jamstack Recipes  Hugo, Azure  demo  hlaueriksson/jamstack-cms  blog post Bael  Vue, Nuxt  blog  jake-101/bael-template  blog post Forest Garden Wales  Hugo  blog  forestgardenwales/forestgarden.wales  blog post Jekyll Demo  Jekyll, Gulp  demo  NickStees/jekyll-cms  read me Jekyll feat Alembic Theme Demo  Jekyll  demo  DavidDarnes/alembic-netlifycms-kit  read me Eleventy Starter Project  Eleventy  demo  danurbanowicz/eleventy-netlify-boilerplate  read me YellowCake – Complete website with blog  Gatsby, Netlify-CMS, Uploadcare  demo  thriveweb/yellowcake  blog post Vue.js – Nuxt.js Starter Project  Vue, Nuxt  demo  renestalder/nuxt-netlify-cms-starter-template  read me Hexo Demo  Hexo  demo  DemoMacro/Hexo-NetlifyCMS  read me Gitbook Demo  Gitbook  demo  DemoMacro/Gitbook-NetlifyCMS  read me VuePress Demo  VuePress  demo  DemoMacro/VuePress-NetlifyCMS  read me Jigsaw Blog Starter Template Demo  Jigsaw  demo  erickpatrick/jigsaw-blog-netlify-netlifycms-template  blog post Nuxt & NetlifyCMS Boilerplate  Vue, Nuxt  demo  tylermercer/nuxt-netlifycms-boilerplate  read me Next.js demo  Next.js  blog  masives/netlifycms-nextjs  read me Delog – Jamstack Blog with Netlify CMS  Gatsby, Netlify-CMS  demo  W3Layouts/gatsby-starter-delog  blog post Netlify CMS template for Gridsome  Gridsome, Vue  demo  suits-at/netlifycms-gridsome  read me Next.js blogging template for Netlify  Next.js, Netlify  blog  wutali/nextjs-netlify-blog-template  read me Netlify CMS and OAuth server on AWS  Netlify, Pulumi, AWS  blog  pulumi/examples/aws-ts-netlify-cms-and-oauth  blog post Eleventy Starter Boilerplate  Eleventy, Netlify  demo  ixartz/Eleventy-Starter-Boilerplate  read me Nuxt, Tailwind & NetlifyCMS Boilerplate  Vue, Nuxt  demo  Knogobert/ntn-boilerplate  read me Gatsby & Netlify CMS Personal Portfolio  Gatsby  portfolio  EarlGeorge/React-Gatsby  read me Gatsby, Tailwind CSS & NetlifyCMS Starter  Gatsby v3, Netlify-CMS, Tailwind CSS  demo  jimmybutton/gatsby-netlifycms-tailwind-starter  read me Metalsmith NetlifyCMS Starter  Metalsmith and Netlify-CMS  demo  metalsmith-netlify-starter  read me

Update the CMS Version

The update procedure for your CMS depends upon the method you used to install Netlify CMS.
Package Manager

If you are using a package manager like Yarn or NPM, use their standard procedure to update. This is how both the Hugo and Gatsby starters are set up.

CDN

If you are using the CMS through a CDN like Unpkg, then that depends on the version tag you are using. You can find the version tag in the /admin/index.html file of your site.

(Recommended) If you use ^2.0.0, the CMS does all updates except major versions automatically.
It upgrades to 2.0.1, 2.1.0, 2.1.2.
It does not upgrade to 3.0.0 or higher.
It does not upgrade to beta versions.

If you use ~2.0.0, the CMS will do only patch updates automatically.
It upgrades 2.0.1, 2.0.2.
It does not upgrade to 2.1.0 or higher.
It does not upgrade beta versions.

Uploadcare

Uploadcare is a sleek service that allows you to upload files without worrying about maintaining a growing collection — more of an asset store than a library. Just upload when you need to, and the files are hosted on their CDN. They provide image processing controls from simple cropping and rotation to filters and face detection, and a lot more. You can check out Uploadcare’s full feature set on their website.

The Uploadcare media library integration for Netlify CMS allows you to use Uploadcare as your media handler within the CMS itself. It’s available by default as of our 2.1.0 release, and works in tandem with the existing file and image widgets, so using it only requires creating an Uploadcare account and updating your Netlify CMS configuration.

Please make sure that Netlify CMS is updated to 2.1.0 or greater before proceeding.
Creating an Uploadcare Account

You can sign up for a free Uploadcare account to get started. Once you’ve signed up, go to your dashboard, select a project, and then select “API keys” from the menu on the left. The public key on the API keys page will be needed in your Netlify CMS configuration. For more info on getting your API key, visit their walkthrough.
Updating Netlify CMS Configuration

The next and final step is updating your Netlify CMS configuration file:

Add a media_library property at the same level as media_folder, with an object as it’s value.
In the media_library object, add the name of the media player under name.
Add a config object under name with a publicKey property with your Uploadcare public key as it’s value.

Your config.yml should now include something like this (except with a real API key):

media_library:
name: uploadcare
config:
publicKey: YOUR_UPLOADCARE_PUBLIC_KEY

Once you’ve finished updating your Netlify CMS configuration, the Uploadcare widget will appear when using the image or file widgets.

Note: The Netlify CMS media library extensions for Uploadcare are not included in netlify-cms-app. If you’re using netlify-cms-app, you’ll need to register the media libraries yourself.
Configuring the Uploadcare Widget

The Uploadcare widget can be configured with settings that are outlined in their docs. The widget itself accepts configuration through global variables and data properties on HTML elements, but with Netlify CMS you can pass configuration options directly through your config.yml.

Note: all default values described in Uploadcare’s documentation also apply in the Netlify CMS integration, except for previewStep, which is set to true. This was done because the preview step provides helpful information like upload status, and provides access to image editing controls. This option can be disabled through the configuration options below.
Global configuration

Global configuration, which is meant to affect the Uploadcare widget at all times, can be provided as seen above, under the primary media_library property. Settings applied here will affect every instance of the Uploadcare widget.
Field configuration

Configuration can also be provided for individual fields that use the media library. The structure is very similar to the global configuration, except the settings are added to an individual field. For example:


fields:
name: cover
label: Cover Image
widget: image
media_library:
config:
multiple: true
previewStep: false

Integration settings

There are several settings that control the behavior of integration with the widget.

autoFilename (boolean) – specify whether to add a filename to the end of the url. Example: http://ucarecdn.com/:uuid/filename.png
defaultOperations (string) – specify a string added at the end of the url. This could be useful to apply a set of CDN operations to each image, for example resizing or compression. All the possible operations are listed here.

media_library:
name: uploadcare
config:
publicKey: YOUR_UPLOADCARE_PUBLIC_KEY
settings:
autoFilename: true
defaultOperations: ‘/resize/800×600/’

Quick Start

There are many ways to add Netlify CMS to your static site. This guide will take you through one of the quickest methods, which takes advantage of Netlify’s hosting and authentication provider services.
Storage and Authentication

Netlify CMS relies on the GitHub API for managing files, so you’ll need to have your site stored in a GitHub repo. (If you’re partial to another Git hosting service, you can file a feature request, or help us add it.) To connect to the repo and make changes, the app needs to authenticate with the GitHub API. You can roll your own service for doing this, but we’re going to use Netlify in this example.
Hosting with Netlify

In order to use Netlify’s authentication provider service, you’ll need to connect your site repo with Netlify. Netlify has published a general Step-by-Step Guide for this, along with detailed guides for many popular static site generators, including Jekyll, Hugo, Hexo, Middleman, Gatsby and more.
Authenticating with GitHub

In order to connect Netlify CMS with your GitHub repo, you’ll first need to register it as an authorized application with your GitHub account:

Go to your account Settings page on GitHub, and click Oauth Applications under Developer Settings (or use this shortcut).
Click Register a new application.
For the Authorization callback URL, enter https://api.netlify.com/auth/done. The other fields can contain anything you want.

GitHub Oauth Application setup example

When you complete the registration, you’ll be given a Client ID and a Client Secret for the app. You’ll need to add these to your Netlify project:

Go to your Netlify dashboard and click on your project.
Click the Access tab.
Under Authentication Providers, click Install Provider.
Select GitHub and enter the Client ID and Client Secret, then save.

App File Structure

All Netlify CMS files are contained in a static admin folder, stored at the root of the generated site. Where you store this in the source files depends on your static site generator. Here’s the the static file location for a few of the most popular static site generators:
These generators …     store static files in
Jekyll, GitBook     / (project root)
Hugo, Gatsby*     /static
Hexo, Middleman     /source
Spike     /views

Notes: – Gatsby treats the static folder more strictly and will not render the admin page as the other generators. You will have to make a page component containing the necessary scripts of the Netlify CMS app in the admin page. However, the config.yml is to be placed in the static folder in the same way.

If your generator isn’t listed here, you can check its documentation, or as a shortcut, look in your project for a CSS or images folder. They’re usually processed as static files, so it’s likely you can store your admin folder next to those. (When you’ve found the location, feel free to add it to these docs by filing a pull request!).

Inside the admin folder, you’ll create two files:

admin
├ index.html
└ config.yml

The first file, admin/index.html, is the entry point for the Netlify CMS admin interface. This means that users can navigate to yoursite.com/admin to access it. On the code side, it’s a basic HTML starter page that loads the necessary CSS and JavaScript files. In this example, we pull those files from a public CDN:

<!doctype html>
<html>
<head>
<meta charset=”utf-8″ />
<meta name=”viewport” content=”width=device-width, initial-scale=1.0″ />
<title>Content Manager</title>

<link rel=”stylesheet” href=”https://unpkg.com/netlify-cms@~0.4/dist/cms.css” />

</head>
<body>
<script src=”https://unpkg.com/netlify-cms@~0.4/dist/cms.js”></script>
</body>
</html>

The second file, admin/config.yml, is the heart of your Netlify CMS installation, and a bit more complex. The next section covers the details.
Configuration

Configuration will be different for every site, so we’ll break it down into parts. All code snippets in this section will be added to your admin/config.yml file.
Backend

Because we’re using GitHub and Netlify for our hosting and authentication, backend configuration is fairly strightforward. You can start your config.yml file with these lines:

backend:
name: github
repo: owner-name/repo-name # Path to your Github repository
branch: master # Branch to update

This names GitHub as the authentication provider, points to the repo location on github.com, and declares the branch where you want to merge changes. If you leave out the branch declaration, it will default to master.
Editorial Workflow

By default, saving a post in the CMS interface will push a commit directly to the branch specified in backend. However, you also have the option to enable the Editorial Workflow, which adds an interface for drafting, reviewing, and approving posts. To do this, simply add the following line to your config.yml:

publish_mode: editorial_workflow

Media and Public Folders

Netlify CMS allows users to upload images directly within the editor. For this to work, the CMS needs to know where to save them. If you already have an images folder in your project, you could use its path, possibly creating an uploads sub-folder, for example:

media_folder: “images/uploads” # Media files will be stored in the repo under images/uploads

If you’re creating a new folder for uploaded media, you’ll need to know where your static site generator expects static files. You can refer to the paths outlined above in App File Structure, and put your media folder in the same location where you put the admin folder.

Note that themedia_folder file path is relative to the project root, so the example above would work for Jekyll, GitBook or any other generator that stores static files at the project root. It would not, however, work for Hugo, Hexo, Middleman or others that use a different path. Here’s an example that could work for a Hugo site:

media_folder: “static/images/uploads” # Media files will be stored in the repo under static/images/uploads
public_folder: “/images/uploads” # The src attribute for uploaded media will begin with /images/uploads

This configuration adds a new setting, public_folder. While media_folder specifies where uploaded files will be saved in the repo, public_folder indicates where they can be found in the generated site. This path is used in image src attributes and is relative to the file where it’s called. For this reason, we usually start the path at the site root, using the opening /.

If public_folder is not set, Netlify CMS will default to the same value as media_folder, adding an opening / if one is not included.

Collections

Collections define the structure for the different content types on your static site. Since every site is different, the collections settings will be very different from one site to the next.

Let’s say your site has a blog, with the posts stored in _posts/blog, and files saved in a date-title format, like 1999-12-31-lets-party.md. Each post begins with settings in yaml-formatted front matter, like so:


layout: blog
title: “Let’s Party”
date: 1999-12-31 11:59:59 -0800
thumbnail: “/images/prince.jpg”
rating: 5

This is the post body, where I write about our last chance to party before the Y2K bug destroys us all.

Given this example, our collections settings would look like this:

collections:
– name: “blog” # Used in routes, e.g., /admin/collections/blog
label: “Blog” # Used in the UI
folder: “_posts/blog” # The path to the folder where the documents are stored
create: true # Allow users to create new documents in this collection
slug: “{{year}}-{{month}}-{{day}}-{{slug}}” # Filename template, e.g., YYYY-MM-DD-title.md
fields: # The fields for each document, usually in front matter
– {label: “Layout”, name: “layout”, widget: “hidden”, default: “blog”}
– {label: “Title”, name: “title”, widget: “string”}
– {label: “Publish Date”, name: “date”, widget: “datetime”}
– {label: “Featured Image”, name: “thumbnail”, widget: “image”}
– {label: “Rating (scale of 1-5)”, name: “rating”, widget: “number”}
– {label: “Body”, name: “body”, widget: “markdown”}

Let’s break that down:
name     Post type identifier, used in routes. Must be unique.
label     What the post type will be called in the admin UI.
folder     Where files of this type are stored, relative to the repo root.
create     Set to true to allow users to create new files in this collection.
slug     Template for filenames. {{year}}, {{month}}, and {{day}} will pull from the post’s date field or save date. {{slug}} is a url-safe version of the post’s title. Default is simply {{slug}}.
fields     Fields listed here are shown as fields in the content editor, then saved as front matter at the beginning of the document (except for body, which follows the front matter). Each field contains the following properties:

label: Field label in the editor UI.
name: Field name in the document front matter.
widget: Determines UI style and value data type (details below).
default (optional): Sets a default value for the field.

As described above, the widget property specifies a built-in or custom UI widget for a given field. The first field in the example, layout, uses a hidden widget. This widget will not show in the editor UI, but will be saved with the default value (assuming it’s been set) in the document front matter. The rest of the widgets work as follows:
Widget     UI     Data Type
string     text input     string
datetime     date picker widget     ISO date string
image     file picker widget with drag-and-drop     file path saved as string, image uploaded to media folder
number     text input with + and – buttons     number
markdown     rich text editor with raw option     markdown-formatted string

Based on this example, you can go through the post types in your site and add the appropriate settings to your config.yml file. Each post type should be listed as a separate node under the collections field.
Filter

The entries for any collection can be filtered based on the value of a single field. The example collection, below, would only show post entries with the value “en” in the language field.

collections:
– name: “posts”
label: “Post”
folder: “_posts”
filter:
field: language
value: en
fields:
– {label: “Language”, name: “language”}

Accessing the App

With your configuration complete, it’s time to try it out! Go to yoursite.com/admin and complete the login prompt to access the admin interface. To add users, simply add them as collaborators on the GitHub repo.

Happy posting!