Add a global Twig variable with Contao state

[aschempp]

I think we controversely discussed this before. However, I had to copy-paste this to multiple of my projects recently, and I think it would make sense in general. With this, you can do the following in any Twig template:

any property from the page object (from current request = usually the global)

{{ contao.page.urlPrefix }}

check if preview mode is enabled

{{ contao.tokenChecker.isPreviewMode }}

[ausi]

I think the downside of something like this is, that the controller rendering the template no longer knows what data the template accesses, making the response of that controller theoretically uncacheable.

However, that problem already exists because of the global app variable.

Maybe we could at least mention that in the documentation of this global twig variable then?

[m-vo]

We also should discuss if this would better be a runtime that provides dedicated functions instead of a 'global'. I'm not sure yet but I'm leaning a bit towards the latter because then we could provide some more convenience instead of outputting raw values that the template has to deal with.

@aschempp Out of interest: where did you need those things? I assume in content elements where you did not have control over the controllers? If so, we could also just add these things to AbstractContentElementController#addDefaultDataToTemplate().

[aschempp]

I mostly used them in fe_page.html.twig actually. Only output the analytics scripts if no backend user is logged in (and not in preview mode). And I think I added some custom fields to tl_page and added CSS classes based on that to the body.

In my cases, neither of these would affect the cache (since anything in regards to user being logged in means a session, and a session means no cache). And any page property wouldn't change on a per-user basis.

[fritzmg]

At least the contao.tokenChecker would be required if you'd want to implement Analytics templates via Twig - since you'd want to use the hasBackendUser method of the token checker.

[aschempp]

At least the contao.tokenChecker would be required if you'd want to implement Analytics templates via Twig - since you'd want to use the hasBackendUser method of the token checker.

It would probably be better to add a contao.hasBackendUser method directly and use the token checker there. Then Twig users would not rely on knowing there is a TokenChecker and what methods it contains.
But I don't know if it is possible (and how to) maybe have contao.security.hasBackendUser without populating the contao.security array with properties that are possibly never used.

[andyKempf]

Servus & Moin!
Are there plans to include this change in the new LTS version? That would be nice, since you can't access tl_page DCA customizations with php variable $[GLOBALS] in Twig.

Thanks for your great work!

Greetings from Munich,
Andi

[fritzmg]

I agree that we should add this (or any other global variables that are useful) to the new LTS. Could also be done as a bugfix.

[aschempp]

PR updated. I also think we should "group" more useful global properties into the contao. variables. That includes the request token to me. @contao/developers let me know if you agree, maybe I'll need to update all usages then.

I checked the TemplateTrait and a few other places but couldn't find anything else to add. But I'm sure we'll come up with more … once we start using it! I intentionally did not add TL_MODE because the scope should not be relevant to the templates (and already is available for fragments etc.).

[aschempp]

Also, the SecurityVariable is necessary to get autocomplete support in the IDE. I tried using an anonymous class first, but then PHPStorm would not autocomplete the properties.

[aschempp]

The properties are now

{{ contao.has_backend_user }}
{{ contao.is_preview_mode }}
{{ contao.request_token }}
{{ contao.page.* }}

[ausi]

LGTM! Apart from #6436 (comment)

[leofeyer]

Thank you @aschempp.