I co-wrote a two-part series of articles on static websites with my friend and colleague, John Kenyon. And it got me thinking - how could I build a good workflow for nonprofits to maintain static sites?

The second of the articles outlines requirements for static sites. I've been using Pelican, a python-based static site generator - I think it's a strong tool, and I've standardized on it - so I'll be using it as the basis for my workflow.

Quickly, here are the requirements:

• A place to host the static files. This could be a cloud storage provider, like AWS S3, Azure Storage, Google Cloud Storage, GitHub, or Dropbox. You can also use a standard shared webhost.
• A theme. You need to either use a theme available for Pelican, or create your own. (If you are like me, you'll either use a canned theme from that link, or have someone else create one.)
• A workflow. That's what I'm going to get to in this article. The standard workflow requires:
• A place to run the command-line functions of Python and Pelican. This could be the Apple, Linux or Windows command line (I personally have been using WSL - Windows Subsystem for Linux).

So what are the requirements for an ongoing workflow? Obviously, if you are technically savvy, you can create a workflow yourself. I edit these blog posts and any pages in Visual Studio Code, and use the Pelican Makefile to use only one command to upload the documents to S3, where they are hosted. (For info on how I did that, here are the details.)

But if you are creating and maintaining a website for a nonprofit organization without much in the way of technical expertise, how are they going to update their site? How are they going to add blog posts?

There are several options. I've had some amount of time testing some of the WYSIWYG web interfaces to the static site generators, and on the whole, I'm not impressed with their ease of use. They are really, it seems, designed for developers, not end-users. And I don't even think a WYSIWYG interface is necessary for site maintenance for many of the use cases for static sites.

Markdown, one of the two options for Pelican (it also understands reStructuredText) is actually pretty easy to use, and has only a few rules. In addition, there are a few decent WYSIWYG Markdown editors out there. So I think that if people just learned to edit Markdown blog posts or pages, and then just put them somewhere somehow, and some backgroud process on a regular basis scanned that resource, and did the site generation and upload, that would be a good way to go.

So the current workflow I'm thinking of is as follows (here site manager is code running on some server somewhere):

• User edits page/blog post in editor of their choice
• User saves page/blog in Dropbox or Amazon S3
• Notification to the site manager of change:
• For S3, this could be via a SQS message that the site manager listens to
• For Dropbox, they have webhooks which can notify about a change
• File sync - site manager will download changed files.
• Site generation/upload - site manager will regenerate content, and upload to host

Obviously the next step is to write the site manager. I don't think it should be too hard - I've coded most of the requisite components in the past. I'll definitely write a blog post if I get around to it. (It's not really worth it unless there are sites to manage, which I don't have at the moment.)