WP2Static’s post-processing phase makes a copy of each crawled file, modifying the contents as needed in preparation for deployment.
URL Detection | Crawling | Post Processing <--- here | Deployment
At a minimum, post-processing will alter all URLs in the crawled site, changing them from your development WordPress URL (ie, http://localhost, https://dev.example.com) to your production site’s URL, such as https://example.com
How WP2Static’s post-processing works
Post-processing is much quicker than a crawling Job. Where in crawling we need to request URLs from WordPress, which has all the WordPress overhead, post-processing works by reading and writing files on the filesystem.
We iterate through each directory and file within the crawled site directory (
/wp-content/uploads/wp2static-crawled-site/) and process each file according to it’s content-type.
Currently, within the core WP2Static plugin, we are treating HTML/CSS/JS files similarily, performing simple substring replacements of WordPress development site URLs to our Deployment URL.
For static binary files, such as images, we simply save a copy without applying any processing.
Applying additional processing
We’ve made it possible for ourselves and you/3rd party developers to extend WP2Static’s post-processing stage.
ie, if you want to create your own advanced CSS post-processor, you can call WordPres’s
remove_action() for the
wp2static_process_css action and use
add_action() to have CSS files processed by your own function. You don’t need to write your own whole plugin, this code could also live within your (child) theme’s
Chaining processors is not currently possible, so if you want to use the default WP2Static post-processing for a particular file type and apply additional processing, you can either reproduce our default behaviour in your processor or run your custom processor on the whole
/wp-content/uploads/wp2static-crawled-site/ directory after all other post-processors have run. You would do this via the
Where are the processed files stored?
/wp-content/uploads/wp2static-crawled-site/is generated by the crawling stage
/wp-content/uploads/wp2static-processed-site/is generated by the post-processing stage
Re-processing without having to crawl again
Because we make a copy of the crawled site when post-processing, if you need to re-process your site for deployment but nothing has recently changed within your WordPress site, you can skip the detection and crawling Jobs and just run the post-process (and optionally deploy) Job. Even for very large sites, the post-processing phase completes very quickly.
In the core WP2Static plugin, the only Post-processing option you need to set is your Deployment URL. This should be set as the fully qualified URL to your production site (or staging during testing), ie
https://example.com or https://www.example.com. All references to your development WordPress site (ie, http://localhost or https://dev.example.com) will be replaced by your Destination URL.
The post-processer within the core WP2Static plugin will attempt to rewrite URL patterns of your development WordPress site’s URL (what’s shown in your WordPress Admin Settings > Site URL). It will rewrite regular and escaped versions of the protocol-specific and protocol-relative versions of your Site URL. This helps with many themes, including WordPress default ones using protocol-relative URLs.
Example of what gets rewritten
Given your development WordPress site with a Site URL of
http://localhost and your Deployment URL set to
https://example.com, WP2Static will perform the following string replacements:
http://localhost to https://example.com http:\/\/localhost to https:\/\/example.com //localhost to //example.com \/\/localhost to \/\/example.com
The default post-processor in WP2static is simple (named
SimpleRewriter.php !) so it will rewrite any string matching the above patterns. This is fine for most cases, but in the case that you have a complex setup with say another web application within the
http://localhost/myapp/ path that you don’t want rewritten for some reason, you would need to add your own additional post-processor to correct those URLs if they should remain pointed to your development server.
Being careful with mixed content in your WordPress site
When serving a site over TLS/https, browsers may alert users to any resources attempted to load over http protocol or block them from loading altogether. If your Deployment URL is using the https protocol and you’re seeing issues with your deployed site not rendering properly, check for any mixed-content warnings in your browser’s console. You’ll usually see a warning in the browser’s address bar in the form of a broken padlock when this is the case.
Fixing the code/theme/plugin responsible for generating the URL in the wrong protocol is the best solution, but you may be able to workaround with a plugin to force HTTPS links in all your development site’s URLs (assuming you’re using https protocol). Examples of such plugins are WP Force SSL and Really Simple SSL.
Verifying which files have been post-processed
- via WP2Static’s UI: Caches > Processed Site > Show Paths
- via WP-CLI:
wp wp2static processed_site list
- via the directory:
Ways to trigger post-processing
- via enqueuing a Post-process Job
- via the WP-CLI command
wp wp2static post_process
- adding an action to the content-type specific hook or on the
Ways to clear the post-processed files
- via WP2Static’s UI: Caches > Processed Site > Delete Files
- via WP-CLI:
wp wp2static processed_site delete
Example Processed Static Site contents
The paths should look identical to your Crawled Site contents, unless you are using an add-on that excludes, adds or otherwise modifies paths, such as renaming default WordPress directory structures to hide the fact you’re site is built with WordPress:
/category/uncategorized/index.html /category/uncategorized/page/1/index.html /hello-world/index.html /index.html /page/1/index.html /sample-page/index.html /wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css /wp-content/plugins/wp-search-with-algolia/css/algolia-instantsearch.css /wp-content/plugins/wp-search-with-algolia/includes/admin/css/algolia-admin.css /wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.woff
Overriding Destination URL with a filter
You can use the
wp2static_set_destination_url to programmatically set the Destination URL. See more about Extending WP2Static
What happens to the post-processed site files?
In a typical workflow, processed files are saved to the
/wp-content/uploads/wp2static-processed-site/ directory. The contents of this directory are what is used when Deploying your site.