Roadmap

[KaneFreeman]

Future (TBD)

• Add documentation for non-Netlify Deployment #48
• Media library folders should not be requested from git #827
• On Change Event collapses list again after data insight has been modified #1049
• Gatsby develop fails static-cms-gatsby-netlify-template#38
• Widgets Repo #1048
• Relation Widget, support creation of record #295
• Feature request: query referenced entries for use troughout the app, not just by relation widget. #632
• Update Gitea backend to work with editorial workflow #1047
• Custom Formatter #484
• [Folders] Drag and drop items between folders #784
• Alternative multiple_folders option for i18n structure #973

[CamilleScholtz]

Great project! Why remove the editorial workflow though, I always found this feature very useful!

[KaneFreeman]

Great project! Why remove the editorial workflow though, I always found this feature very useful!

Great question, that has a long answer.

So the idea of an editorial workflow is great, but the implementation as it was, was not great. It effectively split each backend implementation (or at least the ones that even had it implemented) into two completely different modules, with the editorial workflow side taking way more code to achieve. It also split the UI in many places into two separate setups.

All of that added up to a lot of complexity that slows down future enhancements to the project, as well as increasing the possibility of bugs.

I believe the editorial workflow can and should be handled outside of the core application. I am planning to creating a guide and some templates to show how to achieve a similar result without the extra bulk the previous setup brought. This approach will also allow for far greater customization of the editorial workflow.

[ryangittings]

Following along on this! Hoping for a supported CMS with this setup. Quick question - will there be CDN support for quick installation?

[KaneFreeman]

Following along on this! Hoping for a supported CMS with this setup. Quick question - will there be CDN support for quick installation?

Yes I am planning on supporting that still. From that front little will change at first.

[geotrev]

Would love to contribute. thanks for making this fork! will look over the changes since the fork and pull in the changes i already proposed over in the original repo. cheers.

[KaneFreeman]

Would love to contribute. thanks for making this fork! will look over the changes since the fork and pull in the changes i already proposed over in the original repo. cheers.

That would be awesome! Right now the main branch is pretty much a modified version I am using in another project. I am working on a bigger upgrade / rewrite of the repo into TypeScript. There is still a lot to work to do on the rewrite (its very much broken at the moment), but you can see the progress in this branch: https://github.com/StaticJsCMS/static-cms/tree/feature/typescript-conversion

[geotrev]

Would love to contribute. thanks for making this fork! will look over the changes since the fork and pull in the changes i already proposed over in the original repo. cheers.

That would be awesome! Right now the main branch is pretty much a modified version I am using in another project. I am working on a bigger upgrade / rewrite of the repo into TypeScript. There is still a lot to work to do on the rewrite (its very much broken at the moment), but you can see the progress in this branch: https://github.com/StaticJsCMS/static-cms/tree/feature/typescript-conversion

Very cool. Happy to wait for those changes to land, or add on top, whatever slows you down the least. :)

[qbeauperin]

Thank you for taking things into your own hands and making this fork, I'm very much looking forward to the first stable version so that the newbie that I am can start helping out. 🙌

[mildred]

Thanks a lot for picking this up and cleaning up the code.

May I suggest to look for PRs of the original Netlify repo, I'm thinking in particular of decaporg/decap-cms#4670 which improves the media library allowing to have subfolders. There is a specific implementation at GitHub GraphQL library but I don't see why it needs a specific backend implementation instead of using the existing backend features.

[airtonix]

Great project! Why remove the editorial workflow though, I always found this feature very useful!

Great question, that has a long answer.
...
I believe the editorial workflow can and should be handled outside of the core application. I am planning to creating a guide and some templates to show how to achieve a similar result without the extra bulk the previous setup brought. This approach will also allow for far greater customization of the editorial workflow.

I might be ignorant, but without editorial workflow, how does a user stage a bunch of changes to various documents before publishing?

[merwok]

I guess you’d have to make a branch and edit the config file to push changes to that branch, check results on the deploy preview or branch deploy, then make a pull request to merge all changes (without forgetting to revert the config file change).

[KaneFreeman]

