HTML Post-Processing

Last updated on June 28th, 2021

You may occasionally run into issues where some elements of your site aren’t loading over the desired URLs. This can happen when making changes such as adding CDN support or enabling HTTPS on your site. This is a common issue on hosting platforms, but one that we’ve been able to combat with a simple but powerful custom utility called HTML Post-Processing.

While HTML Post-Processing can help with URL replacements on the fly, it is always recommended that these fixes be implemented in your site’s code or database in the long run. Ideally, this tool should be considered a band-aid that merely allows a site to work while a developer creates a long-term solution.

Table of Contents

1. About HTML Post-Processing

2. Access HTML Post-Processing

3. Post-Processing Examples

4. Caveats and Considerations

About HTML Post-Processing

HTML Post Processing can be used to replace strings (or regular expressions) in the page source of a site with something else. The tool manipulates the HTML of a page after it has been built by WordPress’ PHP, but just before it’s served to a visitor.

Enter only one one find-replace rule per line.
The search and replaces are based on either literal strings or PHP Regular Expressions (RegEx), or a combination of both.
Our system will attempt to check the rules for any general syntax errors before allowing the save to complete. However, it is not able to check if your rule has unintended effects, such as a redirect loop.
Be specific and check your spelling.
Rules are saved to regex_html_post_process table in wp_options database table.
What you’re searching/matching is on the left between the symbols #, and the destination/replacement value is on the right.

Use the following general format:

#match# => replace

Access HTML Post-Processing

HTML Post-Processing is part of the WP Engine must-use plugin, meaning it’s enabled by default on all installs on our platform.

Login to the wp-admin dashboard of your site
Click on the WP Engine tab to access the plugin
Scroll down until you see a box titled “HTML Post-Processing”
After entering your rule, be sure to save

Post-Processing Examples

We have included some examples of possible usage below. Be sure to update the rules with your own information as-needed.

Force all references loaded over HTTP to serve via HTTPS for the specified domain

#http://domain.com# => https://domain.com

Load all uploads files from CDN

#https?://domain.com/wp-content/uploads# => http://CDNZONEID.wpengine.netdna-cdn.com/wp-content/uploads

If you are using an HTTPS secured CDN zone you will need the following instead:

#https?://domain.com/wp-content/uploads# => https://CDNZONEID-wpengine.netdna-ssl.com/wp-content/uploads

Force HTTPS on a custom CDN domain for wp-content/uploads

#https?://domain.com/wp-content/uploads# => https://CDNZONEID-wpengine.netdna-ssl.com/wp-content/uploads

Force static content to a secured CDN URL

#https?://(www.)?(INSTALL.wpestaging.qa|DOMAIN.COM|ZONEID.wpengine.netdna-(cdn|ssl).com)/wp-(content|includes)# => https://ZONEID-wpengine.netdna-ssl.com/wp-$4

Force HTTPS on a custom CDN domain

#https?://domain.com/wp-(content|includes)# => https://cdn.domain.com/wp-$1

Exclude a single file from CDN

#https?://CDNZONEID.wpengine.netdna-cdn.com/(wp-content/themes/theme)/retina.js# => http://domain.com/$1/retina.js

Caveats and Considerations

The above rules are not guaranteed to work on all installs or in all situations. This tool is extremely powerful, however there are still things that it can conflict with based on other site configurations.

Plugin or theme functionality can be prevent our mu-plugin from applying the post-processing. If you’re having issues, try disable plugins or changing the theme.
There could be page elements modified after the page loads by javascript. This could either be due to hard-coded URLs in a .js file, or some javascript doing an ajax call to modify the page after it has loaded in the browser. Post-processing won’t be able to touch those elements.
You want to be sure to always “escape” all RegEx metacharacters in the source of the rule. The destination of your rule does not need to have these characters escaped.
Double-check the rules for any potential spelling mistakes before saving.
These rules can negatively affect third party resources if a domain is not specified in the Post-Processing rule, so be specific!
You might notice that only some of the links are being replaced. Often this is due to using (.*) or (.+) in a match when there is more than one instance of the match on a single line. This is common when code minification is involved.
These rules do not affect elements loaded via JavaScript as this happens after page render, and can have unexpected results when used with things such as generated sitemaps.
Post-Processing does not affect the legacy staging environment at all. However the rules still exist in the database. If Staging is pushed back to Live, these will overwrite those on production, meaning they’d may to be re-implemented.
If you add https to all links, for example using just http:// => https://, a domain that doesn’t have an SSL will not load properly. This could be true of 3rd party resources such as javascript or links to other sites in post content. Be as specific as possible with your rules!

NEXT STEP: Common RegEx rules for redirects and SSL