When a Custom SiteAccess\Matcher is implemented (ex: a modified version of eZ\Publish\Core\MVC\Symfony\SiteAccess\Matcher\URIElement)
eZ's bundled event listener eZ\Bundle\EzPublishCoreBundle\EventListener\SiteAccessListener#onSiteAccessMatch
does not give a chance to rewrite the "semanticPathinfo" using $siteaccess->matcher->analyseURI() since $siteaccess->matcher is null.
This leads to problems like 404 with media urls, ex: pathinfo=/fr/media/123 will keep the same "semanticPathinfo".
How come $siteaccess->matcher is null in that context, is that a normal behavior?
I'm asking since when using a core SiteAccess\Matcher, like eZ\Publish\Core\MVC\Symfony\SiteAccess\Matcher\Map\URI,
"semanticPathinfo" is indeed reworked by analyseURI(), i.e. semanticPathinfo becomes /media/123 when pathinfo=/fr/media/123
Matcher\URIElement had a bug that did not allow elementNumber to be higher than 1. Despite being fixed on jan 27 2017 by https://jira.ez.no/browse/EZP-25337,
it seems the behavior is still not as described by
(ex: fr/something will become fr/something/something).
Also we cannot use Regex\URI who got deprecated since it is not reversible.