[Tutorial] How to force Wordpress to use relative urls - ngrok


  • administrators
    | 87338 points

    When sharing your Wordpress site outside through ngrok - all styles, images, scripts are lost.

    The reason is links in Wordpress are absolute and hard-configured in database, you just need to install the odt-relative-urls plugin and it will work:
    https://github.com/optimizamx/odt-relative-urls/archive/1.0.2.zip


  • | 2092 points

    @leokhoa I also found adding these two lines to my wp-config.php worked:

    define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
    define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
    

    (Got that from https://ngrok.com/docs#wordpress) Not sure why, but I actually didn't need any other plugin. 🙃


  • | 2527 points

    @mnelson4 @leokhoa

    define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
    define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
    

    ^^^This totally works fine! I've been using it for years when migrating/switching between environments. I did try the odt-relative-urls plugin, just because I've never heard of it before, and it actually didn't work well for me. It fixed some urls, but not all of them.

    However I do think its worth noting a couple things about HTTP_HOST.

    1. HTTP_HOST comes from the client, so it is not necessarily reliable. In the context of ngrok, I don't really see that as a problem, but I think its worth noting in general, just in case somebody wanted to push that code to a production server. SERVER_NAME is much more reliable, but is dependent on you configuring your server config properly.
    2. $_SERVER['HTTP_HOST'] will throw a notice and muck up your output for wpcli because $_SERVER['HTTP_HOST'] is not defined at the command line. If you're a developer there is a good chance you use wpcli, so you need to be aware of that. The fix is easy, you just need a conditional around your defines, but again, its just something one should be aware of.
    3. This will not work for hard coded absolute paths in the database (which is what @leokhoa did note). However, the hard coded absolute paths are only for user created links in the admin and not assets and urls built by WordPress on the fly (which the majority of the urls). For those remaining hard coded absolute paths, you would want to use a database find and replace tool to strip those out. I use MigrateDB Pro a lot, and it has that feature, but I'm sure there are plenty of options out there. This is where the odt-relative-urls plugin may come in handy since its a filter instead of a constant, but I don't know that for sure as I haven't tested it.

  • administrators
    | 87338 points

    @pfaciana, @mnelson4 : Many thanks for your information. They are really helpful.


  • | 2092 points

    @pfaciana an alternative to MigrateDB Pro for doing a global find-and-replace on your WordPress database is using WP CLI's search-replace command (see the docs). I'm pretty sure wp search-replace "oldsite.com" "newsite.com" --all-tables will do. (Here's how to set WP CLI with Laragon)


  • | 2527 points

    @mnelson4 Totally! I would say that would be my recommended solution as its free and comes from the WordPress' own docs. MigratedDB Pro does have a nice GUI interface and you can automate it in your migrations between environments and automatically backup prior to find and replace, so if you already have it and/or you're not super comfortable with the command line, it's still a good option, but wpcli should be the recommended way. Thanks!


  • | 2527 points

    Oh, and one other note, since I saw it in your example. It would be best practice to always define the scheme, host and port (if necessary) when find and replacing or stripping. You can have a production/staging/dev site that handles both www.example.com site and example.com and http://example.com and https://www.example.com, etc. I typically do four find and replaces options, two with and without the www subdomain and two with and without SSL, and the replace value is the same for all of for of them. Even if you think you don't need it, it's a nice sanity check that I am not aware has any known side effects (unless of course you have a known edge case). OH, and always backup your database first!


Log in to reply
 

Looks like your connection to Laragon was lost, please wait while we try to reconnect.