We're pretty much in the process of elaborating the purposes and best approach towards baseUri.
We will most likely remove the ATTRIBUTE_BASE_URI solution (which replaced previous getBaseUri() method) on the HTTP request.
See also neos/flow-development-collection#1755

/cc @bwaidelich @kitsunet

We will most likely remove the ATTRIBUTE_BASE_URI solution

Right, Christian is on it with neos/flow-development-collection#1755

Most likely the result will look like this:

$uri = $this->baseUriProvider-> getConfiguredBaseUriOrFallbackToCurrentBaseUri();

Thanks for the feedback! Christian explained me the changes regarding the baseUri this morning in the Slack channel already. I'm happy to adapt it once they are released :)

I just had to get it work for the current version anyway and therefore this PR is still done the old way for the moment.

Ok, so as of https://github.com/neos/flow-development-collection/pull/1755/files the final solution is indeed $uri = $this->baseUriProvider-> getConfiguredBaseUriOrFallbackToCurrentBaseUri(); with an injected instance of Neos\Flow\Http\BaseUriProvider as Bastian mentioned already

@simstern unfortunately this breaks unit tests still and I don't have edit access to your PR

It is a good measure to allow this when creating PRs for upstream Repos:

FYI: We are thinking of getting rid of the notion of a global baseUri configuration (see neos/flow-development-collection#2157) and started to work on this again. So maybe it makes sense to wait for the direction this is taking before merging this one

Thanks for your info and help on this. Makes sense to wait then.

I tried to give you edit access, but it seems I cannot change this anymore (even though, it's documented here how to do it https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)