We describe how to make an existing dynamic site static, keeping it in situ. As mentioned previously, when considering the preferred setup, you may find it convenient to maintain the content management process as it is, especially where there are multiple contributors. The transition requires some work, including a migration from one domain to another, but you can keep the existing hosting provider and once set up it should be straightforward to maintain; fuengsin.org is an example of a site that has gone through this process.
Caveat
This scenario should be considered experimental and carry greater risk as it has received very limited testing. So, any user should feel comfortable with some troubleshooting, which may involve reading logs and tweaking configurations, etc. It is recommended that you familiarise yourself with the process by first trying out only the initial stages, so that you don’t change the current production process until you have good indications that it’s going to work.
Overview
In this scenario, the basic process is as follows.
- Review requirements – not only for your website, but also for hosting.
- Prepare the CMS for MakeStaticSite web crawling
- Run MakeStaticSite to create a static copy
- Migrate the CMS to a new subdomain
- Secure access to the CMS
Assumptions
- Basic requirements are satisfied
- A registered domain name, example.com, say, with DNS settings (A Record or CNAME) configured on the name servers both for the domain and subdomain(s)
- A website hosted on the Internet by a hosting provider under example.com, with access to cPanel (or similar) to manage the hosting of your site
- You have administration rights over the CMS.
Preliminaries
- Audit the CMS software (plugins/modules) – update with latest versions and then deactivate any unnecessary components (such as anti-spam, which will not be needed for a static site). Review site in a browser.
- Audit the CMS content, fixing broken links, etc.
- Prepare the CMS for optimal static output (for example, see WordPress instructions, noting especially consolidation of all links to use the same port, i.e. use https throughout.
- Back up the CMS database and files.
- Install the latest version of MakeStaticSite (some of the most recent changes are supporting this scenario).
- Populate the extras/ folder with any additional files to be copied over after the run, e.g., for a contact form.
Setting up the hosting platform
We are going to create two new areas, one designated for managing WordPress and the other for staging. They will have their own domains, which for examples sake will be manage.example.com and staging.example.com respectively. The process of creating these areas is the same for both.
- Log in to the site as administrator.
- Create a guest account and, where applicable, edit its settings to remove any admin toolbar when logged in. (In WordPress user management, ensure that the option ‘Show toolbar when viewing site’ is unchecked.)
- Log out.
- Check that you can log in with the guest account.
The next steps involve setting up domains, file paths and certificates.
- First, identify the directory path to your existing (live production) site. In the cPanel dashboard, Domains section, select Subdomain (you can return to the main dashboard by clicking on the 3×3 grid icon on the left hand side). Then in the Domain dropdown list, select the required domain (example.com). Then in the Subdomain field, enter staging.
- Create a new subdomain, staging.example.com
and assign a directory that will be storing the static
production site, e.g. webs/example_newsite/ (we
will define a permanent home for staging later on).
- In the cPanel dashboard, Domains section, select Subdomain (you can return to the main dashboard by clicking on the 3×3 grid icon on the left hand side). Then in the Domain dropdown list, select the required domain (example.com). Then in the Subdomain field, enter staging.
- In the Document Root, select the folder path, e.g. webs/example_newsite. Click on the [Create] button. Then click to go back. This should automatically configure the requisite DNS settings (A Record or CNAME) for your subdomain, which you can check in cPanel’s Domain section, Zone Editor.
- To ensure DNS is working, create a file inside
webs/example_newsite/ and check that it’s
reachable over the Web using http and https
- In cPanel, from the Modify Subdomain page, identify the new subdomain and click on the respective Document root link (alternatively, from the dashboard select File Manager and navigate to the webs/example_newsite/ folder).
- Click on +File (top right) and create a new file, hello.txt
- Click on Edit to launch am editing window in a new browser tab.
- Enter some text, click on [Save changes] and [Close].
- From the file browser, open the edited file (e.g. double-click) to check the changes.
- Now check that you can access http://staging.example.com/hello.txt
- Also check you can access
https://staging.example.com/hello.txt
If your browser warns that the connection is not secure (i.e., there’s no valid SSL certificate installed), then wait a few minutes and try again.
- If after waiting, there’s still no valid SSL certificate, then return to the main dashboard and install SSL certificate for that subdomain by proceeding to the Security section and clicking on SSL/TLS Status. Identify your subdomain. To its immediate left there should be an icon with AutoSSL Doman validation status — if it’s ‘validated’ then you’re good to go; if it’s ‘unsecured’, then click on [Run AutoSSL] button and review. Consult your hosting provider for further assistance.
- Nowadays certificates should be free; a popular choice being Let’s Encrypt. It’s also standard practice is to use wildcard certificates. However, the default configuration will depend on how long you’ve had a domain, and how it was configured previously.
Creating and deploying the static site
- Run setup.sh, with the source the existing
site with its domain and set login_required=yes.
(We need to test it.)
Also ensure that the deployment directory is the same as the one assigned in cPanel - Run makestaticsite.sh and deploy to the directory (rsync over ssh).
- Access staging.example.com and check that it’s working as expected; re-run the link checker.
Domain Migration
Having established that the static site works, we now need to update some DNS zone settings.
- Start by editing the DNS zone settings to point the addon domain or subdomain staging.example.com to a new path, webs/example_staging/, say.
- Next, re-point the main domain to webs/example_newsite/, and test that the production site at https://example.com/ is the static site and working as expected.
- Thirdly, re-point manage.example.com to the original path of the live site, webs/example/, say.
- Tidy up the .htaccess files in the root of each of these.
The initial phase of the conversion is complete; our main site is being delivered as static content. The next steps are to allow ongoing content authoring through WordPress, in the same manner as before, except that this will be carried out under a subdomain, manage.example.com. Before carrying out any steps, you should save any work and log out of WordPress.
The most straightforward method to change the domain is to use WP-CLI. Having determined whether this be used remotely from your machine or on the server of the hosting provider, carry out a dry run with the search-replace command:
wp search-replace 'example.com' 'manage.example.com' --dry-run
Review the output and, if all is okay, then execute the change:
wp search-replace 'example.com' 'manage.example.com'
Having carried out these changes, launch a browser and log in as administrator at https://manage.example.com/wp-admin/ and check that you can navigate the dashboard as expected. In particular, in Settings: General, check that both the WordPress Address (URL) and Site Address (URL) is https://manage.example.com. Note that not constraining the search-replace operation applies sweeping changes, which may mean any instance of the exact string example.com that is found, including post content, will also be replaced.
There are many other possible uses for this command, such as enforcing https, e.g. wp search-replace http://example.com https://example.com.
An alternative to running wp search-replace is to use PHPMyAdmin, which offers a little more control to those familiar with SQL.
Finalisation
The final steps are to restrict access to the CMS to logged-in users, as per the instructions on access restrictions.
Now the CMS can only be accessed by login through manage.example.com, whilst open access to static site is at example.com. So, in order to continue using MakeStaticSite, update the url field in the .cfg file to manage.example.com. The other fields can be left unchanged.
Done!