nickchomey
commented
2 months ago So, i patched the rewrite body middleware to allow for using a RequestHost token to swap the hostname rather than use a relative path, which fixed the image problem.
But all sorts of other issues popped up. And im not sure either way can solve them.
- gutenberg embeds the hostname within post content when sending the data to wp rest api. Could maybe rewrite POST request bodies, but i dont think there's any plugins that do that yet
- issues when creating a link
- etc...
Overall, this really might be impossible. I cant do relative because gutenberg sometimes expects absolute. I cant swap urls because that breaks other things.
As it turns out, even with perfect* conversion of urls to relative paths, wordpress doesnt work correctly.
When you add an image block in the gutenberg editor, if you for example select the media library, you can see the images there if you're using relative paths. However, once you insert it, the image doesn't show in the editor - just its alt text, description etc... and a broken image icon.
The browser itself resolves the relative path though!
If you modify the dom to add the request's scheme and hostname, the image immediately appears. It seems to have to do with the react-dom.js file that is used for the gutenberg editor.
I suppose it might be possible to find some kludge for this edge case (be it modifying javascript or making a separate rewrite rule to ignore this specific url in the JSON data that powers Gutenberg/react), but surely there are others as well. The only reasonable solution is to use absolute URLs, which would actually use far simpler regexes than converting to relative paths (as is currently done).
Could literally be
The rewrite headers middleware plugin that I am using has this capability.
I previously asked the dev of the rewrite response body plugin that i am using to add such a token, and he rejected it/didnt understand the issue. My attempts to do it myself failed (more than anything, I couldnt figure out how to use a local version of the traefik plugin so as to be able to quickly debug and iterate. BUt also the code was a bit confusing), but I should try again.
It shouldn't pose any problem because there's already a middleware rule to change the inbound Request Host header to the prod url, so that WP thinks it has been reached via the production url.
The only edge case i've found so far - which would happen with both relative paths and absolute urls - is the wordpress general settings page, where you can update the siteurl and home url. They are input boxes whose value comes in the initial html response from the server. When you rewrite, it gets changed. If you change anything on that page, the entire page and its form values get submitted and those variables will change in the DB - ruining everything.
The solution I found was to do a regex for those specific input boxes, change the url, do the general rewrite, and then rewrite those input boxes back to the original prod url. It stands to reason there's a few other edge cases that need to be handled like this, but surely quite few. Much easier than endlessly tracking down edge cases where relative paths break (since nothing was ever built or tested in such an environment).