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

**URL:** https://discourse.roots.io/t/localhost-3000-is-redirected-if-slash-is-missing-at-the-end-of-the-url/24144
**Category:** bud
**Tags:** webpack, sage10
**Created:** 2022-10-28T01:04:09Z
**Posts:** 14

## Post 1 by @Striffly — 2022-10-28T01:04:09Z

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](https://github.com/roots/bud/issues/1210) 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!

---

## Post 2 by @raffjones — 2022-11-09T11:41:54Z

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.

---

## Post 3 by @ben — 2022-11-09T14:29:41Z

> [@raffjones](#):
>
> 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.

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

> [@raffjones](#):
>
> 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`

`/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.

---

## Post 4 by @raffjones — 2022-11-09T14:59:00Z

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`)
     */
    .proxy("http://proxied-url.dv")

    /**
     * Development origin
     */
    .serve("http://localhost:3000")
```

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

I’m not using Bedrock for this one.

---

## Post 5 by @raffjones — 2022-11-15T11:32:07Z

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.

---

## Post 6 by @ben — 2022-11-15T16:39:29Z

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?

---

## Post 7 by @raffjones — 2022-11-15T17:17:41Z

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.

---

## Post 8 by @ben — 2022-11-15T17:24:21Z

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

---

## Post 9 by @Jake_Dickinson — 2022-11-16T15:34:24Z

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.

J

---

## Post 10 by @ben — 2022-11-16T15:35:38Z

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

---

## Post 11 by @ben — 2022-11-18T15:46:27Z

> [@ben](#):
>
> 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

Opened a request here: [Investigate improving proxy settings out of the box to account for redirects · Issue #1887 · roots/bud · GitHub](https://github.com/roots/bud/issues/1887)

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

```
app.hooks.filter(
  `dev.middleware.proxy.options.followRedirects`,
  true
)
```

Ref [https://github.com/roots/bud/blob/6abb30213a0a1a6bad4825ca8cf024c84c690d16/sources/@roots/bud-server/src/middleware/proxy/index.ts#L19-L109](https://github.com/roots/bud/blob/6abb30213a0a1a6bad4825ca8cf024c84c690d16/sources/@roots/bud-server/src/middleware/proxy/index.ts#L19-L109)

---

## Post 12 by @kellymears — 2022-11-30T01:52:46Z

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](https://bud.js.org/docs/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.

```
<?php

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.

---

## Post 13 by @raffjones — 2023-01-26T12:49:26Z

@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.

---

## Post 14 by @joshb — 2024-04-03T17:39:37Z

Not sure if I should have opened a new topic of just put this here.

Running latest versions of everything, when I attempt to access my .setUrl `localhost:9898`, it redirects me to my .setProxyUrl `https://newproject.test` thus not allowing me to see changes made on save…

It doesn’t matter if I have a trailing slash or not.