[DOCS] Correct reason for request independence in BaseVariants conditions

[CybotTM]

What & why

Follow-up to #5670 by @garvinhicking — this branch is based on his commits, so his (and @brotkrueml's co-authored) work is preserved in the history.

The documentation for base variant conditions currently claims that all functions from DefaultFunctionsProvider are available. Request-dependent functions such as ip() are not available there and fail with:

#1686745105 RuntimeException
Using expression language function "ip(devIp)" in a context without request.

(reported in forge #106696).

Root cause (verified in core)

Base variant conditions are evaluated in Site::resolveBaseWithVariants(), which builds the expression language resolver for the site context without a request variable:

// typo3/sysext/core/Classes/Site/Entity/Site.php
$expressionLanguageResolver = GeneralUtility::makeInstance(Resolver::class, 'site', []);

DefaultProvider only supplies applicationContext, typo3, date and features — there is no request, so ip() (which requires a RequestWrapper) throws. This happens when the Site object is built — not because of caching, which an earlier revision of #5670 stated (thanks @froemken for the correction).

What this changes on top of #5670

• Replace the incorrect "due to caching reasons" explanation with the real cause (no request in the site expression language context).
• Show the actual exception (#1686745105) so the page is found when searching for the error message.
• Link the class via :php-short: instead of a raw :t3src: file link (as requested by @linawolf / @franzholz in the review of [DOCS] Document request independence for BaseVariants conditions #5670).
• Reword the intro of the available-functions list ("Some examples:" → "The following request-independent functions are available:").
• The ip and request-based traverse examples stay removed (as in [DOCS] Document request independence for BaseVariants conditions #5670).

Rendered before / after

Before (current main)	After (this PR)

_{Click a thumbnail to open the full-resolution render.}

Decision required

Before merging, please decide whether this should be documented (this PR) or fixed in the core instead: there is an unresolved discussion in #5670 whether the site expression language context should receive a RequestWrapper (@froemken's proposal), which would make ip() usable again. As of core main the limitation still exists, so this PR documents the current behaviour — if the core starts passing the request, this section should be reverted.

Checklist

• Renders without warnings — render-guides … --fail-on-log exits 0
• Authorship of [DOCS] Document request independence for BaseVariants conditions #5670 preserved (commits by @garvinhicking, co-author @brotkrueml)

[garvinhicking]

Thanks! I believe the proper place to discuss this would be in either a forge issue, gerrit patch - or maybe even a slack discussion in coredev.

My personal feeling is that we should make the SiteEntity request-aware. This is helpful, but it should not rely on the to-be-phased-out TYPO3_REQUEST. The whole entity does too much and is not a good value object. So that would require thought, discussion and architecture decisions.

Shortterm fix would be a "withRequest" or "setRequest" method here and pass it down the chain.

Having said that, I think documenting the shortcoming for now to "fix" a wrong statement sounds helpful to me. We can always adapt the docs afterwards if the bug gets fixed. Which might even be v15 only due to involved changes.

[garvinhicking]

I think this should not be removed! Itcan't check at but isn't "request" actually handed in?

At the least we need to keep "traverse" but with a different array?!

[CybotTM]

I assume you are not talking about Line 157 alone!?

[CybotTM]

ah, got it, line 157 ff checking, seems like a mistake

[CybotTM]

@garvinhicking AFAIU your removal of this is satisfied, as it is not possible to provide a working example, which would be the whole point of listing it here, isn't it? (request is not handed into the base-variant context in current core, that's exactly this issue; traverse() itself is request-independent, but there's no array variable available to demonstrate it with.)

[CybotTM]

Thanks! I believe the proper place to discuss this would be in either a forge issue, gerrit patch - or maybe even a slack discussion in coredev.

My personal feeling is that we should make the SiteEntity request-aware. This is helpful, but it should not rely on the to-be-phased-out TYPO3_REQUEST. The whole entity does too much and is not a good value object. So that would require thought, discussion and architecture decisions.

Shortterm fix would be a "withRequest" or "setRequest" method here and pass it down the chain.

Having said that, I think documenting the shortcoming for now to "fix" a wrong statement sounds helpful to me. We can always adapt the docs afterwards if the bug gets fixed. Which might even be v15 only due to involved changes.

For this discussion I started investigating in CybotTM/typo3#2 and CybotTM/typo3#3.

this would be in either a forge issue, gerrit patch

Maybe later. In any case, I won't open either of them until I'm sure, although you're certainly welcome to. Personally, I avoid the tools you mentioned as much as possible because they put too much mental strain on me for various reasons. Too many hurdles.

(And the core team seems well aware of it as it seems to even utilize it as barrier: "Yes, PRs in ttps://github.com/TYPO3/typo3 have been disabled at the beginning of June, because we had issues with people publicly disclosing security issues. riccardodecontardi For the moment, you need to go through the default core contribution workflow (via Gerrit).")