Zauberfisch

ok, as a workaround I created `/usr/local/bin/i3-restart` ```bash #!/bin/bash i3-msg restart ps aux | grep '[l]ibi3workspaces' | awk '{print $2}' | xargs -n 1 kill ```

cool, I'll PR against 3.6 with a non breaking change. For 4, will it be merged upwards or should I make a 2nd PR?

you do realize that right now it's always 301? Yes, I want 302, but right now it's hardcoded 301.

nope: https://github.com/silverstripe/silverstripe-cms/blob/6fb1012eb803e75996733e43e650fc5caa4f1aba/code/Model/RedirectorPageController.php#L20 Speaking about it, I wouldn't be opposed to make it a 302. Because I often get the problem that clients change a redirector page and then think the...

uh, not considered an API change? lovely. The more I think about it, there more I feel like it should be 302. From a users perspective it's very counter intuitive...

so, sounds like we are agreeing on switching to 302 and adding a `onBeforeRedirectHook` so developers can change behavior if needed. But, while changing to 302 is not really breaking...

I'd be happy to do PRs for 3 and 4. But I'd like to have the nuances figured out first though

As long as it's extendable, I'm fine either way. But if we make 301 the default, I would also strongly tend towards adding a warning. But I feel more and...

ok, that sounds like a reasonable solution. I'll be happy to implement this. What branch will we merge this into?

Additionally, I'd like to raise the following question: should `Controller->redirect('/foo', 301)` also have a `Cache-Control` header with an expiry date?