-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange behavior with request path extensions #94
Comments
Thank you for your solution. I'm interested in the PR. |
You can place them wherever you want, as long as the namespace fits accordingly. For my example from above:
|
Great, thanks! Here’s what I had done initially: However, I was encountering the following error:
I thought the issue was due to the incorrect placement of my code, but your message prompted me to investigate further. I ended up resolving it by aliasing the service and modifying the constructor of the provider as follows: public function __construct(
private Inner $inner,
#[Autowire(service: 'sulu.repository.redirect_route')]
private RedirectRouteRepositoryInterface $redirectRouteRepository,
) {
} Now the error is gone, and I can start testing the redirections. Thanks again for your quick response! |
Actual Behavior
The redirects do not work as expected if the source or target has an extension.
The current behavior works great for internal redirects that follow Sulu's pattern. But for external redirects or internal redirects that are taken over from a legacy system, the current behavior quickly fails.
Possible Solution
The following workaround works for us. We have overwritten most of the RedirectRouteProvider and the WebsiteRedirectController. I am also happy to create a pull request once the target behavior has been agreed.
The text was updated successfully, but these errors were encountered: