Enhancement: Non-technical user actions to publish a site

[apowell656]

Is your feature request related to a problem? Please describe.
I have a few people that want to use static sites and the demos I shared with them were all from VSC using Front Matter. Each one of them was like "Wow, that is so much smoother than WordPress/Wix. That is how I want to manage my site." Then I watch their eyes glaze when I run git pull/add/commit/push.

Describe the solution you'd like
Two native actions (assuming node and unfortunately that is not my bag) - Download (git pull) and Publish (git add, commit - with a generic message, and push) added to the "Actions" menu kind of like the "Open site preview" button.

Describe alternatives you've considered
I thought about writing something in Python or Java to do this, but I don't think it is very portable for the environments the user may have or the SSG they are using. Oh, did I mention they are not very technical ;-)

[davidsneighbour]

Reading this I would solve it via an action that uses child_process to run shell commands.

https://stackabuse.com/executing-shell-commands-with-node-js/

The only thing that stands in the way for this solution is that you don't like nodejs scripts ;) I remember reading in the last or previous to that release that there is a parameter for actions where you define the binary that runs your action script. that would be /bin/bash for a shell script in my opinion, but I did not check that and can't find the notes right now.

[estruyf]

Thanks, @apowell656, good suggestion!

I think it was already suggested before, but as it's not yet implemented, it deserves the bump!

Custom scripts are a good start, but having them part of the default experience would be even better.

It reminds me of opening a repository on custom scripts that others are using.

[apowell656]

@davidsneighbour - thanks for the resource but the execution would not pass the wife test for me. The face she makes on how easy or complicated something is makes a great gauge of how useful most end-users I encounter will find a feature or functionality. I would lose her and most people after installing the SSG and git.

One of my goals for the end of the year is to practicing with node (it has remained immensely popular), but you know time ;-)

[estruyf]

Doing some tests with simple-git.

Action behind the pull

const simpleGit = require('simple-git');

const options = {
  baseDir: process.cwd(),
  binary: 'git',
  maxConcurrentProcesses: 6,
};

(async () => {
  const git = simpleGit(options);
  console.log(await git.pull());
})();

Action behind the push

const simpleGit = require('simple-git');

const options = {
  baseDir: process.cwd(),
  binary: 'git',
  maxConcurrentProcesses: 6,
};

(async () => {
  const git = simpleGit(options);

  const status = await git.status();

  for (const file of status.not_added) {
    await git.add(file);
  }
  for (const file of status.modified) {
    await git.add(file);
  }

  await git.commit(`Published from Front Matter`)

  await git.push();
})();

[estruyf]

Thinking of putting this behind a setting: frontMatter.git.actions: true. Once set to true, the download and publish actions will show up in the interface.

[estruyf]

Sync actions will become available in the panel + content dashboard.

[estruyf]

Available in the latest beta.

Activate by setting the frontMatter.git.enabled setting to true.

The default commit message is: Synced by Front Matter. In case you want to change this, update it in the frontMatter.git.commitMsg setting.

[apowell656]

Uh, just amazing! Thank you.

[bwklein]

I think #195 is the related issue.

[estruyf]

@bwklein it is related, but not fully the same. This would be the simple version. The things described in #195 are an extended flow of PRs and merges.

Probably both can exist. Starting with the simple version and seeing how it gets adopted might be ideal to know the next steps.

[bwklein]

@bwklein it is related, but not fully the same. This would be the simple version. The things described in #195 are an extended flow of PRs and merges.

Totally agree, related but not the same. I wrote #195 (too many GitHub accounts) and my intention there was to chain together a consistent process of actions that would work with some FM UI to enable an editorial process, where the writer of the content is part of a larger system of change management. The question in my mind is where the process starts and ends for the content author.

[apowell656]

@bwklein I used to manage an editorial team for a tech media property and the writers flung around Word and Google docs(some used Markdown) until they were approved. #195 seems like it could solve from approved to publish (prepping the technical side - SEO, images, etc.), but I wonder how many writers would feel comfortable with the overall workflow.

A lot of this can be done outside of the system, but it requires some skill in git, repo tech, etc. to make it happen and many 'content editors' who would use the CMS would not know or want to learn the 'coding' side of the process/system to make some edits and pass them for review

I think the problem to solve is the "staging" and production branch navigation, since most SSGs have a dev server you can spin up. Isolating work on staging along with keeping the status of draft would provide the workflow you are looking for I believe, and it provides a pseudo scheduling mechanism.

Just my two cents.