Accessing local dev environment from other devices on network

[Ekeler]

Hi all,

I am using Sage 10.7.0 in a Local by Flywheel environment on MaxOS 14.1.

For responsive dev purposes, I always access the site I am working on using my machine’s local host name (bastiaans-m1-max.local:3000) so I can have auto refresh and style injections work on my laptop and phone at the same time.

I have the following set in bud.config.js:

.setPublicUrl('http://bastiaans-m1-max.local:3000')
.setProxyUrl('http://mysite.local')

I have come to these setting through trial and error, I am really not sure how to define my urls at this point from just the docs. I have been using Sage since v8 and I have always found a way to do this but I’d be curious to see what the recommended way is as this config can be kind of erratic for me.

For instance, when I try and visit “http://bastiaans-m1-max.local:3000/”, I get forwarded to “https://mysite.local/”.
But when I visit “http://bastiaans-m1-max.local:3000/news/”, it work just fine and auto refreshes as expected.

From the console:

 › Proxy  ┄ http://mysite.local/
 › Dev    ┄ http://0.0.0.0:3000/
          ┄ http://192.168.68.81:3000/
          ┄ http://bastiaans-m1-max.local:3000/

Does anyone have any ideas?

Thanks!

[ben]

I’d recommend using @talss89’s bud-localtunnel package which really simplifies the process

[Ekeler]

Hey thanks for the help!

Ok, I have that up and running and it works ok for the home page but secondary pages are forwarding back to local.

So “https://sage.loca.lt/” works but “https://sage.loca.lt/news” links back to “https://mysite.local/news/”

I updated my bud config to:

    .setUrl('http://localhost:3000')
    .setProxyUrl('http://mysite.local')

Going through a remote server also almost feels too complicated? Using the local system has worked well in the past, just not sure why it’s not working for me now…

[talss89]

Hi @Ekeler,

I suspect you’re running into issues with the canonical redirect functionality of WordPress. It looks like you’re being redirected off the HMR server. bud-localtunnel sits on top of the HMR server, so if you’re having redirection issues in vanilla Bud, it won’t fix that.

If you disable canonical redirects via remove_filter('template_redirect','redirect_canonical'); does that make any difference? If so, I’d normalise trailing slashes in your link URLs, rather than disable the redirects in production.

Your configuration from the first post looks correct to me, and I’ve just tested a similar setup on my devices with mDNS - all works:

@Ekeler

.setPublicUrl('http://bastiaans-m1-max.local:3000')
.setProxyUrl('http://mysite.local')

---

@Ekeler

I have come to these setting through trial and error, I am really not sure how to define my urls at this point from just the docs.

I’ve lost countless marbles looking at these set***Url() calls over the last few months. I think others are a bit confused as to what each does too.

Here’s my understanding of each one, based on casual tests and working with the Bud.js source. @kellymears - sorry to drag you in, but please could you validate this?

---

Overview

Bud’s HMR server will listen on a port, and serve HMR assets. If a request is made for a non-HMR asset, it will pass requests upstream to a server. When the response comes back, if the content type is HTML, the proxy server will search and replace URLs in the response body to keep assets pointed at the HMR server.

The HMR server does not appear to perform search and replace on HTTP headers, meaning upstream redirects will not be modified. Perhaps we could improve this.

Setting URLs for the HMR server

setUrl()- Sets the interface and port on which Bud will listen for HMR requests. Internally, Bud will try to resolve any hostnames specified here, and open a socket on the interface that matches the resolved IP. It will default to http://0.0.0.0:3000, which will open tcp/3000 on all local interfaces.

setProxyUrl() - Set the upstream URL which Bud’s HMR server will pass through non-HMR requests to. This should be accessible from wherever Bud is running. For Sage, this should be your WordPress server.

setPublicProxyUrl() - Set the search string in the upstream search and replace. The HMR server will look for this URL in the upstream response body, and replace it. By default, it will be set to the setProxyUrl() value.

setPublicUrl() - Sets the URL that will replace the setPublicProxyUrl() string. By default, this will be set to the setUrl() value.

[Ekeler]

Thanks for the extensive response @talss89 !

I tried removing the redirect_canonical filter but it didn’t seem to have any effect. I can also now note that even just using:

.setUrl('http://localhost:3000')

has its issues sometimes, on the current site I’m working on, http://localhost:3000/ and http://localhost:3000/properties/sample-property/ work fine but http://localhost:3000/discussions/ forwards to http://mysite.local/discussions/

I’m having a hard time figuring out if it’s Sage, Chrome, MacOS or Flywheel Local that’s causing the issue and it just seems very inconsistent, making me think it’s somehow caching or DNS related? I’m really just guessing at this point…

EDIT:
Hmm ok so you mentioning trailing slashes got me thinking and it seems that http://localhost:3000/discussions/ work fine but http://localhost:3000/discussions (without the trailing slash) forwards to http://mysite.local/discussions/. I don’t really understand why that is the case but this may help me along in the future…

[talss89]

No problem at all.

Can you capture the request that triggers the redirect in inspector? You may be able to see an X-Redirect-By response header, which should tell you which component is redirecting.

For example, in my current project, WordPress’ canonical redirect is adding the slash: