Installed Sage 10 and Acorn.
The site loads no problem, including http://0.0.0.0:3000/wp-login.php
But I can’t log in - the page just reloads. Cleared cookies, preferences, tried incognito window. Nothing works.
If I use http://sage10.dv/ which is the URL which Bud is proxying, it’s fine.
I’ve not had this problem on previous versions of Sage.
Am I missing something? Thanks in advance for any pointers
Sounds like it could be a redirection issue caused by an incorrectly configured site URL. Although if the site is otherwise loading fine, then this may not be the problem.
Check your wp-config.php file. What is configured for the following:
define( 'WP_HOME', '...' );
define( 'WP_SITEURL', '...' );
Thanks for the reply, @roygbyte.
There was nothing defined for either of those, but adding them and clearing cookies makes no difference.
I’ve never had to have those defined in previous versions of Sage.
Now they are:
define( 'WP_HOME', 'http://sage10.dv' );
define( 'WP_SITEURL', 'http://sage10.dv' );
but the issue persists.
My mistake–I see now I misread your original post and thought “reloads” was “redirects”.
Can you provide any more clues about your situation? Do you have error logging enabled? What does the Roots logfile look like?
I have WP_DEBUG enabled and error_reporting(E_ALL) but there are not errors. I’m not sure what you mean by “Roots logfile” since I don’t know where that is, or indeed how to enable writing to it.
There are no errors visible on the page, and no exceptions thrown.
I’ve been using Sage for years, and this is the first time I’ve had this problem. Also first time using Bud… probably not conincidental.
It’s got to be something about cookies not being accepted or a cookie crossdomain conflict but with no error shown it’s impossible to work out 
By logfile, I mean what’s found under storage/logs/application-*.log.
In any case, it does sound like cookies. To be sure, can you login through http://sage10.dv/wp-login.php? The only trouble you’re having is with http://0.0.0.0/wp-login.php?
Oh, sorry - those logs… there’s nothing there at all.
You are correct in saying I can log in at http://sage10.dv/wp-login.php with no issues. Strange… like I say I’ve never had an issue with Sage localhost:3000 before. I did try changing the serve URL in bud.config.js to that but it made no difference.
My guess is that it’s not a Sage issue, but a networking issue. In this regard, I unfortunately can’t offer much help. But it seems to me the issue has something to do with 0.0.0.0 as an address, and so you might want to look into the configuration of your server (Apache? Caddy?) or your computer’s internal addressing (Linux’s /etc/hosts file could be relevant).
Just for kicks, you might try setting:
define( 'WP_HOME', 'http://0.0.0.0' );
define( 'WP_SITEURL', 'http://0.0.0.0' );
Thanks, but that had no effect - it should’t really since it’s the proxy URL that should be used for WP_HOME etc. as far as I know.
I am seeing an error that others have reported but I’m not sure that’s relevant to this case.
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
there are 2 occurrences for every login attempt.
What happens if you attempt to login at http://0.0.0.0:3000/wp-login.php when Bud isn’t running?
I get the expected page:
This site can’t be reached
0.0.0.0 refused to connect.
I think there’s an http-proxy-middleware issue that’s related to this issue. I’m a bit out of my league here, so I’m going to have to step out of this issue for now…
Appreciate you trying to help anyway - thanks a lot. I’ve reverted to an older version of Sage that (ahem) works 
Yes, I’m still using the beta version of 10 myself. I did try out the current master branch in an attempt to sort out your issue.
Curious to know: is there a reason you want/need to use 0.0.0.0 to visit the site instead of using the proxy address? Even in the beta version of 10, I use the proxy address to develop. I’m asking in case I’m doing something wrong XD
I don’t use it because doesn’t hot reload when you make changes, which is the main benefit of using this kind of browsersync method. If you aren’t using that technique you should definitely get on to it as it really speeds up the workflow.