Configuring the CMS through its own ui

[Skrubbadubba]

Hello hello!

I had come across this issue with suggestions for a UI makeover for netlify CMS. It was just designs, but one thing that struck me (besides the awesome design) was that he had mocked up some suggestions of new features. One of which was configuring the CMS from the UI. I coudn't get it out of my head, but thought that it might never happen. I thought "this looks so good, I wish this was a thing. Not even the top dogs like sanity is configurable through its UI (maybe for good reason 😛)". Then just a couple of days ago I suddenly got inspired again and thought "well maybe you could make a collection representing the config.yml file???". I quickly got to work, but as 100s of lines quickly emerged I was constantly reminded of this article. After getting my attempt in yml to kind of work but being ugly as hell, I decided to start over with javascript and json.

Enough yipyapping, here is the

Result

https://github.com/Skrubbadubba/static-cms-self-config.

The idea is that we split the config into different parts: the main config.js. This imports all the parts that are next in line, and represent the entire pieced together config object; settings.json. This repsesent all the configurations besides the collections; collections/<collection>.json; these are all the collections. Each collection is given its own file. These are the collections representing content and site settings; collections/metaCollection/collections.js and collections/metaCollection/settings.js. These are the collections that will each respectively control all collections and settings besides themselves (so we don't acidentally break them by using them).

What we get is that we can configure the CMS and edit all the collections (besides the settings and collections collection), from within the UI.

Here are some screenshots:

got damn gimme some dark mode

Here is the folder containing the entire config structure:
config.zip
In case anyone wants to just go ahead and implement it. Simply make sure to bundle and pass the default export of config.js to CMS.init().

The repo has a working example. Clone and run $ npm install && npm run dev && npx @staticcms/proxy-server

You might notice I am using vite in my repo. The reason is simply that its the only thing I worked with (besides messing around with plain js/html/css and learning from w3schools). I know its bundling behaviour, and I know how to use import.meta.glob(). The code is quite reliant on that function in order to import all the modules and jsons correctly. I would very much appreciate it if people would share their own versions working with other bundlers, or just other general improvements.

This brings me to

Limitations

Developing this you could really sense that the app isn't built for this. I opted to splitting up settings and collections. I thought this would be the best balance of keeping the collection list clean, while keeping the entries from having to many nested widgets. The alternatives were to have everything in one file collection, with a file representing all configuration options; the other option was to split into one "settings" collection, one "file collections" collection, and one "folder collections" collection. This illustrates how useful it would be to group collection in the UI (#316 (comment)), as that would make the last option the obvious choice.

The problem is one which is a big limitation in the app - widgets can't access the state of other widgets. This meant that entries in the "collections" collection, needs to contain fields both for the files and folder options. This also means that they both need to have set required: false. Unfourtanetly this also means I haven't provided a fool-proof way for amateur developers to quickly create valid collections (which was partly my goal). Furthermore, all of this doesn't entirely work, which is what I'll get to next.

Bugs (kind of?)

When trying to create a folder collection, you would have to make sure the "files" list widget is empty, while adding at least one object to the "fields" list widget. However, creating such an entry results in a <collection>.json with an attribute: files: [], creating an invalid collection. However, if we populate the "files" widget, but leave the "fields" widget empty, the resulting <collection>.json does not contain a fields: []. If I'm not making sense, try my repo and you might see what I mean.

view_filters view_groups and sortable fields are all object widgets. The object widget has required: false, however, if you leave them empty, their fields get underlined red saying they are required. Even though the object widgets fields don't have required: false, this looks to me like unexpected behaviour considering the object widget itself should not be required. This seems to only happen sometimes, and I can't figure out when. Furthermore, there have been times when this happened for the "filters" object widget.

Last bit

Thanks for reading this wall of text. I didn't really have a good reason to make this (it took quite some time), it was mostly for self-satisfaction, and perhaps a few minor claps from internet strangers. I could perhaps see this being useful for very new developers, who are maybe not psyched about learning yet another technology for making their small-scale personal blog. With this, creating a valid config becomes slightly more fool-proof.

[Skrubbadubba]

Heya.

Just dropping back to say the repo is updated with slightly better usage instructions.

I have now also split file and folder collections. This means that they actually have expected behavior, and the fields that are required (fields for folder collections, and files for file collections) could thus be properly marked as required.