An editor workflow can be achieved outside of the editor itself. You can simply add a boolean Draft field that defaults to true to your documents, with your site setup to not publish draft content. Publishing it then is simply a matter of toggling the Draft flag.

I am planning on making a working example of this after the 1.0.0 release, but that is the gist of how it would be done.

[marcojakob]

@KaneFreeman I really like your approach to keep the CMS as simple as possible. Although it's really tough to make those hard decisions - possibly against a few people because it might be their currently used feature. But I think it's better to have a well maintained core than an overloaded CMS with no future.

So thank you very much for taking on this big task!

[merwok]

You can simply add a boolean Draft field that defaults to true to your documents, with your site setup to not publish draft content.

Sure but then you only have the editor preview to see the results, which is not as good as a build of the site to see the real results (the page and automatic menu entries and inter-language links etc).

[Skrubbadubba]

You can simply add a boolean Draft field that defaults to true to your documents, with your site setup to not publish draft content.

Sure but then you only have the editor preview to see the results, which is not as good as a build of the site to see the real results (the page and automatic menu entries and inter-language links etc).

I agree with this. I think the big reason to use editorial workflow was that it gives you a built site - a real preview.

Overall I'm stoked about this project, but I think a deploy preview will be an essential feature missing from this project, and am wondering if @KaneFreeman has any ideas in mind regarding deploy previews?

[KaneFreeman]

Its my opinion that preview deployments are outside of the scope of this project (especially with me being the only maintainer at the moment and our community is still small). Netlify CMS partially supported this (not ever backend could do it) and it nearly DOUBLED the amount of code each backend had.

However, this doesn't mean you cannot have a preview site deployment, using Static CMS as it is today.

I've put together an example template, with posts being able to be marked as draft. Then there are two deployments:

• production - Deploys only non-draft posts
• staging - Deploys all posts

https://github.com/StaticJsCMS/static-cms-next-netlify-editoral-template

[marcojakob]

@KaneFreeman Seems a reasonable approach. I mostly use Hugo which also suports building with our without drafts.

hugo --buildDrafts    # or -D

[KaneFreeman]

Yes, while I used Next in my example, any static site generator that can use environment variables should be able to achieve this.

[KaneFreeman]

Moving #516, #34 and #228 out of v2.0.0 to speed up the release.

Dropping #81 for now. May revisit in the future, but for now will focus on just the Markdown editor.

[ddorstijn]

Is there an expected timeframe for when worked will be started for the multiple file uploads? The progress you are making is absolutely incredible, and I really appreciate the updates. This is the one issue that makes static-cms not usable yet for me in a real project.

[KaneFreeman]

The next release (hopefully today) has support for multi file/image uploads in a single widget.

[mnordhaus]

I really appreciate keeping this CMS simple but providing options to extend it.

I believe using the draft flag and branches to implement an editorial workflow is a great solution.

• draft to distinguish between preview and yes we are ready to go live
• and merging through a pull request for a 4-eye editorial workflow which is essential for a CMS that works in an enterprise environment.

The first part is relatively easy to implement - as mentioned by simply running two preview instances (like two hugo servers)

The second part needs more attention to ensure easy usability. Executing a pull request with Github, Gitlab is very technical, and regular chief editors might shy away from that.

My suggestion is a page extension that handles a pull request that is easy to understand for a content editor.

https://www.staticcms.org/docs/additional-links

What do you think about this?

[KaneFreeman]

I am not intending on adding any pull request support to the app at this time.

[KaneFreeman]

After much consideration, the Editorial Workflow will be returning in v4.0.0 coming to beta soon (hopefully next week)!

[KaneFreeman]

Custom themes will also be coming to v4.0.0

[almereyda]

Open Authoring is now checked, with #897 not resolved yet. Was this intentional?

Or should it be moved to the future section, as an extension to the reinstated editorial workflow in a subsequent release?

[KaneFreeman]

Open authoring is completed. It currently only works with the GitHub backend and will remain as such for the v4 release.

The work for the editorial workflow on the GitHub backend is also ready.

Both are available in the mist recent beta version for v4