Netlify-cms: 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 (#1134, #1171)
• [ ] Preview Template API (#1041, #1311)
• [ ] Widget API (https://github.com/netlify/netlify-cms/pull/1131#issuecomment-386804125)

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

• [x] Bitbucket support (#525)
• [x] GitLab support (#517)
• [ ] Configurable entry paths (#445, #513)

Provide assistive tooling for CMS implementation

• [ ] Configuration generator/validator (#1167)

Image Handling (see umbrella issue #1321)

• [ ] Multiple folders for media (#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: https://github.com/netlify/netlify-cms/pull/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: https://github.com/netlify/netlify-cms/pull/1303

[mbrookes]

@erquhart Spot on with #1303 - I missed that one and it's exactly what I had in mind. 👍 I believe there's also an issue related to saving the slug for a relation, so I'll link that too when I find it again.

I can create a new issue for the second suggestion, as I don't thing there's a an existing or related one. (Appreciate it may be a hard nut to crack when it comes to implementation!)

[erquhart]

That second issue is an expansion on https://github.com/netlify/netlify-cms/issues/1267, I'd recommend commenting on it with your expanded use case. Still the same general requirement of conditional fields.

[mbrookes]

I may be misunderstanding, but it seems a bit of a stretch to suggest these are related. #1267 (if I'm reading it correctly) enables an input based on a boolean.

What I'm suggesting OTOH s that the secondary relation's collection (Local News, National News, World News, etc.) is determined by the primary relation's selection (News, Sport etc.)

[erquhart]

Ah, didn't understand that - that may be a separate issue, depending on what the select/relation setup looks like to you. If you're saying a select widget essentially determines how the relation widget is configured (e.g. which collection it points to), it can easily be an extension of #1267. That issue isn't about booleans, it's about showing a field based on the value of another field.

If my understanding above is correct, you'd set up a few different relation widgets and show them based on the value of the select widget. If not, probably a separate issue as you said.

[jnowland]

I would love to see #432 added to allow larger image binaries to not always be in the repo which becomes an issue. This could also solve the image manipulation issues as a lot of external image hosts provide that functionality.

[namzo]

I would love to see a mobile version of the CMS (Or a responsive site)

(EDIT: linked issue #441)

[jcmrgo]

I'd love to see multilingual/localization support (https://github.com/netlify/netlify-cms/issues/716) in 2.0

[anaibol]

What about a GraphQL endpoint?

[tarragonparagon]

I'd love to see more flexible permissions settings, namely the ability to prevent certain roles from accessing/editing the posts of others and to restrict the ability to publish editorial workflow posts .

(EDIT: linked issue #2)

[jipiboily]

I'm curious about one thing: upgrade vs breaking changes.

I know it's early...but are you planning and leaning more toward smooth upgrades to go from 1.x to 2.0? Or is it likely that there will be a bunch of breaking changes?

[lsmod]

• Possibility to add custom widget button directly to the rich-text toolbar and choose its position (access in one click no need to click on +).

• Customization of rich-text available buttons and order (show/hide button and position in toolbar).

I see this quiet useful for simple text decoration custom widget like: underline, color, font-size, font-family and such.

[tech4him1]

@anaibol Please create an issue describing in more detail what you are requesting.

@lsmod

Possibility to add custom widget button directly to the rich-text toolbar and choose its position (access in one click no need to click on +).

This would be a separate feature request, please open a new issue. We are working on adding some new buttons in https://github.com/netlify/netlify-cms/pull/1324.

Customization of rich-text available buttons and order (show/hide button and position in toolbar).

This is already available as of v1.6.0.

[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: #1046
• Multilingual support: #716
• Upload multiple assets at once: #1032
• 3rd party image hosting: #432
• 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: https://github.com/netlify/netlify-cms/pull/1602

[erquhart]

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