Localhost:3000 is redirected if slash is missing at the end of the URL

Hi everyone,

When a slash is missing at the end of my URL, localhost:3000 is redirected to proxy URL. I have this issue with Sage 10.3.1, Bud 6.4.5 & Bud 6.5.4.
Ex. : http://localhost:3000/test redirects to http://mywebsite.localhost/test/

I’ve already opened an issue about this: the problem seems to have been solved for a while, but it seems to come back since a few releases. As suggested in comment I tested this with different vhost configurations (MAMP Pro, custom nginx config, Lando), but the problem still seems to be there.

Before reopening a new issue I would like to know if this problem is present for some of you.

Thank you!

1 Like

I am also seeing this. For example if I try to logout via http://localhost:3000/wp-login.php?action=logout&_wpnonce=8baa561e43 it just doesn’t work. It redirects to http://proxied-url.dv/wp-login.php?loggedout=true&wp_lang=en_GB and I remain logged in on localhost:3000

Or if I attempt to log in at http://localhost:3000/wp-admin/ it redirects to http://proxied-url.dv/wp-login.php?redirect_to=http%3A%2F%2Fproxied-url.dv%2Fwp-admin%2F&reauth=1

The only way to log out is to manually clear cookies which obviously isn’t ideal. And I have to manually adjust the login URL which is a pain.

This has only been an issue since the arrival of Bud.

I can’t reproduce this - try from an incognito window or different browser.

/wp-admin/ is going to redirect you if you aren’t already logged in. Try to login from http://localhost:3000/wp-login.php (or for Bedrock folks, http://localhost:3000/wp/wp-login.php)

Having issues? Try from an incognito window or different browser.

1 Like

Thanks @ben.

Navigating directly to wp-login.php solves that issue, although I didn’t have this issue on previous versions of Sage - it would load http://localhost:3000/wp-login.php after the redirect from wp-admin, not the proxied URL.

I am able to reproduce the logout issue in an incognito window using Brave browser. Attempts to log out still redirect to the proxied URL and fail to log me out on localhost:3000

I tried Firefox and Safari but the same thing is happening.

Bud config is:

     * Proxy origin (`WP_HOME`)

     * Development origin

where proxied-url.dv is configured in MAMP, pointing to the root WordPress directory.

I’m not using Bedrock for this one.

Redirects from localhost:3000 to the proxied URL (triggering a login window) are also happening:

  1. On activating or deactivating a plugin
  2. On flushing the permalink cache

Also can’t log out - it redirects to the proxied URL login screen and I remain logged in on localhost.

It’s really annoying. Never used to happen on previous versions of Sage.

Are you saying that from the dev session in the wp-admin that’s happening? Is there a reason why you’re using your dev session in the wp-admin like that instead of visiting the site directly without the dev proxy?

I like to use the dev proxy localhost:3000 for the whole work session only because it makes sense - if I’m rebuilding styles in the new world where editor.css is supplied to admin, then if I access wp-admin without the proxied URL, the styles just aren’t there. Also it’s just really impractical. If I’m on a page and click to “Edit Page” then the URL is naturally a localhost:3000 URL.

All I can do is explain via an example with a slightly older project built with Sage 10 before Bud serving the proxied URL on localhost:3000.

After running npm run start, if I visit http://localhost:3000/wp-admin/, it redirects to http://localhost:3000/wp/wp-login.php NOT the proxied URL login screen.

Then I log in and it redirects to http://localhost:3000/wp/wp-admin/ - no problem. If I activate a plugin, deactivate a plugin, clear permalinks cache, there is no issue - it always stays in localhost. The only time it doesn’t is after updating a page or post… the “View Page” link shows the proxied URL.

I can also log out and I return to the login screen, still on http://localhost:3000

Now with Bud… where my proxied URL is proxied-url.dv

After running yarn dev, if I visit http://localhost:3000/wp-admin/, it redirects to http://proxied-url.dv/wp-login.php.

So I navigate directly to http://localhost:3000/wp-login.php and can log in this way.

