Contents
1 Introduction
I have always wanted to build a synchronously updated static copy for a dynamic blog based on WordPress. On the one hand, it is out of the pursuit of "whole-site caching" and "always online" capabilities. After all, early blogs did not yet implement disaster recovery and active-active deployment. Once WordPress itself went down, the entire site would have access anomalies. On the other hand, I also hope to have a read-only copy that can run independently without the WordPress environment in some special scenarios, such as publishing blogs to private networks (such as DN42), or when port 443 of some domain names needs to be disguised (to conceal the special role of certain paths on these domain names).
In fact, I have also tried other "dynamic blog staticization" solutions in the early days, such as the article on using Hexo to build a static blog based on cloudflare pages (see:Home data center series uses hexo to build a static blog and deploy it to cloudflare pages). At that time, I was actually preparing for the subsequent "staticization": the idea at that time was to export WordPress articles as structured data, and then import them into Hexo to regenerate a static site. This method is theoretically feasible, but I eventually gave up: from format conversion to style customization and the differences between the Argon theme on WordPress and Hexo, all kinds of details require extra work, and the generated site always has a sense of fragmentation in visual effects, which is still far from what I want, a "genuine" static blog that is almost exactly the same as the WordPress dynamic blog.
Until recently, I discovered a very interesting WordPress plugin:Simply StaticIt can directly staticize the entire WordPress website into an HTML file while retaining the original style and page structure, and export it to the local directory of the host machine. This method does not rely on content migration, nor does it change the front-end performance. It is more like putting a "snapshot layer that is independent of the database and PHP" behind WordPress, which makes me feel that this "static" route is finally reliable.
2 Simply Static plugin introduction
Simply Static is a plugin that focuses on making the entire WordPress website static. Its idea is not complicated, but it is very practical: by simulating access to all pages of the WordPress site, "crawl" these pages down, convert them into standard HTML, CSS, JS and static resource files, and finally export them to the specified local directory, or directly upload them to a remote target (such as GitHub, S3, FTP, etc.).
In simple terms, its principle is more like a crawler running inside WordPress, which will visit your website as a visitor and save the rendered results of dynamic pages as static content. This is different from traditional cache plug-ins, which are more about improving responsiveness at runtime, while Simply Static is completely "pre-rendered" and can still run independently after leaving the WordPress environment.
The benefits of this approach are obvious:
- Static resources, fast access: Static sites typically load much faster than dynamic sites because there is no database query and PHP execution overhead.
- High availability: The exported HTML pages can be deployed on any static site platform, such as Cloudflare Pages, GitHub Pages, Vercel, etc. Even if the source site WordPress goes down, the static copy is still online.
- Significantly improved security： Static sites have no backend, database, or other attack surfaces, and are almost impossible to hack into even if they are publicly accessible.
- Easy to integrate into automated processes: Through scheduled tasks or Webhooks, you can even achieve regular staticization and automatic deployment to form a CI/CD-style content update process.
Of course, its "staticization" is not without cost. Because static sites no longer have PHP execution capabilities, all functions that rely on dynamic interactions (such as search, comment, login) will fail - however, if your goal is originally a "read-only copy" or cache acceleration layer, this is actually a very refreshing implementation path.
Simply Static itself supports three export modes:
- Local directory export(Local Directory): Write the generated HTML files to a directory on the WordPress host, suitable for manual synchronization or deployment.
- ZIP file packaging(ZIP Archive): After exporting, it will be automatically packaged into a ZIP file for easy downloading or transmission.
- Remote deployment mode(Remote URL): You can configure remote targets such as FTP, S3 or GitHub, and automatically upload and deploy after export, which is very suitable for fully automatic deployment chain
My personal recommendation is the "local directory export" mode, which, combined with a Git repository and a scheduled script, is not only easy to debug, but also allows the deployment process to be incorporated into the existing version control system.
Note: Why do I not recommend using Simply Static's remote deployment function to publish the site to GitHub directly, but choose to push it manually using Git commands? In fact, the reason is very realistic:Because I can't afford Simply Static Pro(Many seemingly “automatic and hassle-free” functions often have a line of small print behind them: “Paid for use”). Rather than relying on the remote synchronization function provided by the plugin, which eventually leads to pitfalls due to permission or frequency restrictions, it is better to use Git management yourself, which is clearer, more controllable, and easier to integrate into your own deployment process. Although it is a bit “primitive”, for individual users, this is precisely the optimal solution between cost and efficiency. As the old saying goes: “You can have dignity even if you are a prostitute".
3 Git initialization (optional)
This part is not necessary. It is only needed if you plan to store the static files exported by Simply Static in a Git directory and push them to a remote repository (such as GitHub) through Git commands. This article does not cover the specific operations of this part (it was originally included, but I felt that it was not relevant and not necessary, so I deleted it. I will use a special article on "How to achieve fully automated updates of static blogs" to cover it in the future). The reason why it is mentioned here is that if there is such a requirement, you need to perform a series of Git-related initialization operations in a certain order before Simply Static exports static files.
If you just save the exported directory locally and publish the website directly using a web server such as Nginx, Apache or OpenResty, you can skip this step without affecting the normal use of the site. In short, if you don't have the need for "code hosting" or "automatic deployment", Git is not a must here.
However, even if it is just a simple static website, using Git to manage the exported version can also bring some additional benefits: such as version rollback, team collaboration, automated deployment (CI/CD), etc., especially when you want to synchronize this static site to a remote node or integrate it into a larger release process in the future, a Git repository will be a very useful infrastructure.
4 Simply Static plugin installation and settings
4.1 Simply Static plugin installation
Install directly using the plugin market:
After the installation is complete, just click Activate:
4.2 Simply Static plugin settings
4.2.1 Overview
The setting of Simply Static plugin is actually very simple, and the core is two parts:Replacing URLs and Deployment Settings：The former determines which domain name all the links in the exported static pages should point to, what protocol to use, and whether to force replacement; the latter is responsible for specifying where these static files are finally exported, such as packaging them into zip or writing them to a local directory. In most scenarios, you can directly generate a static site after setting these two configurations, and other settings can almost all remain default (the real reason is that other settings are almost all paid~).
4.2.2 “General”-“Replacing URLs”:
Note: The following will use my "static" blog URL"
https://staticblog.tangwudi.com“For example.
1. Replacing URLs
This option determines how Simply Static handles in-site links such as articles, pages, resource addresses, etc. when exporting HTML. There are three options in the drop-down menu:
| Options | Meaning and Use | Recommended scenarios |
|---|---|---|
| Absolute URLs | All full links within the site ("https://blog.tangwudi.com/xx/xx") will be replaced, such as https://staticblog.tangwudi.com/xx/xx, the original "relative path" within the site will not be affected. |
Recommended static site for online deployment |
| Relative Path | Replace the full link withRelative Path, such as /page/ or ../images/xx.jpg | Offline use, portable HTML files |
| Offline Usage | All links become pureRelative file path, such as ./page.html, a zip package suitable for serverless use | Create offline documents, copy to USB disk, etc. |
For static sites that are intended to be deployed to Cloudflare Pages or self-built OpenResty,Absolute URLs is recommended, the most stable and compatible.
2. Scheme and Host
When you select "Absolute URLs", two additional configuration options will appear to define the link prefix:
| Settings | illustrate | Example |
|---|---|---|
| Scheme | Select the protocol used by the link, usually http or https | If your website uses HTTPS, select https:// |
| Host | Fill in your static site domain name | Such as staticblog.tangwudi.com |
The final effect is that all links in the site will be replaced uniformly like this:
https://staticblog.tangwudi.com/technology/article123/
This will prevent the original WordPress domain name from remaining and avoid cross-domain resource loading or failure.
3. Force URL Replacements
The default is off. This option means:Even if the link is already a correct URL, it will be forced to be replaced again with the Scheme + Host you specified.
effect:
- Fixed some old domain names that "slipped through" in plugin/theme output;
- Resolve hard-coded links left by some shortcodes and JS plugins;
- Avoid using multiple domain names for exporting sites, which may affect loading or caching;
- Unified link style is beneficial for SEO and front-end deployment debugging.
Recommended to enable (especially when deploying on a public domain name or CDN)
4.2.3 “Deploy”-“Deployment Settings”:
This section determines the static HTML files generated by Simply Static.How and where to exportThe free version supports two export methods, corresponding to different usage scenarios.
1,Deployment Method
This is how you export a static site. There are two options in the free version drop-down menu:
| Options | Meaning and Use | Recommended scenarios |
|---|---|---|
| ZIP Archive | The exported results are packaged into a zip file, and users can process them by themselves after downloading | Manual backup, one-time transfer scenario |
| Local Directory | Write the export results directly to a local directory on the server, suitable for automatic deployment | Recommended for synchronous deployment scenarios, such as git push or reverse proxy release |
2,Path (export directory path)
This path is the directory path where static files are actually written. Local Directory This path must be accessible and writable by the server where WordPress is located.
If you are deploying WordPress with Docker (like me), you need to use the "-v" parameter to mount the host target directory into the container. For example, to mount the default path of the website created in openresty installed by 1Panel to the "/export/static" path inside the WordPress container, use the "-v" parameter as follows:
-v /opt/1panel/apps/openresty/openresty/www/sites/staticblog.tangwudi.com/index:/export/static
Then fill in the Path of the Simply Static plugin in WordPress:
/export/static
The static site content generated in this way will be directly written into the Web service directory corresponding to the openresty website.
3.Clear Local Directory Before Deploy
This checkbox means: Before each export,Whether to clear the target directory first.
- It is recommended to check this option to ensure that no old files remain in the export directory;
- If you have some additional files that you do not want to be overwritten, or plan to transfer them to object storage, the "Clear Local Directory" option cannot be checked. Otherwise, the "incremental synchronization" effect cannot be achieved, which means that all files must be transferred again for each update.
If you plan to automate synchronization or integrate into an existing Web service, it is recommended to select the "Local Directory" mode and expose the target directory of the host to the container by mounting in advance, such as mapping /opt/…/index to "/export/static" in the container, and then configuring the corresponding path in the plug-in (pay attention to the permissions of the index directory, incorrect settings will cause Simply Static export to fail). In this way, the static content will be directly exported to the Web service directory each time, which is very convenient to use with Git management or reverse proxy.
5 Exporting a static site
5.1 Diagnose compatibility issues first
Before you start exporting, check if there are any compatibility issues between Simply Static and URLs, servers, WordPress, plugins, file systems, and databases:
For example, I have compatibility issues with the redis plugin:
After disabling the redis plugin, it looks normal again:
5.2 Start exporting
Then, depending on the performance of the host machine and the number of pages that need to be converted, it will take different amounts of time. My export time is as follows:
Final export results:
Note: In fact, this kind of export does not necessarily need to be done on a VPS. You should know that the performance of VPS is generally not very good, and it is not suitable for resource-intensive operations (rich people can do it at will). If you must export on a VPS and there are many articles, it may take dozens of minutes to n hours, and the system resource consumption of the VPS will increase sharply during this period. So if conditions permit, you can use a high-performance computer at home to build a WordPress to perform this export operation, and then use the git command or github desktop to complete the push operation. The VPS only needs to git clone it for use later.
5.3 Release
Assuming that the directory exported by Simply Static is directly specified as the corresponding root directory of the web service software website (OpenResty in this case), then it can actually be directly accessed from the local network. However, one last step is required to publish it to the public Internet.
Taking publishing through cloudflare tunnel as an example, you only need to set the public host name in the tunnel to point to port 80 of OpenResty. Generally, if cloudflared is installed directly on the VPS, you can directly point to localhost:80. However, because I deployed it in a home data center with a more complicated structure, cloudflared is deployed on an lxc, and the redundant Wordpress node is on another virtual machine, so I cannot directly use localhost:80, as shown below:
5.4 Actual effect display
I'm surprised by the high degree of restoration, except for the fontawesome icon display problem:
This is because I chose to host the Font Awesome icons locally when using them in WordPress (see article:Home Data Center Series WordPress Icon Font Optimization: Local Hosting FontAwesome, Say Goodbye to API Limitations), the purpose is to solve the problem of exceeding the fontawesome monthly API request limit that was occasionally encountered when importing through CDN.
However, this "optimization" strategy has become a hidden danger after the conversion to a "static site". Because tools such as Simply Static export pure static HTML files, they do not parse or verify whether resources such as JS and fonts are actually accessible. Once these locally hosted resource paths are not exported correctly (for example, font files are omitted, path spelling changes, and MIME types are missing), the front-end will not display icons or have distorted styles:
More importantly, Font Awesome usually relies on a complete set of font files (such as .woff2, .ttf, etc.) and related CSS or JS files. If a part is not exported or improperly configured (such as missing MIME response headers), it will cause the browser to fail to load. In contrast, although the CDN hosting solution is subject to external networks, it can at least ensure that the resources are complete, the path is correct, and the type matches, making deployment more worry-free.
Therefore, although local hosting is more flexible and controllable when running a dynamic blog, it may bring additional maintenance costs and compatibility issues when building a "static version". It is recommended to give priority to using a stable CDN solution when exporting a static version, or to ensure that local resources are complete, the path is correct, and the service configuration is complete, so as to truly achieve perfect staticization with "high restoration and consistent experience". But I won't bother with that. I'm too lazy to bother.
As for the actual effect after "staticization", you can also experience it directly:https://staticblog.tangwudi.com, I will also keep this "static" blog updated synchronously with my main WordPress blog in the future. After implementing the high availability solution of dual-active WordPress nodes, I have now further realized that the "static" blog is always online, which makes me feel completely at ease.
Different WordPress static solutions have different restoration levels. The reason why I can achieve a high degree of restoration after "staticization" is mainly because the Argon theme I use has a clear front-end structure and few dependencies. It uses a lot of native HTML + CSS + a small amount of JS to build pages, does not rely on too much dynamic rendering or asynchronous loading of interactive logic, and does not have complex Ajax requests. Therefore, Simply Static can restore the complete page structure and visual style almost as is during the export process.
In addition, I rarely rely on dynamic shortcodes or features that require login participation (such as likes, rewards, user personalized recommendations, etc.) in the theme, which greatly simplifies the complexity of staticization. In other words, the "pure front-end friendliness" of the Argon theme itself makes it very suitable for exporting as a static site.
In general, if you choose a highly dynamic theme that strongly relies on the database or login state, it will be much more difficult to achieve high restoration after staticization, and you may even need to do secondary development or customize the export process. However, a theme like Argon, which has a clear structure and simple logic, is an ideal match for staticization that can be used "out of the box".
6. Afterword
In fact, there is another extremely suitable usage scenario for the "staticization" of WordPress dynamic blogs - that isUse a registered domain name to publish blog content in the country. Anyway, domestic compliance requirements do not allow the opening of the comment function, and comments are one of the greatest dynamic values of WordPress. In this case, retaining dynamic logic is a waste. It is better to simply export a purely static version and use domestic object storage + CDN for hosting and publishing, easily achieve full-site caching, excellent performance, and even save WAF - anyway, they are all static files, and there is no attack surface.
If we go one step further and combine CloudflareDynamic redirection feature(For example, redirect based on visitor IP country or ASN), you can build an intelligent access strategy:
- Foreign VisitorsAutomatically access the dynamic WordPress main site to get a complete experience, including comments, subscriptions, backend interactions and other functions;
- Domestic VisitorsIt will automatically jump to the domestic registered domain name to access the static read-only version. The page will load very quickly (because it uses domestic CDN), and there is no need to endure the instability and "negative optimization" of Cloudflare in China.
This approach not only takes into account functionality and performance, but also bypasses various domestic compliance restrictions and access barriers, which is equivalent to achievingDual entry and optimized experienceThe best part is that this structure can naturally support "incremental synchronization" and even "automatic deployment", with extremely low maintenance costs. It is very suitable for bloggers who want to target Chinese and English bilingual users and take into account the experience of domestic and foreign readers.
The next step is to fully automate the entire process: weekly scheduled automatic export of Simply Static, scheduled automatic git to github repository, and automatic deployment to cloudflare pages. This will maintain the weekly scheduled automatic synchronization of the "static" blog and the WordPress main blog. Later, I will use a special article to record every step of this process.
