Rewrite Links in source code - Not working

I’m using Bitnami WP Multisite, on Ubuntu (AWS Lightsail).

I’ve set up the following options under the Processing tab:

Rewrite Links in source code-
wp-content/themes/twentyseventeen/,contents/ui/mytheme/
wp-includes/,inc/

Rename Exported Directories -
wp-content,contents
contents/themes,contents/ui
contents/ui/twentyseventeen,contents/ui/mytheme
wp-includes/,inc/

(basically, I copied the default examples)

In my case, the directories are being exported correctly (with the changes to .zip and S3), but the source code is untouched from its original WordPress defaults.

I think it may have something to do with the data in the WP rewrite_rules input field being ignored because of my WP multi setup? Possibly causing a flag to skip?

The description on the rewrite_rules input states:

URLs will be first checked to ensure they are part of this site, not an external WordPress site, which would mess up URLs of linked images, etc

So, it’s possible that I have a URL conflict because of Multi? If that’s the case, I suppose I would need to bypass the URLs being checked?

I searched the repository (https://github.com/WP2Static/static-html-output-plugin/search?q=rewrite_rules&unscoped_q=rewrite_rules) but I’m not familiar enough with this plugin to develop a starting point for debugging.

Any pointers would be appreciated.

1 Like

Hi @Eric, there’s an issue in latest builds with that URL/directory rewriting option, as per this issue here:

There’s an example of a user’s workaround there, if you want to go down that rabbit hole, else can run plugin without using those options for now and implement once they’re fixed. The project’s got more automated tests in place now and generally any fixes come with new automated tests to prevent those areas breaking again once fixed.

I’d guess that there’s double the amount of users now than this time last year, so we’re seeing quicker alerts if anything breaks in a new build, ideally before it gets published on wp.org!

Thanks, @leonstafford! I will definitely look into the statichtmloutput_post_deploy_trigger option and possibly contribute to the broader codebase on this issue once I’m more familiar.

@leonstafford I created a plugin as an interim fix to this issue:

Info: https://github.com/EricP/static-html-output-post-deploy/
Download and for WP install: https://github.com/EricP/static-html-output-post-deploy/archive/rewrite.zip

It works, with a caveat:

  • It breaks the functionality of the live WP static output (/wp-content/uploads/static-html-output/index.html), This is inconvenient, but not a big deal to me because I’m publishing to S3.

The nice thing is that there is no special setup/configs. Just install the plugin. It utilizes the existing data entered in the Static HTML > Processing > “Rewrite Links in source code” text input.

This plugin applies the rewrite rules to the resulting static output files using statichtmloutput_post_deploy_trigger.

However, the odd thing is that the files deployed to S3 are different than the static output.

For example, when this is the code in “rewrite_rules” input:

wp-content/,content/
content/themes/,content/ui/
wp-includes/,inc/
https://mydomain.com,/

The static files reflect that “https://mydomain.com” has been replaced with “/” (to create relative links). However, the files sent to S3 have “https://mydomain.com” injected back into the source code files. I assume that this is because another, secondary processing is happening before the files are sent to S3?

The relative URLs are not a dealbreaker though, just curious.