The use of MakeStaticSite revolves around the website you select for the generation of a static version. We refer to this site as the source and distinguish it from the destination, where you deploy the static version.

The location of your source is key as it impacts your ownership of information, responsibilities around publication and the technical knowledge required. These are major considerations, about which we confine our attention to the role the kind of role that we envisage MakeStaticSite to play within the overall scheme of website creation and production.

There are basically two scenarios that cover where and how you host your source.

1. Host the source locally, on your own computer, and subsequently deploy it on your hosting provider or in the Cloud.
2. Host the source and deploy with your hosting provider or in the Cloud.

MakeStaticSite can be used in either scenario, the choice dependent mainly on the access requirements for contributors to the site and partly on your technical know-how. We proceed to explore options with reference to the key considerations of information management and site creation.

Information Management

First, consider how the process of creating and publishing a website impacts ownership and management of information (or, technically, data).

• When hosting the source on your own equipment, you have to hand all the information (to be published as content) and if it’s at home or in your office it is immediately accessible, not dependent on Internet access. Also, you are free to work on the content without hindrance, to press the [Publish] button at any time, to make and review as many revisions as you wish, until you decide to publish online.
  At the same time, this places a greater responsibility on ensuring that you maintain backups and are able to restore them. However, the main drawback is that it provides other contributors with limited access to the machine; in many cases, it’s simply not feasible to share access outside the household or office. Thus, such arrangement usually only suit individuals or small close-knit groups.
  
• When using a content management system with a hosting provider, whether that’s WordPress.com or one of the many ISPs, the information is stored in a database, with the provider. If the service is in the Cloud, then it is furthermore distributed across multiple nodes in the global network. The provider has some responsibility for making backups and usually provides tools to do that. However, usage depends on Internet access and care is needed to ensure that you retain copies of the data in the right format.
  The main advantage over self-hosting is that access can be granted to anyone with Internet access.

To help assess the viability of moving to a static public-facing site, it may be helpful to carry out an audit of the existing arrangements, in terms of content and the technical infrastructure supporting it.

We now move on to consider implications for site creation.

Development: Local or Remote?

The use of MakeStaticSite itself requires relatively little in the way of technical knowledge. However, irrespective of where you actually deploy the resulting static site, there’s more involved if you decide to develop your website locally, as that implies you (or a trusted person) are acting as your own hosting provider. In this scenario, you need some technical experience of setting up web applications; it’s not sufficient to know how to administer a CMS through the dashboard.

Setting up a CMS locally means downloading, installing and configuring a database management system plus scripts and/or templates. They are typically obtained from dedicated open source project sites such as wordpress.org and drupal.org. The software will require updating, sometimes the system will have hiccoughs and things will stop working. So it is not a trivial commitment. However, most of the popular CMS have greatly simplified the whole process. For example, see WordPress comprehensive instructions and the various Drupal demos.

Once set up, developing your site locally gives you greater control and fewer security concerns — as long as you maintain the requisite security of your computer. And as the output is a set of static components, you don’t have to worry about compatibility of PHP version on the hosting provider. Furthermore, if it’s a locally installed WordPress site, MakeStaticSite can be configured to use a powerful command-line tool, WP-CLI, to carry out enhancements without manually configuring options through the dashboard. It may or may not be possible do this on a hosting provider, depending on their operating system and security practices.

Alternatively, you can build the site on a hosting provider and then deploy the static version either with the same provider or with another; with WordPress, it is possible to convert an existing setup to do this. It involves working with multiple domains and with any hosting provider you need to consider access restrictions otherwise you are making the dynamic site available to the public (which rather defeats the purpose of MakeStaticSite). This has the advantages of avoiding the technical overhead of creating and maintaining your source locally, and of allowing a group to continue working on it as before.

Deployment

Before running MakeStaticSite, you also need to decide where to deploy the static version. It depends on where you are running MakeStaticSite and the location of the destination.

Whether you are running MakeStaticSite on your own machine or on a remote host, there are basically two scenarios.

1. If you are both hosting and deploying the site on your machine, we call that local deployment. In this case, it’s a simple matter to deploy sites (using the cp command) to another directory on the file system.
2. If you are deploying to a different/remote host, then MakeStaticSite needs to make the transfer using rsync over ssh, for which the prompt for credentials may be avoided by the creation of a public/private key pair. This is widely documented (see, for example, instructions by Indiana University).