Open leonstafford opened 4 years ago
Leaving only the edge cases to deal with.
Thanks for testing this @HulaCloud! Will get it sorted before next wp.org release
So, doing some testing with this now, using the following settings (when TwentyTwenty theme active)
Content rewrites:
wp-content/themes/twentytwenty/,contents/ui/mytheme/
wp-includes/,inc/
wp-content/plugins/,contents/widgets/,
wp-content/uploads/,contents/files/,
Directory renaming:
wp-content,contents
contents/themes,contents/ui
contents/ui/twentytwenty,contents/ui/mytheme
wp-includes/,inc/
contents/plugins,contents/widgets
contents/uploads/,contents/files/,
Which generally worked fine. There was 1 missing image, which was a background-image url defined within a stylesheet, like background-image: url("../../uploads/2020/05/thisguyblogs.jpg");
Now, the file exists in the static exported site at /contents/files/2020/05/thisguyblogs.jpg
as expected.
Because we're not currently forcing FQURLs within stylesheets, that image will remain pointing to the wrong path in the CSS file.
We can force that by adding an extra content rewriting rule of /uploads/
-> /files/
but this is dangerous, in that it isn't taking in the context of the whole link and there's a great chance of breaking any other URLs, internally or externally which just happen to have /uploads/
as part of the URL.
My recommendation for now as a workaround is to check for that kind of relative URL within your site and make it a fully qualified URL, like https://example.com/path/to/file.png
@HulaCloud - hope that helps you to isolate the exact paths not being rewritten properly.
I'm not 100% decided on forcing all stylesheet URLs to FQURLs just yet, but that should solve these cases if it goes ahead.
Yes, Rewriting and Renaming processing is not reflecting at deployed site.
Current solution is overly complicated and error prone.
Plugin knows the locations of these key WP directories, so the user should just be able to input against each one, ie: