Generate and edit config through CMS UI

[erquhart]

- Do you want to request a feature or report a bug?

Feature

- What is the current behavior?

Users must manually create a config in yaml

- What is the expected behavior?

Users should be able to configure the CMS through the UI. The output is still just a yaml config file that is version controlled.

Considerations:

• Allow disabling through manual config
• Strong warnings for changing certain fields, e.g. anything under backend
• Provide access through the top right settings menu
• When settings editor loads, compare deployed config and notify user if any changes are awaiting deployment.

[erquhart]

Related to #322

[josephearl]

This would be awesome 💯

[tech4him1]

It would be good to be able to have an option to disable this as well -- if you are building it for a client, for example.

[americool]

I was thinking about starting to try to tackle this. Is anyone currently working on it?

[Benaiah]

@americool not that I know of - we'd love your contributions towards this. I think the best strategy for tackling this would be to use the CMS editor with a stub config that allows you to edit the config.yml itself as a file collection - what are your thoughts on how you'd tackle this?

[erquhart]

The main challenge with this is that the backend config must be made available separately from the rest of the config, so the CMS knows where to get the remaining configuration (along with other content). The other issue is dealing with the GitHub API's intermittent caching delays when editing single files - having configuration in a state of flux could have harmful consequences.

[americool]

@Benaiah I'm not 100% sure, you'll have to forgive me I haven't touched the repo in a month or two so I'm still getting reacquainted with it. That being said, I think what you suggest makes sense. I imagine, looking at the example page (which I assume I can tackle this problem from...but maybe not) within the settings sidebar option we also want a link to "Edit Config" which would then render (some) of the config options and allow the user to edit and save them (via github API PR/Merge)? Any any pointers as to where to start would be great, I also just want to make sure I'm not barking up the wrong tree.

[americool]

