Switch from Netlify CMS to a different editing system?

[behoppe]

Issues Over the last week or two I have struggled with configuration issues of Netlify CMS (or bugs? hard to tell sometimes), and I am seeing broader issues with the tool.

• Just a few days ago, Netlify CMS contributors ask Netlify, Is this project dead? (because it's getting no activity for the past several months)
• This blog post affirms my experience that Netlify CMS documentation is "...not good" (as they say politely), and it names several competitors.

Discussion I recommend putting Netlify CMS on notice and considering those competitors. Forestry.io appears to be top of the list.

To be clear, this does not change our use of Netlify. This is only about Netlify CMS.

@cleiserson this concludes my work today trying to fix the problems you and discussed earlier this afternoon. In short, it will probably be better to switch to something like Forestry.io than to try to fix our issues with Netlify CMS.

[behoppe]

Flagging for my partners in process @cleiserson @dcurtisatmit @ailiop

After some research I would say that "switching from Netlify CMS" means we're looking at the world of "headless CMS," which is like a regular content management system (CMS) but uses APIs so it's agnostic about how the data is stored and displayed.

These two links indicate that there are dozens of options:

• https://jamstack.org/headless-cms/
• https://www.cmswire.com/web-cms/13-headless-cmss-to-put-on-your-radar/

So I would say that we're not looking at a quick and simple switch (e.g., from Netlify CMS to Forestry.io), but facing something more like our original website choice of platform -- when we eventually selected Eleventy. As we did for that decision, I recommend considering our priorities. These might include

• integration with GitHub content
• integration with GitHub teams for permissions
• contextual and collaborative editing
• pre-publishing workflow

I suspect that in parallel with this, I/we will want to understand the capabilities of GitHub, because I think GH is our user's "home base" and we don't want to accidentally add some tech layer that separates us unnecessarily from GH.

[behoppe]

@cleiserson @dcurtisatmit @neboat: following up on the team meeting I discussed GitHub workflow with @ailiop yesterday. I liked his suggestions and I have tried to summarize them visually like so:

@ailiop did I get it right? (I have left out some things like "squash" for now, which we probably do want to include soon.)

There is an editable svg at https://github.com/OpenCilk/www.opencilk.org/blob/main/src/img/github-workflow.svg (which I drew with Inkscape fyi).

I look forward to discussing. I think this model reflects everything we discussed on Wednesday, including

• Managing "this release" and "the next release"
• Defining where updates and discussion happen for any page of content being worked on.
• Allowing many different pages to be edited in parallel.

[ailiop]

@behoppe I think this looks very good. I will add a few comments, which hopefully will be helpful — rather than confusing — for some details:

• As I understand this illustration, it shows the commit where a PR/branch starts from. It does not show the rebasing/merging onto main. The latter is trivial when the PRs are independent and requires resolving conflicts otherwise.
• "Netlify CMS PRs" makes it a little simpler to initiate a page-specific PR and edit a page collaboratively without having to go through the GitHub interface or maintain a local clone of the repo. "Manual PRs" could also facilitate collaborative edits if the source of the PR is a branch on OpenCilk/www.opencilk.org instead of a branch on a user's fork.
• One may still interact with a "Netlify CMS PR" as if it were a "Manual PR". That is, one can make comments, request reviews, add commits using a "manual" terminal-based workflow, etc. After all, "Netlify CMS PRs" appear as regular PRs on the GitHub repo.

[behoppe]

Thank you @ailiop. I find those comments helpful, although I will need to think more about the second one: "collaborative edits where the source of the PR is a branch on OpenCilk/www.opencilk.org".

I just discovered a wrinkle to this model: when we disable Netlify CMS "workflow," then Netlify CMS no longer creates pull requests. Instead, each edit session ends with clicking "publish," which generates a commit to the designated branch. There is no pull request, and so there is no page-specific PR deploy-preview. I have configured a site that shows this behavior, and it's generated with content from https://github.com/behoppe/one-click-hugo-cms. So you can look at that repo for a glimpse of what I mean. In that case, Netlify CMS works on the staging branch, which has is a pile of commits corresponding to any edit I've made to any page -- waiting for me to create a pull request for all those commits and merge them with main.

So I think maybe we want to use Netflify CMS workflow in a specific limited way. All we want from that module is to generate pull requests for each page (along with the deploy-previews and comment threads etc.). We do not need it to track draft vs in-review vs ready, because we can assume everything is "pre-published" in Netlify CMS, and we will use GitHub Project to track the specific status levels.

So with the workflow screen, we might look only at "draft" and ignore "in-review" and "ready":

And with the edit screen, we might use only the "save" button and ignore all the other status and publish buttons.

Hopefully this sounds workable? I am not sure how hard it would be to actually reformat those pages, to hide the parts that I propose we ignore.

[behoppe]

Replying to the original 2 posts of this issue, there are important updates in the landscape of headless CMS:

• Netlify CMS has been reborn as Decap CMS (as of Feb 2023)
• Forestry.io is no more, being replaced by Tina CMS

I'm also impressed with how Data Umbrella uses GitHub to run their community blog, which includes this tutorial post on how they did it.