It redirects to http://localhost:3000/wp-admin/ - no problem. I can perform most actions (edit pages / posts / options) while remaining in localhost.

If I activate a plugin, deactivate a plugin, clear permalinks cache, I get logged out and returned to the proxied URL login screen- it never stays in localhost. The only time it doesn’t is after updating a page or post… the “View Page” link shows the proxied URL.

I also cannot log out - it never works. Always redirects to the proxied URL and fails to log me out.

1 Like

Thank you for the additional details! I’ll check with @kellymears and do some testing on my own to see if we can maybe ship some additional defaults to the Bud proxy to prevent being redirected away from the dev session

Just downloaded the latest main copy of sage and am having the same issue as well. The dev link ‘localhost’ instantly redirects to the proxy link so getting no auto refresh, injected styles etc.


I don’t think this is the same issue from what you’ve described but I could be wrong - that sounds like a misconfigured Bud config

Opened a request here: Investigate improving proxy settings out of the box to account for redirects · Issue #1887 · roots/bud · GitHub

h/t @kellymears but I haven’t yet tested:


Ref bud/index.ts at 6abb30213a0a1a6bad4825ca8cf024c84c690d16 · roots/bud · GitHub

You are not actually signed out of WordPress when you click Disable or Enable on the plugins dashboard. The plugin is disabled and then you are routed to the login page on the actual site URL. If you click the browser’s back button you’ll find that you’re still logged in to the WordPress admin. You could sidestep this issue entirely by just right clicking the link and opening it in a new tab; your user session is not lost when you do this. I have a hard time seeing this as being a big deal (unless you’re working on a script that runs on the plugin management page specifically!)

I don’t have the same problem as you do with the post preview buttons.

Why does it not work like I think it will?

The bud.js proxy server is not browsersync and it doesn’t want to be browsersync. I don’t have any plans on making it act more like browsersync than it currently does. There are different advantages and disadvantages to each approach. The bud.js development server prioritizes speed and state over the browser-sync approach of reloading the page on every change. It isn’t broken, it’s just different.

Edge cases like internal redirections are always going to be handled more consistently with browsersync than the bud.js dev server. On the other hand, the bud.js dev server is faster and better at preserving browser state when modules are updated. If you’re working on a multi-part form, for example, you’ll almost definitely want to use the bud.js dev server over browsersync.

That all said, here are three relatively easy ways to get closer to the behavior you seem to expect:

1. Use browsersync

You can use browsersync to handle reloading and proxying if you are happy with the way it works.

import plugin from 'browser-sync-webpack-plugin'

export default async bud => {
  bud.use(new plugin({/* config */}))

Do not call bud.proxy when using the plugin.

2. Add this mu-plugins drop-in

I don’t currently have any plans on formally supporting this code and I doubt it is perfect, but if anyone has any suggestions after trying it then feel free to add to the thread.

If you want to take this and run with it I’ll do what I can to help promote your work.


namespace Roots\Bud;

use function Roots\add_filters;

$skip = fn () => $_SERVER['HTTP_X_BUD_ORIGIN'] === home_url();
$encode = fn ($url) => urlencode($url);
$filter = fn ($urls) => fn ($url) => $skip() ? $url : str_replace($urls[0], $urls[1], $url);

if (array_key_exists('HTTP_X_BUD_ORIGIN', $_SERVER)) {  
  $urls = [home_url(), $_SERVER['HTTP_X_BUD_ORIGIN']];

  add_filters(['rest_url', 'admin_url', 'login_url', 'includes_url'], $filter($urls));
  add_filters(['login_redirect', 'logout_redirect'], $filter(array_map($encode, $urls)));

3. Set WP_HOME to http://localhost:3005

If you want to do general management of WordPress using the dashboard over the bud development server this is probably the best possible way to do it.


@kellymears Thanks so much for posting this. I’m not sure why I didn’t see it when you wrote it, but only when I returned to see if there had been any developments on this thread today.

I’ll take the mu-plugin for a spin and see how it goes.

Thanks again.