DEV Community

Cover image for Testing a local WordPress Instance on BrowserStack
Ingo Steinke
Ingo Steinke

Posted on • Updated on

Testing a local WordPress Instance on BrowserStack

Responsive design and progressive enhancement have always fascinated me about my job as a web developer.

Developing and testing on localhost has become quite convenient and easy, and so has cross-browser and cross-device testing. I used to collect old devices and install as many web browsers as possible on my workstation and start VirtualBox with different Windows versions to test outdated browsers and exceptional screen sizes, but I have found BrowserStack to be a more practical alternative.

BrowserStack provides access to actual machines running different operating system and browser versions, including Microsoft Windows, Android, Apple MacOS, and iOS Safari.

Using BrowserStackLocal, I can route requests to my actual local host when typing localhost in the remote devices address bar - unless it's an iPhone.

Due to security restrictions in Safari (on iOS 10 and above), localhost URLs will automatically change to http://bs-local.com.

(quoted from Using Local Testing with Live)

This even works with a port number, so I can use http://bs-local.com:8000 to reach a default local WordPress instance on Port 8000. But to "load your website assets properly, remember to ensure that your local server is configured to serve requests from bs-local.com".

Put more generally, it could be any domain on the internet that is not recognized as a local domain by the machine. We do not need a special client application to reroute traffic. An entry in our hosts file

/etc/hosts

127.0.0.1   localhost pseudo-remote.example.com
Enter fullscreen mode Exit fullscreen mode

would have a similar effect to define a seemingly remote domain that actually serves as an alias for our local server. A useful alias to prevent mixing up cache, cookies, favicon images and saved passwords between projects, but also a an alias to cause confusion using a local WordPress instance.

Configured to Serve Requests?

But WordPress is usually only meant to be run on one single domain (which is also an issue when migrating ). How come it accepts bs-local or pseudo-remote.example.com without redirecting back to localhost?

Well, it does! Style sheets, scripts, web fonts, mostly everything is loaded via localhost, which is why our web fonts have been blocked for seeming to come from an untrusted domain according to cross-origin policy even on our local machine.

Screenshot of cross doamin errors in my local developer tools

How did it work to load anything on the remote machines at all? Now the remote Macbooks do accept the localhost URLs, so I will see the same issue in the remote Safari dev tools, only without the cross-origin blocking.

So the Macbook test looks good at first sight, but we didn't really manage to switch domains yet, except for the very first main request (the one we type in the address bar, listed first in the developer tools network tab).

Screenshot of a Safari browser with open developer tools in a remote session on BrowserStack

What about the remote iPhone? And where have all the assets and images gone? We could connect a physically present iPhone to a Macbook and use remote debugging, but is there a way to debug a remote iPhone when accessing it via the BrowserStack client?

Yes, we can!

Screenshot of remote iPhone and BrowserStack menu offering developer tools options

Just like the real thing:

Screenshot of remote debugging an iPhone using remote Safari developer tools

Proof of a Redirect

Screenshot: entering the bs-local address in remote iOS Safari address bar

Developer tools have proven that bs-local.com gets redirected to our WordPress base URL which is localhost:

Conclusiong: Configuring WordPress URLs

So it seems, to be able to test our local WordPress site on remote Apple devices, we need to change our default base URL in the WordPress administration settings.

First, we should ensure that the alias also works outside of the BrowserStack UI, by opening http://bs-local.com:8000/ in our browser where we should see our local WordPress site.

To log in to the administration interface, we have to use the current URL again: http://localhost:8000/wp-admin before we change it to bs-local.com in the general settings.

Screenshot of WordPress admin general settings

In WP-Admin, navigate to Settings -> General and change both URLs, "WordPress Address (URL)" and "Site Address (URL)" (or rather the prefix in case you have any custom path here) to http://bs-local.com:8000/.

After saving the settings we will be redirected to log in on the new URL.

Now we can test our local WordPress site properly in any relevant remote device, including Safari on iPhone! And don't forget that the new alias will only work when the local BrowserStack client has been started.

P.S. Update: I added a fallback entry in /etc/hosts to map bs-local.com to localhost 127.0.0.1 and verified that the BrowserStackLocal client still works. But the fallback entry will allow me to connect to localhost as bs-local.com without the client as well, like when working offline without connecting to the BrowserStack server.

Oldest comments (2)

Collapse
 
ingosteinke profile image
Ingo Steinke • Edited

Possibly do more research:

  • Maybe there is a WordPress plugin to allow alternative URLs?
  • ... and shouldn't " localhost URLs will automatically change to bs-local.com" mean that the client / network tunnel software should be in charge to rewrite any localhost url to bs-local on the fly without any project configuration change?

Done more research (and updated the original post later, see postscriptum (P.S.) paragraph:

  • Should I make a fallback entry in /etc/hosts to map bs-local.com to localhost 127.0.0.1 or would that break the BS client?
    • Adding a fallback entry does not seem to harm the client.
Collapse
 
ingosteinke profile image
Ingo Steinke

Note that local testing with BrowserStackLocal is not guaranteed to work in Vivaldi browser which is not officially supported by BrowserStack. If you experience any issue in Vivaldi, try to reproduce the error in Google Chrome before contacting support. I recently saw one error message on a remote iPhone when testing in Vivaldi, and another error message when using Chrome (which is officially supported).