Publish vs Save

[squidfingers]

First off, I love Pages CMS. Thanks for putting your time and energy into this.

As I've been testing this out, I've wanted a publish button separate from the Save button. This way, I'm not rebuilding my site every time I save a file. One use case I have is modifying multiple files, but want them to be published to my site all at the same time.

[hunvreus]

That makes sense. I guess the only 2 ways I can think of to achieve that would be:

1. Stage the commits before pushing to GitHub. This would require me to have a copy of the repo somewhere before pushing there over. I don't think I would want to do that, it would be a radically different approach to interacting with GitHub.
2. Stage all commits as you go in a branch (e.g. staging) and merge changes into the branch you build the site from (e.g. main) once ready. I guess you can already do that manually, but I could offer a more user-friendly way to do that via the CMS.

I actually think there may be something to dig further here, allowing you to define actions you could perform with the click of a button or via a webhook.

Does the second option make sense to you?

[squidfingers]

Yes, options 2 make sense, and sounds great. Especially if there was a way to manage it from the CMS. I like this because it would still allow quick edits to main, but provide a way for larger changes to be staged if needed.

[hunvreus]

I'll probably get this done in June as I'm finalizing the Next.js rewrite and I would much prefer having a nice dashboard/landing page when opening up a repo, rather than redirecting to the first collection.

Offering the ability to trigger webhooks (including GitHub actions) as well as tracking the build status are the first things I'll do.

[frodelu]

It's somewhat on the side, but also related, so I'll take a stab at mentioning it here. First of all – I think Pages CMS is a brilliant idea and the little I've tested it so far looks fabulous. But is it possible to add support for optionally using the GitHub flow (branch, commit, PR, review, merge) somehow? It would fit with option 2, but it wouldn't be a static "staging branch", but basically a new branch for every "session", and when you hit "publish" it doesn't really publish, but creates the PR instead.

[kamranayub]

I would vote for this, as it's already the flow we use for OSS contributions in the repo that Pages would manage. Normally we draft blog posts or docs on a branch and merge when reviewed. I think in Pages, right now you'd just switch to the branch (but that requires a branch to be made first manually). When you're done, you go back to GH to review and merge. I bet Pages UX could handle that fairly nicely.

[hunvreus]

I wanted to allow users to define buttons that can trigger a GitHub Action, that may allow you to achieve some of that?

[rachitpant]

@hunvreus

Jumping into this conversation , i think this is great idea of allowing "publish" only when ready. Something else that would tie with this is "editorial workflow" / "Deploy Preview". Both Vercel and netlify allow "preview deployments" live from a seperate branch before its merged.

Just like you request comments in a pull request before merging it , usually you would want to get feedback / comments before saving a file/post and deploying it live.

So instead of just a "Publish" button , it would be nice to have two buttons

1. Deploy preview ( on preview branch by default )
2. Publish live.

[rachitpant]

As i look closer at this deploy preview feature I just requested , both vercel and netlify automatically generate a preview when a PR is created. A second way they generate preview is using a "preview" branch.

If we keep a single staging branch , the "editors" would be forced to push all "unpublished" changes at once. I think the whole point of first saving and then "publishing" is to be able to publish only when ready.

On the pages cms , we would want every post to either be "saved" , "Preview" , or "live". Not so easy to implement though.

[BigBlueHat]

Posted some related thoughts in #142 (comment) mostly around "branch protection" but the end result would be/feel the same, afaict.