Integrated CMS

[jimafisk]

This will need to be converted into an epic with individual tasks, but for now just jotting down some ideas:

• Should be git-backed (like NetlifyCMS or TinaCMS)
• Built with svelte so any previews use site's native templates and only one framework is needed
• Editing should be done on the page via .contentEditable
• Widgets will be needed for things like links, buttons, images, and other non flat text data sources (this will be challenging to make work with flexible keys in data source)
• The _blueprint.json file should define the type of widget that is used by the CMS
• Local editing should write to project filesystem unless optional flag is passed to serve command, something like: --ignore-edits
• Remote editing should create a commit in remote repo and kick off CI rebuild (would be nice to support Github, Gitlab, and Gogs)
• Should have to optional flag to build a site without the CMS --cms=false

Down the road:

• Support open authoring (automatic forks for non-members)
• Support drafts (using PRs + review + merge)
• Flexible theming of CMS components

Action items:

1. Think through / mockup admin menu. This would likely be an edit/preview toggle and widget for adding new instances of a type.
2. Brainstorm how to inject CMS during build... do we identify field values in templates and match them to their keys in the data source, then lookup the widget type from _blueprint.json, then wrap the field value in a custom component?

[sanderjson]

Will this require a standard login function to be shipped with all CMS sites?

[jimafisk]

The high level concept I have is that if you're editing a site on a local URL, no login should be required and it would write to the local JSON files of your project. That way you can choose whether to commit and deploy content updates or discard them for testing.

For deployed sites, the build would look to your site-wide plenti.json configuration file to find what backend repository you're using. I'd like to support GitLab pages first since they're open source and support implicit grant, then add GitHub pages support afterward. So you would have to authenticate with those services to use the CMS remotely. The login process would be similar to how NetlifyCMS works, if you're not familiar with that, this old video I made shows what that would look like: https://youtu.be/Xv2ZW-QPAFc?t=425

I also want to add config options to build sites without the CMS for people who just want a static website that has to be edited locally to make changes.

Does that make sense @sanderjson? Curious to hear your thoughts. Thanks!

[sanderjson]

Local in-page editing with a binding to the JSON sounds fine. This type of editor would likely be equally effective just creating markdown files for the content, but I understand the end goal of on page editing. And it does make sense to just tie this to JSON files instead of markdown.

However most content editors would likely need a very simple approach - and live on-page editing sounds great. My question as about the site visitors UX experience...

So an editor would visit their own site and either click an edit button -> which brings up a login dialog etc. Or perhaps their is just access through a un-indexed route (mysite.tld/edit).

At this point the user is logged in and has access to edit all text inside some svelte component. Based on a config file we could allow/disallow certain editable blocks based on user permissions. For example perhaps a basic editor could change content in p tags within article on certain pages, but superuser could edit more -> like foots and header copy.

If I were to use live inpage editing I would want access to basic rich tect actions -> perhaps a floating toolbar. I would also like to save drafts. Would the JSON hold the content as an HTML string? If not how would an editor embed bold, and italics, and links within a paragrpah block? Also are there any security conerns with letting users enter content that is essentially stored as a string that will be passed to the svelte compiler as @html?

[jimafisk]

You're exactly right, the content editor would hit a route like mysite.tld/edit. I like your thoughts on more robust permissions, I figured we'd queue off the user role in the hosted repo (by default GitLab offers Guest, Reporter, Developer, Maintainer), but even this would be a down the road thing. For the MVP it would likely be binary: If you're a member of the repo you can edit, if you're not you can't.

Regarding drafts, I'd like to eventually create something like NetlifyCMS's editorial workflow where it creates a PR instead of committing directly to a build branch: https://www.netlifycms.org/docs/configuration-options/#publish-mode. This too would likely be part of a later phase after the fundamentals are worked out a bit more though.

Even the WYSIWYG (rich text) editor that you mentioned would probably be a later phase, although I recognize the need. I typically only allow very limited elements (b, em, a) in editors for my own projects to ensure things stay within the design specifications. You do have to be careful if letting users save html that is then rendered with @html on the frontend. This will need to be thought through from a security standpoint.

Ultimately I'd like to implement what you're proposing, it aligns with my long-term vision for the project, it just depends on when. I definitely appreciate the brainstorming and welcome any ideas you want to put forth. Thanks for contributing to the conversation!

[jimafisk]

Writing to the local filesystem will be tricky, the closest we may get is providing a download of content changes: https://stackoverflow.com/questions/21012580/is-it-possible-to-write-data-to-file-using-only-javascript

Or the Filesystem API:

• https://stackoverflow.com/questions/371875/local-file-access-with-javascript
• https://www.jotform.com/blog/html5-filesystem-api-create-files-store-locally-using-javascript-webkit/

For local dev, we could use Go as a helper to actually write to the filesystem.

[jimafisk]

Could possibly learn some lessons from the git-backed cms in https://github.com/primo-app/primo

From https://primo.af/faq.html:

Can I use primo's CMS with another IDE/framework?
You can use primo as a headless CMS since it, by default, publishes a static API. So you can consume your site both as a webpage or as a JSON object. And the great thing about using it as a CMS is that you can use primo's IDE to build yourself a custom dashboard, if you're into that kind of thing.

[jimafisk]

We should probably use PKCE instead of Implicit Grant. It looks like GitLab supports this: https://docs.gitlab.com/ee/api/oauth2.html#supported-oauth2-flows

• Why PKCE: https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead
• Using PKCE with SPAs: https://auth0.com/blog/oauth2-implicit-grant-and-spa/