With MakeStaticSite (and more generally with other static site generators), development is carried out in one environment, whilst deployment is to another. When setting up a web server on our own computer, it is standard practice to choose domain names that designate local development. Then, for deployment, such references are typically changed to reflect the deployment domain or else replaced by relative links.
This is the approach currently used here; when running makestaticsite.sh, references to the source domain, i.e. domain portion of the variable, url, are replaced by relative links. However, there are issues to consider in the conversion to static pages. Ordinarily, in its mirroring process, Wget recognises as far as it can absolute URLs under the domain being crawled, subject to the patterns encoded according to the World Wide Web Consortium’s HTML standards. Having identified such URLs, it replaces them with relative URLs. Whilst this provides assurance that its conversions are generally sound, the coverage of the standards is incomplete and there are further hidden references used by various applications. It means that for most sites, the conversion process is partial.
This leaves the question of what to do about the remaining references to the source domain. It’s a problem that can be addressed in different ways. At present, MakeStaticSite uses a blunt approach, by a recursive search and replace of file contents after Wget has created a mirror. The main issue with this is that it makes unintended replacements, particularly where the source domain is mentioned in a paragraph. If you wish to avoid the risk, then set force_domains=no in constants.sh to be prompted during runtime.
In fact, the MakeStaticSite website has used a temporary fudge because of this — can you spot it? In general, there are workarounds to ensure that any domains can be mentioned in pages, such as wrapping part of a string in <span> tags, though that trick is not always effective as in some contexts tags are filtered out.
Tackling this at source suggests a CMS-specific solution; in WordPress, there is the command wp search-replace, which carries out a basic substitution across tables. The search can be constrained to specific tables and columns. Such an approach could be added as an option. However, a more robust solution probably requires working with HTML DOM.
Same Domain Scenario
It’s not actually necessary to choose distinct domains and MakeStaticSite supports the same-domain scenario. Apart from avoiding the problematic conversions, this approach allows realistic testing before deployment. It’s particularly helpful if you incorporated non-static content, such as a contact form protected by Google reCAPTCHA, which issues domain-dependent keys.
This is enabled through the appropriate DNS settings, as configured by including an entry in /etc/hosts
127.0.0.1 example.comMaintain this whilst developing and then to view the live site, simply comment it out:
#127.0.0.1 example.comMakeStaticSite handles the particular case that the source domain is the same as that of the deployment domain, the hosting provider to which you are transferring files remotely; when running makestaticsite.sh, it will check whether the domain portion of url matches deploy_host. If so, it will look for and, if necessary, modify the respective entry in /etc/hosts ahead of using rsync (hence the variables, ip4re and ip6re, defined in constants.sh). On completion of the transfer, it will revert the settings to how they were.