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