IBX-6504: Gracefully handled URL generation in RoutingExtension

[barw4]

Question	Answer
JIRA issue	IBX-6504
Type	improvement
Target Ibexa version	v3.3
BC breaks	no

Related PR: https://github.com/ezsystems/ezplatform-page-fieldtype/pull/251

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review (ping @ezsystems/engineering-team).

[micszo]

Fix works when LP preview is empty (no block or no base lang). Otherwise exception persists but template changes (ezplatform-kernel/eZ/Bundle/EzPublishCoreBundle/Resources/views/pagelayout.html.twig -> ezplatform-page-fieldtype/src/bundle/Resources/views/default_layout.html.twig).

[barw4]

@alongosz @konradoboza @Steveb-p @kisztof as @micszo noticed with the certain case the preview still wasn't able to be loaded. This is due to block rendering in a new language and loading old values if we are basing a new translation on an old translation. https://github.com/ezsystems/ezplatform-page-fieldtype/pull/251 + 124723a should handle this case

[micszo]

This unblocked the mentioned flow. 🙂

[alongosz]

@barw4 so if page is translated into many languages that would hit performance badly as all 30 translations would be loaded. I'm not sure if there's API issue here or we use it incorrectly, but that doesn't feel like a good direction performance wise. Not sure what to suggest without looking deeper into this. What is exactly the error there and what and where we're trying to load that we shouldn't?

cc @ezsystems/php-dev-team

[barw4]

@alongosz we have multiple calls like this (with Language::ALL) throughout the whole codebase so I'm a bit surprised this has become a problem of performance just now. Especially, if this will only in reality affect PB's previews. In the same request, we are having the exact same calls from other packages as well (for example https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FieldType/Page/ParameterProvider.php#L116).

To answer your question, this is basically the same case and comes down to loading Location, but now this is caused by blocks rendering https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/bundle/Resources/views/default_layout.html.twig#L8, specifically https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FragmentRenderer/BlockRenderOptionsFragmentRenderer.php#L121 and later https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FragmentRenderer/BlockRenderOptionsFragmentRenderer.php#L148. Situation is pretty much similar as ez_path - we cannot load Location in given Site Access when alwaysAvailable flag is false without an error.

[alongosz]

@alongosz we have multiple calls like this (with Language::ALL) throughout the whole codebase so I'm a bit surprised this has become a problem of performance just now. Especially, if this will only in reality affect PB's previews. In the same request, we are having the exact same calls from other packages as well (for example https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FieldType/Page/ParameterProvider.php#L116).

To answer your question, this is basically the same case and comes down to loading Location, but now this is caused by blocks rendering https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/bundle/Resources/views/default_layout.html.twig#L8, specifically https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FragmentRenderer/BlockRenderOptionsFragmentRenderer.php#L121 and later https://github.com/ezsystems/ezplatform-page-fieldtype/blob/2.3/src/lib/FragmentRenderer/BlockRenderOptionsFragmentRenderer.php#L148. Situation is pretty much similar as ez_path - we cannot load Location in given Site Access when alwaysAvailable flag is false without an error.

I'm not fully convinced by "we're already doing it like that" argument, however maybe it's fine for now if @micszo tries to benchmark it a bit with e.g. content item with 30 translations? AFAIR test-fixtures already contain a lot of languages, creating such content might be a bit time consuming, so maybe some sort of command to loop over languages and create translations? ;)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[micszo]

however maybe it's fine for now if @micszo tries to benchmark it a bit with e.g. content item with 30 translations?

Tested the flow by adding 30 translations to a Landing page with simple non-empty preview. Did not observe any significant increase in time when editing, previewing or publishing.

[micszo]

QA Approved on Ibexa Commerce 3.3.36-dev.