Netlify CMS 2.0

[erquhart]

Overview

View Issues

It's 2.0 time, people! 🔥🔥🔥
This issue serves as an all-purpose tracking center for the 2.0 release. It is the source of truth for dates, release strategy, goals, and relevant issues, and all of these things will shift (especially early on) based on the discussions that take place in the issue.

Tracking

Track the status of all 2.0 issues on the 2.0 project board.

Voting

If you're hoping to see something in 2.0 that isn't currently listed below, you have two options:

1. See if someone has commented with a request for the feature, and thumb up the comment. If there is no comment for it, add one. Please make sure your comment links to an issue.
2. Pitch in! A solid pull request implementing a new feature is the best way to get it in.

Comments receiving a high volume of thumbs up will improve the chances of the feature being prioritized.

Note: we can't guarantee that every item added to the checklists below will make it into 2.0 - only that they will be considered a very high priority. Netlify CMS is a community project, and the more folks pitch in, the closer we'll all get to seeing 100% of our 2.0 goals complete. Let's make it happen!

Timing

The release date for Netlify CMS 2.0 is July 24th.

Release Strategy

Moving forward, 2.0 work will occur on the master branch, and a dedicated release branch will be used for 1.x maintenance releases.

Goals

We've been saying for months that the themes of 2.0 are extensibility and growth. Here's what that's come to mean:

Extensibility

Netlify CMS was created to be extended - editor controls, backends, previews and more can be customized through a minimally restrictive JavaScript API. For 2.0, we want to improve that story by lowering the barrier to entry for extension authoring. Here are the stories for extensibility (checklists TBA):

Improve extension authoring docs

Provide extension starter packages

