Consent modal is displayed every time locally

[brotkrueml]

When rendering a manual locally, for example TSconfig reference, every time I click on a menu the consent modal is displayed:

Personally I think, this modal should not be displayed at all when rendering locally.

[garvinhicking]

How would we discern that? The locally rendered docs are what gets uploaded. So we would need some kind of javascript check to see if the domain matches "file://" or "ip-address" or "localhost" or "ddev" domain names or or or... that's a pandora's box?!

[linawolf]

I am openening the file in localhost via PHP storm: http://localhost:63342/render-guides/Documentation-GENERATED-temp/Index.html?_ijt=6kplt626g1nbd4cbtq0k4gf99o&_ij_reload=RELOAD_ON_SAVE

And I dont have the issue. It probably depends on how you open it weather the cookie can be set

[brotkrueml]

In Firefox with file:// URL:

consentbanner.webm

[linawolf]

which is no wonder as you cannot set cookies then.

[brotkrueml]

How was it done with the Sphinx-way? Some special building by the DRC?

[brotkrueml]

Ah, I know why it is displayed now: at home I have a Pihole which doesn't allow the consent manager, so I don't see this at home. But here at TYPO3 GmbH I don't have a Pihole, therefore it is displayed.

[linawolf]

So can this be closed?

[brotkrueml]

Working with Firefox locally (file:///localhost/...) this appears every time when switching to another page (at least for me). If it is only me, than feel free to close the issue - if it occurs also for someone else later, they can open a new issue.

One solution is to add 127.0.0.1 app.usercentrics.eu to the local hosts file (/etc/hosts) or add the domain to an ad blocker (both have the advantage that these consent banners also disappears from other pages who use usercentrics).

[linawolf]

I am no big fan of these consent banner and I dont really get why we would need them. But also they dont bother me enough to put in an effort to find out who made the descision why ;-) Maybe there is someone you could ask in Düsseldorf

[brotkrueml]

I assume, we embed the JavaScript for this on local rendering (haven't looked in the code, yet). And another assumption: In DRC on local rendering this JS is not embedded (like the search box top right and the TYPO3 header), only when deployed.

[garvinhicking]

Yes, packages/typo3-docs-theme/resources/template/structure/layoutParts/footerAssets.html.twig:

<script id="R9wBKTwzv" src="https://app.usercentrics.eu/latest/main.js"></script>

I don't think we currently have a twig variable that indicates "locally rendered" or "remotely rendered".

The trouble with this is, if you use the docker container, everything is "locally rendered". We have one place where the AZUREEDGEURI is evaluated to let all CI-rendered documentation point to central assets (instead of local assets). We could "abuse" this variable and try to somehow pass it into twig.

packages/typo3-docs-theme/src/Twig/TwigExtension.php stores that as $this->typo3AzureEdgeURI.

Similar to getRelativePath() in there we might be able to do something like:

public function doINeedToTrackAllTheThings() : bool
{
    if ($this->typo3AzureEdgeUri !== '') {
        return true;
    } else {
        return false;
    }
}

Then inside Twig we might be able to something like the following (I have no idea, I'm a twigvirgin):

{% if doINeedToTrackAllTheThings %}
<script id="R9wBKTwzv" src="https://app.usercentrics.eu/latest/main.js"></script>
{% /if %}

That might be worth it, otherwise we do collect local user statistics and "phone home" and this is not appreciated at least by me 🗡️

(Thanks for addressing this, this is indeed something we should solve)

[linawolf]

we could maybe set a flag in the script?

[brotkrueml]

Another possibility: Check if the URL starts with file:// - but this would be JS and a server-side check would be better. And a local detection would be also beneficial for the version selector which does not work locally.

[garvinhicking]

Problem is, Lina and me use ddev (which uses a http(s) protocol). And wysiwyg rendering uses 'localhost'.

So I think a "local" detection by doing this azureEdgeUriVersion would be good, also for the search then. What do you think about my code proposal? I just need the correct twig PHP+template implementation for it.

[brotkrueml]

Fine for me, but I would choose another name for the variable, like isRenderedForDeployment or similar. I assume, this would be a Twig function then?

[garvinhicking]

Yes, the variable name was more a joke; your idea sounds like a production-quality variable name. Twig function or variable, I don't know, I have like zero twig knowledge. If you can tell me the PHP+twige code I would need to use, I can prepare a PR