!!! TASK: Use configured baseUri in form action

[simstern]

$actionRequest->getHttpRequest()->getUri() returns the original request Uri, which conflicts if the Setting Neos.Flow.http.baseUri is overwritten.

TBH: I'm not sure if this is really the best way to replace the base uri, so I'm happy for any feedback.

Closes #22

[albe]

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

[bwaidelich]

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();

[simstern]

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.

[albe]

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

[albe]

Looks good apart from the one comment

[bwaidelich]

I took the freedom to make some (mostly cosmetic) tweaks.
Tested and merge this for the next major release. Thanks!!

[bwaidelich]

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

[bwaidelich]

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

[simstern]

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)