I've been messing around with it for a while now, I think I following @Benaiah's suggestion makes sense and was the approach I found myself naturally moving towards (that is - if I'm clear on what is meant mean by stub config.) @erquhart's points definitely need to be addressed, but I'd like to get just the most basic stuff up and running on my end first. Alas I'm currently having a little trouble actually getting a file collection to render appropriately - can someone point me in the direction of where the test-repo data is? (Particularly something along the lines of file: "_data/authors.yml") so I can see what I'm doing wrong? thanks!

EDIT: found the creation of _data folder in the index.html inside of the example folder. Still struggling to get a mock config file to render though...I'll keep working on it.

[erquhart]

@americool don't use the test backend for this, not even to get the ball rolling. The CMS has to load an actual config file, which the test backend can't provide. Instead, set up a repo to test against, and create a new file type collection pointing at "config.yml". You can start with just a partial definition of the config file - maybe a non-existent field, so you can see it in action.

We're here to help, feel free to comment back with more questions.

[americool]

Alright thanks, I can do that with my repo, I'd just avoided it because for whatever reason it takes a short lifetime to start up.

[erquhart]

If you're not already, try using yarn. Well, that'll help with install speed, anyway.

[americool]

I've got yarn, but that doesn't really make a huge difference on the build time on the cms, might be a little shorter, but it's not notable. I maybe misunderstanding, and hopefully there's a much better way to do this, but if I'm not using the test backend I'm currently running my jekkyll site locally and having it point to my cloned copy of netlify, which is where the real stop gap seems to be since every time I change anything, it takes about 3 minutes to re-serve the site. (I've tried using the example config file to point at my repo instead of the test-backend, but while it can render my post collections, it doesn't seem to recognize the config as a file collection, or any other sample file I try to make to test it out.)

That aside, when running off my site with the local cms copy, I can get it to recognize the config file (at least pop up as a link, and it allows me to navigate to a new page and add more data) but using that or a much simpler file I attempted just to test out never seems to render the already existing data. I'm probably missing something obvious, but feel free to have a look at the config file, currently with the couple of fields I have for the config collection it's kinda in a forever-load/break and the test .yml (something else) won't read the existing data, which is the behavior the config collection was exhibiting before attempted to put proper fields in.

https://github.com/americool/americool.github.io/blob/morenetlify/admin/config.yml

[erquhart]

@americool join us on Gitter, it's a better format for this kind of discussion. That said, I will say that your current problem is probably that you're using the List widget instead of Object.

[americool]

Thanks! Will do.

[t1merickson]

Design needs for 1.0 are more polish; longer tail could involve larger design redo

[erquhart]

Related to #534. I'm not sure the resulting interface should simply be 1:1 UI for the config, per se. Most of the configuration should be editable in this UI, but it should be a higher level unified Settings UI that is itself configurable and extensible.

[mittalyashu]

use the CMS editor with a stub config that allows you to edit the config.yml itself as a file collection - what are your thoughts on how you'd tackle this?

As @Benaiah has mentioned, that strategy will not work to solve this issue.

Why @Benaiah idea will not work?

As I understand how NetlifyCMS work, it reads the config.yml file connects to the .git repository hosted online, fetch the data and show it.

Neither NetlifyCMS allows us to add additional widgets using the interface.

So, it will be just like editing the pre-defined fields using the NetlifyCMS, which is of no use.

How we can implement issue #341?

Using Layouts (optinal)

We need to create layouts.

NOTE: Do not mix layouts with collections.

What are the layouts?

Layouts will be a set of fields and widget (just like we do in the collection).

For example: I will create a layout name post.

Which include the following widgets:

1. String (Layout)
2. String (Title)
3. String (Description)
4. Date (Date)
5. Boolean (Published)

and now we can use this layout for whichever collection we want.

What's the difference between collection and template?

According to the NetlifyCMS docs of collection, we can define fields based on folder or files.

Sometimes we might duplicate the fields in the collections. That's why we need to use layout.

Where we can create layouts in a file layout.yml, and use post layout in the as many folder collections we want, without even duplicating the code.

Adding/removing widgets

Referece from CrafyCMS

We need to allow users to edit the layout or collection by adding and removing fields directly from the interface.

Auth.yml file

Netlify CMS stores content in your GitHub, GitLab, or Bitbucket repository. In order for this to work, authenticate with your Git host. In most cases that require a server. We have a few options for handling this.

Since the user has to provide some authentication details before NetlifyCMS take over. That's why, instead of creating a config.yml, the user will only create the auth.yml file.

In which the users will only provide the detail related to auth so that NetlifyCMS can connect to the .git repository.

Inside the auth.yml file (just an example).

backend:
  name: github
  repo: owner-name/repo-name
  branch: master
  auth_key: xxxxxxxxxxxxxx
  app_key: xxxxxxxxxxxxxxxxxxxxxx

All the available auth options.

Inside NetlifyCMS

Once the user is inside the NetlifyCMS there should 3 pre-defined sections.

1. Site settings (basic settings)
2. Layouts (users can define/create layouts)
3. Collections (users can define/create collections)

Site settings

These settings can be included in the site settings.

For example:

• Site name
• Published mode
• Media folder
• Public folder

and the same goes for the other two, layout and collections which follows the rule of adding/removing widgets using NetlifyCMS.

[erquhart]

Thanks for the thoughtful breakdown @mittalyashu!

We'll generally want to maintain a physical config.yml and edit it like we do other files. I already have a working prototype of this locally and it runs fine. I've held off work on this because of the following:

1. A Config UI will likely increase the rate of adoption for Netlify CMS, and the editing experience itself should be smoother before we take that step.
2. The Config UI should be informed - it needs to know what extensions have been registered and what options are available for those extensions, which will require changes across most of our registration API's.
3. The Config UI is a big part of the general onboarding story for Netlify CMS. It shouldn't just be a general file editing screen - there will be considerable product design effort behind whatever we put out for this. So it's a heavy lift.

For now this should be considered a future improvement, likely post-3.0 (which is scheduled for December). In the meantime, @talves has published a fantastic external configuration editor, you can find it here: https://netlifycms-configurator.netlify.com/

[mittalyashu]

1. the editing experience itself should be smoother before we take that step.
2. there will be considerable product design effort behind.

It seems like the first step is to design the interface only.

I have started working on the new design for NetlifyCMS and I am happy to discuss about it in they community discussion.

[erquhart]

@mittalyashu definitely, designing the interface is the first step - we're just not ready to take that step yet.

I think I mentioned this to you elsewhere, but we're not looking to overhaul the design of Netlify CMS right now. Definitely interested in specific, focused improvements, though. Can you reach out to me on Gitter if you have questions on that?

[numoonchld]

this would help add a new folder collection directly from the CMS UI, instead of having to manually create the config and adding the folder in the site repo for a new folder collection.

This is especially useful for creating multiple blogs on the same site.

[justinmahar]

Creating config entries manually is a huge pain point. It's slow and cumbersome.

Even a crappy standalone UI that knows about the NetlifyCMS config spec and allows you to plop in your current config.yml to edit it would be amazing. Having it integrated directly into the site admin would be icing on the cake.

[Kinark]

Omg, I just found this thread but I just finished my own version of an external tool to edit the config file.

Well, I know that @talves developed something similar in the past, but now that I'm here, I'd like to share my tool too:
https://netlify-config-builder.marcossi.com/

It's an open source project hosted on https://github.com/Kinark/netlify-config-builder

[justinmahar]

@Kinark AMAZING

[BranonConor]

@Kinark this is awesome! The docs are a little slim for this tool, would you mind giving a little more information on how it works and how exactly it addresses the issue in this thread? Would love to try it out!

[austincondiff]

Just to give you a visual of how this might look...


Via #2557

@Kinark That is some great work! Is this something that we might be able to leverage this work in this effort?

[Kinark]

@BranonConor Thanks and oc! It's a simple third party tool to generate and edit the config.yml. On the left side you can create and select Files/Folder collections. On the right side, you can edit them. It's pretty intuitive and you can import your own YML files into it. Just use it for a while and you'll get it :D

[Kinark]

@austincondiff Jesus Christ, you, my friend, did a great work over there. Of course, we can use it! I'm 100% into your vibe. If you want, contact me by email (igor@marcossi.com) so we can work on a PR together to implement your new UX. I'm a designer myself (besides developer), so I believe I can help you if you want :)

