If you are a developer and find MakeStaticSite useful then you may like to consider contributing to its further development. The quality of the existing code could surely be improved and it could be extended in many ways. We indicate some of the broad developments that are possible.

Improving mirrors

MakeStaticSite currently delivers faithful replicas of many sites, but struggles with some of the more modern and complex designs. The completeness and quality of the reproduction can be improved in various ways, which we will consider in sequence.

CMS Optimisation

A large proportion of Web content is stored in content management systems such as WordPress, Drupal, and Joomla. Each has particular, sometimes quirky, ways of doing things. Accordingly, fine adjustments can be made to the mirroring of such systems.

• Modularisation of CMS prep. MakeStaticSite can be used to turn a wide range of dynamic websites into static versions. However, the system was conceived with WordPress in mind and a particular set of requirements and goals. The initial phase (function prepare_static_generation) is designed to fine-tune content management systems ahead of running Wget, but is currently WordPress-specific (calling mod_wp.sh). As hinted, this should be modularization so as to support any number of other content management systems (CMS) …
• … Support for other CMS. The kind of architecture that might emerge will depend on the set of command-line (CLI) scripts available to modify the respective CMS. Other systems that have capable CLI tools analogous to WP-CLI. For example, Drupal Console and Drush are both well-established.

Like for like replacements of Wget

Wget is a mature and highly functional product, but its development has eased off. Two basic avenues that are being explored to try and secure the long-term future of MakeStaticSite

• Support for other Web crawlers. A Probably a key requirement is to add support for Wget2, designed as a replacement for Wget and under active development. However, it is not yet so widely adopted and initial tests with MakeStaticSite have been unfavourable.
  Mirroring tools such as HTTrack should also be considered.
• The use of headless web browsers via Web proxy. This appears to be the best way forward. The main focus is on retrieving Web page elements in their entirety, especially if they contain elements generated by JavaScript, so-called interactive pages.
  Initial exploration is being carried out in Node.js with AnyProxy + Puppeteer orchestrating headless Chrome (with the caveat that AnyProxy doesn’t seem to be supported now).

General System Improvements

MakeStaticSite needs quite a lot of work to become properly established.

• Internationalization (i18n). The instructions for setting up and running MakeStaticSite should be provided in multiple languages, not just (British) English. For guidance on implementation, see the article by Louis Iacona.
• Testing framework. In Bash terms, this is quite a substantial project and ought to include a range of tests, especially to ensure cross-platform compatibility.
• Support for other shells. Whilst MakeStaticSite is authored in Bash, versions for other shells should be possible and the code might not require a great deal of modification. It might even be possible to code a translator.

A Graphical User Interface

MakeStaticSite is effectively an engine configured with a text editor and run at the command-line interface. It that lacks a graphical user interface, making it a daunting prospect for many (even if it really shouldn’t be!).

So, what about a point-and-click GUI? Whatever the interface, most of the effort (and hence user interaction) with MakeStaticSite concerns setting configuration options, so this is where the effort should be concentrated.

It could be implemented in many different ways. The most natural extension would be to use the Common Gateway Interface (CGI) with further Bash scripts that can utilise the MakeStaticSite library files directly. However, this requires some technical know-how on setting up a web server and introduces many security issues, albeit mitigated if installed on a personal computer.
A safer, but still useful alternative, would be to code a standalone web form, in which configuration options are built dynamically in sequence according to user input, mirroring what happens with setup.sh. The output would be (the contents of) a .cfg file that the user could then store in the config/ folder. A limitation with this approach is that it would be difficult to replicate the validation in setup.sh.

A proof of concept that encompasses a web authoring lifecycle of content authoring, site build and deployment has been developed separately and is available for preview — please get in touch if interested.