Going static

For a variety of reasons I reckon it's time to convert the public facing version of my website to go to a static version. The reasons include:

  • After the suspension of En Garde there's no dynamic input to the site other than my own (When I restart that campaign I will need to modify the hosting mechanism to provide the form processing - I'll cross that bridge when I get to it)
  • It'll make the site more secure (no WordPress admin on the public version of the site)
  • No more annoying emails from my web host encouraging me to upgrade from a shared host to a VPS due to reaching memory limits (presumably due to the wordfence plugin).

I'm using the Simply Static plugin though I did have to handle some quirks due to the private server sharing the same machine as my fossil repositories and my popmail spam filter.

It should be noted that this post is also part of an experiment to see how the workflow of updating my website is going to go!

Comments: 5

  1. David says:
    17th December 2018 at 6:45 pm

    It does look like the static version works well - though I will need to think through when/if I want to run a game via the site and hence need some kind of form processing

    As a reminder to myself on the workflow when updating the website:

    1. Make the update on the test system
    2. Use the simply static to generate the static site (it will take a few minutes)
    3. While that's running delete all the non-fossil files from the local static directory
    4. Download the resulting zip and unzip into the local static directory
    5. Start Filezilla
    6. Use fossil extras to identify new files. Use fossil add to add to fossil and use filezilla to schedule the upload
    7. Use fossil status to identify changed and deleted pages (if deleted consider setting up a redirect on the test system, adding to simply static's setting going back to step 2). Deleted pages need to be deleted on the live site. Changed files need to be scheduled for uploading (uploading the containing directory will typically be OK)
    8. Process Filezilla's queue
    9. fossil commit to get the changes into the fossil for next time

    Although complicated this minimises the amount of uploading as this uses fossil to identify all the changed files (typically there will be quite a few due to updates affecting the sidebars and/or footer).

  2. David says:
    22nd December 2018 at 9:06 am

    Of course using WinSCP and its synchronization options is much easier. With that the workflow becomes:

    1. Make the update on the test system
    2. Use the simply static to generate the static site (it will take a few minutes)
    3. While that's running delete all the non-fossil files from the local static directory
    4. Download the resulting zip and unzip into the local static directory
    5. Start WinSCP
    6. Use fossil extras to identify new files. Use fossil add to add to fossil
    7. Use fossil status to identify changed, added and deleted pages (if deleted consider setting up a redirect on the test system, adding to simply static's setting going back to step 2). Use WinSCP synchronization mode (using both file timestamp and file size to identify changed files) to identify changes that WinSCP thinks is appropriate. This will select everything (due to the changed timestamp, so unselect everything and then use the output from fossil status and select the actual files to be updated. Note that WinSCP will take a while to run the initial check!
    8. Process WinSCP's queue
    9. fossil commit to get the changes into the fossil for next time
  3. David says:
    11th January 2019 at 10:03 am

    After generating, clean up simply static's directory (plugins/simplay-static/static-files) otherwise All-in-One WP Migration will include that in the export file (ballooning that quite nicely!)

  4. David says:
    5th May 2019 at 5:33 pm

    The generation can take long enough that it exceeds the execution timeout. This can be overcome by extending the timeout. I did this by adding
    php_value max_execution_time 300 to the .htaccess file

  5. David says:
    22nd February 2020 at 1:05 pm

    See also Automating the static upload (Feb 2020).