• Improve widget starter (https://github.com/netlify/netlify-cms-widget-starter)

Rework extension API's

• Backend API ((WIP) Backend API restructure: pagination, refactoring, and plans for Gitlab & BitBucket #1134, (WIP) Backend restructure - Integrations #1171)
• Preview Template API (API Overhaul: Preview Templating #1041, WIP (docs driven development) - Preview API #1311)
• Widget API (Widget types error message #1131 (comment))

Improve community authored extension discoverability

• Provide community widgets reference (#1286)

Growth

The community around Netlify CMS is the reason for it's success. A whole lot of folks have doubled down on the JAMstack as the path forward for development on the web, and thousands of websites have been deployed using Netlify CMS for content management. The more developers use Netlify CMS, the more developers invest in the project, the more the entire community benefits.

For the growth epic, we want to address issues that are expected to have high impact on adoption for Netlify CMS. Stories include (checklists TBA):

Improve implementation docs

Improve SSG and service compatibility

• Bitbucket support ((WIP) Bitbucket integration #525)
• GitLab support ((WIP) Add GitLab Backend #517)
• Configurable entry paths (Make sluggification visible, customizable, and fail-safe #445, content in subfolders… #513)

Provide assistive tooling for CMS implementation

• Configuration generator/validator (CMS visual builder (config.yml generator) #1167)

Image Handling (see umbrella issue #1321)

• Multiple folders for media ([Media Library] Ability to work with folders #1046)

[jimmyangel]

I would love to see Media Library folders as discussed here. Right now it is a bit painful to maintain all images in a single folder.

[math0ne]

Looking forward to bitbucket support!

[rwxrob]

I have been searching for a data-driven CMS and thought Gatsby hit it close, but the OpenGL requirement is a limiter. Hugo also comes close (but doesn't quite hit the mark). Many static sites are simply database views (in the traditional sense) rendered statically. Building a data-driven component into the core of the CMS without any specific dependency would be ideal. I might suggest support for everything from FADB (filesystem as database) approaches (JSON, TOML, INI organized into directories) to a modular method to plugin data view renderers (or fetchers) as attempted with Gatsby. A clean data module system would allow plugging in data sources. The pattern and approach isn't new, it just currently has not been integrated cleanly into any static CMS that I am aware of.

[erquhart]

@robmuh Netlify CMS can edit data files (TOML, JSON, and YAML currently). What specifically is missing to fulfill your requirements? Sounds like it's still going to come down to your SSG since Netlify CMS simply edits source data and does not behave as a source itself (it's literally just a React app).

[rwxrob]

Ok, that helps me understand better. When I hear CMS I usually interpret that to mean something with site generation included (or no ssg like wordpress).

[Jinksi]

Is #1032 going to make it into this release?
[Media Library] Allow uploading multiple images at once, with drag & drop

[ghost]

Could #1267 Be Added To Version 2.0
Desc: When one field is set to true its dependent fields become active for user input. Implementing this will reduce a lot of clutter in the UI and give the user a better UX experience.

[erquhart]

Note: I added a blurb in the summary above about voting - comments that get a lot of thumbs up will have the best chance of being prioritized.

[johnkferguson]

Casting my vote for a configuration generator/validator (#1167)

[Andrewyg]

How about supporting Facebook as one of the OAuth platforms to log in to Netlify CMS since it's one of the biggest social network.

[rwxrob]

I oppose doing anything with Facebook, at all.

[talves]

Are we considering the mono-repo setup within 2.0?

I believe this needs to be done sooner than later. @erquhart After our long discussion in chat about how the starter should be setup, I went and did some extensive heads down testing on a mono-repo starter for those wanting to do a pure React driven build of the CMS. Also, the concerns with globals (#1292) needing to be exposed to create widgets also brings this to the forefront.

Initial Findings: (Some opinionated)

• There needs to be a core library for an extensible netlify-cms in a pure react app.
• netlify-cms-core would have peer dependencies of the default netlify-cms react app as well as a starter example to show how to extend your own custom netlify-cms react app
• The published netlify-cms app would extend upon the core library the same as an example starter and keep all the current functionality of 1.x for compatibility.
• Not sure if we move to Weback 4 prior or after the mono-repo setup
• NelifyCMS supported widgets, previews and editors would be published in the mono-repo and serve as the examples of a starter
• netlify-cms-widget-starter should be a mono-repo the same as the netlify-cms to adhere to best practices of creating and publishing a widget, so the publisher will be familiar and will make it easier to become a contributor of the cms.

I made a valiant attempt (failed) at moving the CMS to a mono-repo using Lerna and Yarn workspaces. I will keep on this to at least have a discussion WIP branch if possible. This is a MAJOR restructure of the folder structure in the cms and would be hard to keep rebased on master.

I also attempted and succeeded at creating a mono-repo for the cms starter. The biggest issue is the dependencies being duplicated in the bundles due to a lack of externals and/or peer dependencies. This is what warrants me to suggest we take a hard look at creating a mono-repo sooner than later.

[ekoeryanto]

netlify-cms-widget-starter should be a mono-repo

I think it should be in cli
something like

netlify widget create <name>

and all netlify widgets in the netlify cms mono repo created by that.

[ekoeryanto]

I also would like to see the advanced(minimal) and easy(full) version, where the easy version is only need to include a js and a css(just like 1.x) and advanced version is;

1. it is minimal (core) version without any widget included
2. widget should be added manually

[mrnoisytiger]

It would be great if we allow different orderings of the file lists, such as by last modified or date added. Right now, the ordering of the posts whatnot in a collection appear to be random.

[erquhart]

@talves great thoughts on the monorepo setup, definitely a 2.0 goal, need to add it to the summary.

[randallmlough]

Would love to see nested fields in the name parameter (issue 595). From a UI/UX perspective, not being able to nest makes it pretty ugly and cumbersome to the user and developer very quickly.

[mbrookes]

@robmuh

I oppose doing anything with Facebook, at all.

Given that Netlify CMS is written in React, that might be a problem! 🤣

[mbrookes]

Being able to define the field name to use for the slug.

At the moment it uses "title", which means you have to have a field called title in a collection, even if it doesn't make sense for the collection content. (For example, in an Authors collection, you have to use "title" as the field name for the field labelled "Author Name".

Related: #445 (in that it calls out the same core issue: 'With no field named "title", entries currently fail to save.'), but doesn't address the need to be able to determine the source field for the slug. Slug editing as proposed shouldn't be a pre-req to addressing the core issue.

[mbrookes]

Being able to define sub-selects / sub-relations.

For example, in Posts, I have a "section" field with a relation to "Sections", so can select "News", "Sport", etc. as the post type.

For a sub-select (or relation), this would restrict the available options based on the prior selection, for example "Local News", "US News", "World News" if News is selected, but "Football", "Hockey" etc if sport is selected.

One select / relation set of choices is dependent on the value of another.

Edit: Discussed in #1267

[mbrookes]

Ability to select which field to display in a relation widget, as distinct from which field is the valueFiled that is saved. (For example displaying the title of a related post, but saving the slug.)

Related: #1063 (but doesn't call out the need to be able to define the field to display in the dropdown)

Edit: Per @erquhart's comment, this is covered by #1303

[erquhart]

@mbrookes can you link issues to those comments?

[liquidvisual]

I saw that Forestry.io just released a 'blocks' feature that lets you choose and order includes with their own sets of properties. Essentially they're "mini templates" inside a content section.

I'd love to see something along these lines. I'm trying to figure out how I could achieve something similar now - perhaps using the List widget.. but all the fields would then be identical?

https://forestry.io/docs/settings/fields/blocks/

[erquhart]

@liquidvisual didn't know about the Forestry feature, but there is a widget in the works that fits what you're describing: #1169

[liquidvisual]

@erquhart Wow, that's awesome - I'll keep a close eye on it. Thanks!

[mbrookes]

@erquhart I've found and linked a couple of related issues. Shall I add comments to those, or is the link sufficient?

For the parent / child select / relation suggestion (for want of a better description), I don't think there's a relevant issue to link to. Should I create a new one?

[erquhart]

Thanks for that @mbrookes - linking alone is fine. Creating a new issue where necessary is super helpful, but I think the droid you're looking for in that last comment is close to merge: #1303

[emveeoh]

Ability to use a separate Git repo for assets (images, video, strings). Main repo would be for app code and the Content repo would be linked, but not actually part of the App repo.

[ekoeryanto]

@emveeoh, ...or maybe separate branch

[david-genger]

I would love to see more options on how to store the data, I want the option of storing the data in the file system, or in a database. the CMS should separate the concerns of where it stores the data.

[talves]

@david-genger you have the ability to register a backend today. You can write a backend for your needs and registerBackend('new-backend', NewBackendClass). There will also be some improvements on this in the 2.0 API.

This example has a backend that writes to the file-system during development.

[david-genger]

I want a backend that writes to a Database @talves

[talves]

@david-genger Right. This is something someone could do outside the CMS. A backend to write to a specific database would be maintained by the community and not be part of the CMS in most cases. I have written a backend myself to write to firebase/firestore for a project (currently private).

[david-genger]

@talves why shouldn't this be part of the CMS?
I feel that the Netlify CMS should support any static workflow. I currently use prismic,io for my backend, and I would like to replace it with Netlify CMS, but there is no support for database management.
A critical workflow currently for static site developers is pulling in content from a database into the website at build time,the same way I do with https://github.com/mbanting/metalsmith-prismic

[talves]

More than one reason for the NetlifyCMS project NOT maintain a database backend:

• The solution already exists for someone to add their custom backend to the CMS
• Hundreds of databases out there, which one would be best maintained by the NetlifyCMS project
• There would be no difference of how to create the backend whether it was included in the main project or if you or I created it.
• All backends will eventually be ported outside the main bundle into their own library package whether core libraries or custom

Discussion: in gitter

[erquhart]

Heads up media library aficionados: a new Image Handling section has been added to the 2.0 checklist by popular demand. Thanks to everyone for voting and commenting, keep it up! Special thanks to @haileypate for pulling together the image handling umbrella issue!

[keybits]

Not sure if this is in scope, but for 'documentation' type sites, the option to create 'versions' of the site would be super helpful. e.g: see: https://docusaurus.io/docs/en/versioning.html

[mbrookes]

@keybits You could take advantage of Netlify's branch-deploy feature. It's how we intend to version the Material-UI docs site - pushing a new branch per version, so branch v1.0.0 will be served as https://v1.0.0.material-ui.com (not live at this moment).

[keybits]

@mbrookes aha - that's a great idea. Thanks!

[mbrookes]

Also, the list of versions shown on the versions page will be pulled from a JSON file in the github repo, so that the versions page is kept up-to-date even for earlier versions of the docs. The v1.0.0 versions page will display a link to the v1.1.0 docs (when it's released), and so on. (Commented out code here.)

[ekoeryanto]

More plugable/extensible/widgets creator friendly or what ever, as seen here and here #1292.

one more issue i found,
I created fontawesome and material icons widgets, both depend on react-virtualized-select
when I use both, they include (duplicate) react-virtualized-select when I use them with script tag method.

ref #328

[ethancalvo]

Jekyll support.
1.0 seemed to work fine with a HUGO site, Jekyll required a workaround.

[delucis]

@ethancalvo Netlify CMS already works with Jekyll. Check out the jekyll-netlify-cms template or the Netlify CMS docs.

[hennessyevan]

Global settings would be great. Somewhere to store prefs that can be accessed globally (by the SSG) but more importantly by the widgets. I just created a youtube widget that would be greatly enhanced by being able to hook into a general setting for an API Key. As it stands, the key is passed through a field in the widget in config.yml but needs to be passed everytime.

[erquhart]

@hennessyevan the Widget API is being reworked under 2.0, and part of that will include allowing widgets to accept a config object at registration, so you'll be able to accept the API key there.

[ekoeryanto]

One more feature.
Web Notification on Deploy

@hennessyevan maybe you want to try my starter to your next widgets. I extracted that starter from my mono repo widgets here

[erquhart]

Update

Top 5 community voted features as of 5/23:

• Media library folders: [Media Library] Ability to work with folders #1046
• Multilingual support: Support for multilingual content authoring #716
• Upload multiple assets at once: [Media Library] Allow uploading multiple images at once #1032
• 3rd party image hosting: Host images using a 3rd party service #432
• Responsive UI: Make the CMS work for mobile (responsive UI) #441

@growdigital is digging into that last one!

Anyone interested in owning or contributing to any of these efforts, please comment.

[erquhart]

Update

We now have a project board for tracking status of all 2.0 issues.

[erquhart]

Also: release date is now set for July 24th.

[jooola]

@erquhart will the release date be respected ?

[erquhart]

I have utmost respect for the release date. Missed it while trying to get some small changes merged in, but will release soon.

[erquhart]

Heads up: 3 of the top 5 requested features for 2.0 can be solved with this PR: #1602

[erquhart]

Closing - current priorities can be tracked here: https://github.com/netlify/netlify-cms/projects/7