IBX-6312: Fixed ParentContentType View Matcher for not available parent

[vidarl]

Question	Answer
JIRA issue	IBX-6312
Type	bug
Target Ibexa version	v3.3
BC breaks	yes

This is a rebase of ezsystems/ezplatform-kernel#383 made for 3.3. But 3.3 is now out-of-maintenance

Description:

When matcher is checking parent's contenttype, it might throw NotFoundException if the parent is not available ( for instance if it is not available in any languages configured in the current siteaccess). I don't think the matcher should throw an exception in this case, just simply return false.
In dev, this NotFoundException will be shown to the user, while this will be handled by Ibexa\Bundle\Core\EventListener\ExceptionListener and a non-explaining 500 will be shown:

The change have no functional change on the front-end site access. User will anyway be given a 404 ( but the NotFound exception is no longer originating from the matcher). However, in admin-ui there is a big difference. A Landing page is not editable in admin-ui without the fix because the preview will be rendered with the front-end siteaccess scope and the matcher will then throw the exception

With this fix, user will see this in prod:

In dev, the preview controller will throw a BadState exception and look like this:

For QA:

See instructions in ticket for how to reproduce

Documentation:

No doc needed

[Steveb-p]

Nitpick: Ideally, logger calls should be checked (via Mock expectations). Missing log information would be an issue for a developer.

[vidarl]

@Steveb-p : Added test in e3a7e61

[tomaszszopinski]

QA approved on IbexaDXP 4.6 commerce.

[tomaszszopinski]

🟢 ibexa/experience#509

[alongosz]

This is an issue that needs to be resolved, not added to the baseline, please.

[vidarl]

@alongosz : Adam said I could solve it this way : #438 (comment)

How to do you want it fixed then ?

[alongosz]

@vidarl ok, but then see #438 (comment) about how to handle expected "unresolvable" issues. Baseline is sort of "todo" list. On main we could tackle it with ?-> operator. Here we would need to use if or ||, so that might become unreadable indeed.

btw. for that reason I'm not a huge fan of traits, especially that one coming from PSR. They're meant to be very flexible which leads to such trivial issues.

But the solution could be as Steve described in the mentioned comment.

[vidarl]

Actually, I had missed @Steveb-p comment in #438 (comment)

Moved error to phpstan.neon.dist in ad68fc7
Better ?

[alongosz]

Moved error to phpstan.neon.dist in ad68fc7 Better ?

Almost 🙃
See: #438 (review)

[vidarl]

@alongosz and now? ref 025414d

[adamwojs]

@vidarl Could you please rebase PR? CI has been fixed on base branch.

[alongosz]

@vidarl Please notice the exact format of the mentioned example: https://github.com/ibexa/product-catalog/blob/main/phpstan.neon.dist#L18
For generic not resolvable issues we skip count and path in phpstan.neon.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud