search

decaporg / decap-cms

A Git-based CMS for Static Site Generators
https://decapcms.org
MIT License
17.84k stars 3.04k forks source link

Netlify CMS 2.0 #1280

Closed erquhart closed 5 years ago

erquhart commented 6 years ago

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

Rework extension API's

Improve community authored extension discoverability

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

Provide assistive tooling for CMS implementation

Image Handling (see umbrella issue decaporg/decap-cms#1321)

jimmyangel commented 6 years ago

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 commented 6 years ago

Looking forward to bitbucket support!

rwxrob commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

ghost commented 6 years ago

Could decaporg/decap-cms#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 commented 6 years ago

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 commented 6 years ago

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

Andrewyg commented 6 years ago

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 commented 6 years ago

I oppose doing anything with Facebook, at all.

talves commented 6 years ago

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)

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

randallmlough commented 6 years ago

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 commented 6 years ago

@robmuh

I oppose doing anything with Facebook, at all.

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

mbrookes commented 6 years ago

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: decaporg/decap-cms#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 commented 6 years ago

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 decaporg/decap-cms#1267

mbrookes commented 6 years ago

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: decaporg/decap-cms#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 decaporg/decap-cms#1303

erquhart commented 6 years ago

@mbrookes can you link issues to those comments?

liquidvisual commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

mbrookes commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@erquhart Spot on with decaporg/decap-cms#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 commented 6 years ago

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 commented 6 years ago

I may be misunderstanding, but it seems a bit of a stretch to suggest these are related. decaporg/decap-cms#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 commented 6 years ago

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 decaporg/decap-cms#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 commented 6 years ago

I would love to see decaporg/decap-cms#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 commented 6 years ago

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

(EDIT: linked issue decaporg/decap-cms#441)

jcmrgo commented 6 years ago

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

anaibol commented 6 years ago

What about a GraphQL endpoint?

tarragonparagon commented 6 years ago

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 decaporg/decap-cms#2)

jipiboily commented 6 years ago

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 commented 6 years ago

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

tech4him1 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@emveeoh, ...or maybe separate branch

david-genger commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

I want a backend that writes to a Database @talves

talves commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

Discussion: in gitter

erquhart commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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).