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
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.
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).
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!
Just like the real thing:
Proof of a Redirect
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.
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.
Top comments (2)
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).Possibly do more research:
Done more research (and updated the original post later, see postscriptum (P.S.) paragraph:
/etc/hosts
to mapbs-local.com
to localhost127.0.0.1
or would that break the BS client?