[austincondiff]

@Kinark I just sent you a slack invite. Send me a DM when you join and I’ll get you up to speed with where things are at.

[BranonConor]

@Kinark awesome thanks so much! I have been messing around with it and I noticed the yaml file it spits back out is in a different format then what I had originally based on NetlifyCMS docs, will it still be read properly?

For example what may have looked like this:
collections:

• name: "blog" # Used in routes, e.g., /admin/collections/blog
  label: "Blog" # Used in the UI
  folder: "source/_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: "Draft", name: "draft", widget: "boolean", default: true}
  • {label: "Type", name: "type", widget: "hidden", default: "blog"}
  • {label: "Excerpt", name: "excerpt", widget: "string"}
  • {label: "Title", name: "title", widget: "string"}
  • {label: "Publish Date", name: "date", widget: "datetime"}
  • {label: "Featured Image", name: "thumbnail", widget: "image", required: false}
  • {label: "Body", name: "body", widget: "markdown"}
  • {label: "Categories", name: "categories", widget: "string"}
  • {label: "Tags", name: "tags", widget: "string"}

Becomes:
collections:

• name: blog
  label: Blog
  folder: source/_posts/blog
  create: true
  slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
  fields:
  • label: Layout
    name: layout
    widget: hidden
    default: blog
  • label: Draft
    name: draft
    widget: boolean
    default: true
  • label: Type
    name: type
    widget: hidden
    default: blog
  • label: Excerpt
    name: excerpt
    widget: string
  • label: Title
    name: title
    widget: string
  • label: Publish Date
    name: date
    widget: datetime
  • label: Featured Image
    name: thumbnail
    widget: image
    required: false
  • label: Body
    name: body
    widget: markdown
  • label: Categories
    name: categories
    widget: string
  • label: Tags
    name: tags
    widget: string

[Kinark]

@BranonConor Yep, it looks different cause it's been translated between JSON and YML some times, but it should work as expected!

[bmackinney]

I used theNewDynamic/hugo-module-tnd-netlifycms to create a CMS generator using Hugo. Check it out at basa-casa/hugo-module-bc-nc-admin, with a preview available at https://netlify-cms-generator.netlify.app/nc-admin/#/