Hi @djbuch,
your solution has a few issues, do you think you can fix them?
I'm asking because I wanted to test it and see if we can include it directly in the 9.0.x branch.

[Edit]
I ran a test - if you restore the $router parameter to what it was before, meaning you declare it as Symfony\Component\Routing\RouterInterface, the issue should be resolved and your solution should work.

Hello, I made the change you said, let's wait and see the check results.

[Edit]
But I think we will have a problem since RouterInterface doesn't define matchRequest but this is the core change needed in this bug fix

Hello, I made the change you said, let's wait and see the check results.

[Edit] But I think we will have a problem since RouterInterface doesn't define matchRequest but this is the core change needed in this bug fix

Okay, even though I tested it quickly locally and it works, let's wait for the tests to be sure/safe

Yes the PHPStan tests failed

Error: Call to an undefined method Symfony\Component\Routing\RouterInterface::matchRequest().

Line src/PrestaShopBundle/EventListener/Admin/Context/ShopContextSubscriber.php

365 Call to an undefined method
Symfony\Component\Routing\RouterInterface::matchRequest().

@djbuch
Okay, sorry 🙏, you're right, that's clear.

You could try it this way:
Reset the type of the $router parameter to Symfony\Component\Routing\Router
and then here

  PrestaShopBundle\EventListener\Admin\Context\ShopContextSubscriber:
    autowire: true
    autoconfigure: true
    arguments:
      $router: '@router'

Let's check if it doesn't throw an error anymore, and then we'll ask the others for confirmation too.

Hello

I checked the problem, and the code below helped:

$controller = $request->attributes->get('_controller');
if (!$controller || !str_contains($controller, '::')) {
    return null;
}

Could you guys check?

@kpodemski where should this code go ?

@djbuch

I haven't tested other bugs that were reported by @Codencode, I've only tested sending emails :)

If that works, then it also requires removing RouterInterface and adapting tests if needed

But the problem here is in the matching of the route. Because of "request.isXmlHttpRequest()" in the route definition.

@djbuch I'm not sure about that, to me the problem was a mismatch in the route. After applying the changes I don't have any errors mentioned by @Codencode

@djbuch

I haven't tested other bugs that were reported by @Codencode, I've only tested sending emails :)

If that works, then it also requires removing RouterInterface and adapting tests if needed

@kpodemski this solution works, I tested it for the cases that were causing issues and it's ok.
@djbuch it's also less impactful, I would take it into consideration!

@kpodemski yes but the missmatch is because of request.isXmlHttpRequest(), with your code we just don't get the ShopContext from the route.

But the route exists, it is defined so it should be found. You can see that if you remove the condition request.isXmlHttpRequest() on the route definition the original code works, but this is the problem if we want the condition ton work we need to pass all the request to the match, not only a mocked request as it is done with ->match($request->getPathInfo())

[EDIT] : Did you try it in multishop context ?

@djbuch

[EDIT] : Did you try it in multishop context ?

Of course, it worked for me w/o multistore enabled. It didn't after enabling multi-store, it showed me that the URL doesn't exist.

OK and are you shure that with your code the good shop context is loaded ?

@djbuch checking

@djbuch I'm testing sending emails, I've set a different data in the single and all stores context, I managed to correctly receive the email for the corresponding inboxes

And what if you don't send this through XmlHttpRequest ? Because the whole this is about this condition in route definition.

If it is not needed for security reasons, then we could remove it from the conditions.

And what if you don't send this through XmlHttpRequest ? Because the whole this is about this condition in route definition.

If it is not needed for security reasons, then we could remove it from the conditions.

If we remove it from the route definition, we then have to add the check in the controller method. This was the solution I thought of, which you can find here: #39991

Yes but with my solution the condition works

@Codencode it is always false because ->match($request->getPathInfo()) will recreate a mocked request with the info about XmlHttpRequest missing, but with ->matchRequest($request) it works

Yes but with my solution the condition works

Ah ok, I didn't realize it was in addition to your solution.

@djbuch @Codencode

ok, thanks for the info

let's ping @jolelievre to see his opinion as well, not relying on the interface is not a clean way, but on the other hand, creating an adapter like some RouterMatcher is probably too much

@djbuch

Well, I've checked, and route conditions in rhe route listener are checked before our subscriber, so when I do the POST directly, it shows me:

No route found for "POST http://prestashop9.test/admin-dev/index.php/configure/advanced/emails/send-testing-email" (from "http://prestashop9.test/admin-dev/index.php/configure/advanced/emails/

When I remove the condition:
{"errors":[]}

It returns me JSON response :)

@kpodemski @djbuch

since the PR was stuck on rebase for a while, I went ahead and did it myself.

@kpodemski @jolelievre I ran the test and the PR works correctly.

We're now waiting for the UI tests that were created from scratch because I performed the rebase, and obviously the second approval is still missing.

c/c @SiraDIOP

UI TEST are green 🟢 https://github.com/Codencode/ga.tests.ui.pr/actions/runs/26416354197

thank you @djbuch @Codencode