How to access extension configuration options from TSconfig conditions? - typo3

Global extension settings are done in ext_conf_template.txt and edited in the BE in the Settings module. The documentation headlines this settings as Configuration options.
How are they accessible from pageTSConfig conditions in TYPO3 versions 9.x?

I think this is not possible with the conditions based on the symfony expression language at the current state.
In the BE I can verify that the access would be via global variables:
GLOBALS|TYPO3_CONF_VARS|EXTENSIONS|myextkey|mysetting
In the unit tests I found a comment that access to global variables is bad. I conclude that a general access to globals is just not implemented. Instead access to some global variables is provided as functions for example access to TSFE as getTSFE.
https://docs.typo3.org/typo3cms/TyposcriptReference/Conditions/Reference.html#functions
The drawback is, that the access to many global variables is currently not implemented.

Related

Should Extbase Persistence TypoScript always be loaded globally?

Imagine a multi-site TYPO3 installation. One of those sites uses an Extension (loads the extension's TypoScript) that modifies the config.tx_extbase.persistence.classes config for GeorgRinger\News\Domain\Model\News. Other sites also use News, but without including that Extension doing the modification.
The problem that you will run into is that the DataMaps are cached globally - so after clearing the cache it depends which site will be called first and its extbase persistence configuration will be cached, possibly breaking the functionality of the other sites.
To get around this problem I started to move DataMapper related TypoScript into a separate TypoScript file ExtbasePersistence.typoscript and load it globally in ext_localconf.php:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTypoScript('myext', 'setup', '<INCLUDE_TYPOSCRIPT: source="FILE:EXT:myext/Configuration/TypoScript/ExtbasePersistence.typoscript">');
My question is: Why is this not best practise and done in every extension? Or what am I doing wrong that I seem to be the only one running into that problem?
Edit: From my point of view this would mean that also core extensions (such as extbase) MUST load their DataMapper related TypoScript globally.
Extbase does load this globally via https://github.com/TYPO3/TYPO3.CMS/blob/9.5/typo3/sysext/extbase/ext_typoscript_setup.typoscript
This file is auto loaded by TYPO3 on a global scope, this is also best practice, as far as I know.
Each Extension can add this file, see https://docs.typo3.org/typo3cms/CoreApiReference/ExtensionArchitecture/FilesAndLocations/Index.html#reserved-file-names

Keycloak templates available variables

I'am googling for a while in order to find a documentation of all available say "variables" I can use in the various Keycloak templates.
by variable I mean all the ${xxx.yyy} things I can use to inject some dynamic values inside the template.
Through the documentation I can find here and there some of them (like ${user.attributes} or ${url.resourcesPath}) but are there others than these ?
Does anyone have a reference link ?
Many Thanks
You can look for the template providers in Keycloak's code.
All the templates are "ftl" files filled with a map called "attributes". Keycloak has a couple of classes which fill those templates with Beans depending on the page or action as CharlyP mentioned. For example:
FreeMarkerEmailTemplateProvider class fills the email templates.
FreeMarkerLoginFormsProvider class fills the login templates.
I did not find any easy to use documentation but I found the Keycloak Javadocs which can be helpful when you look for the *Bean classes of this documentation. These classes seem to be the ones available in most of the templates. And their public methods will match the available properties you can use in the templates.
For example:
You want to know the properties available for the variable url you can check the class UrlBean in the documentation and you will find for example a method getLoginUrl. This means you can access the property url.loginUrl.
That's all I could find for the time being. Hope it will be helpful...

environment specific variables in pingfederate templates

I am customizing a pingfederate temaplte (for login).
As part of this customization I would like to be able to have a java script variable that is dependent on the configuration of the form being used. Essentially to distinguish between a test and a live environment.
I'm trying to keep the templates in source control and not have duplicated code and also to be able to test configurations before I deploy.
I'd like to think that I could set a variable somewhere in the admin interface and get this exposed in the template, however I have found nothing in the documentation to suggest that this is possible.
Is there a way to do this, or a reasonable work around?
From the perspective of PingFederate itself, no. There are plenty of mechanisms in Javascript that you could use, like window.location.host to trigger CSS properties. You could even use the Velocity variable of $PingFedBaseURL to drive CSS properties.

using fluidcontent (fluid powered TYPO3) in a TYPO3 multidomain setup

I have an TYPO3 installation with two domains. Each domain has its own provider extension and static template file.
Example:
domain1.com -> providerextension1
domain2.com -> providerextension2
Is it possible to hide the fluidcontent FCEs from providerextension1 in domain2.com?
Example from Bootstrappackage (https://github.com/Ecodev/bootstrap_package)
As soon as an extension has included fluidcontent FCEs (like the fluidcontent_bootstrap) it will add these to all domains, also when the TypoScript Configuration is not included.
If I understand the question completely, the answer is no: you cannot in TYPO3 make your TypoScript that is available in the backend, depend on the domain name being used. There is a way to make TypoScript conditions for the frontend output (for example a condition to only add template paths for your provider A when domain is X), but the same is not possible in the backend.
You are of course welcome to add a feature request on our issue tracker - I don't see any immediate problem with a feature to toggle on and off particular provider extensions based on for example a TypoScript setting. But you should keep in mind the limitation mentioned above since it implies that in order to achieve your desired goal you must place each domain record on a page tree of its own and closely manage the TypoScript that controls the available Provider Extensions on each page tree.
Put shortly: even if you get this feature request filled, it may not be the solution you want and you may have to restructure your pages and domains to get where you need to be.
The problem is, that the FCE are defined in the "ext_tables.php" and "ext_localconf.php" and these files are always loaded when the extension is enabled.
You can alter "ext_tables/ext_localconf" with a simple condition like
if($_SERVER['server_name'] == "www.yourdomain.com") {
//init FCEs here
}
You can try to override the template paths for one domain with an empty value or at least a path to an empty directory. Maybe flux is smart enough to ignore empty template paths.

TYPO3 user permissions: "read-only" Extension mananger and Templates module

Hi,
I'm looking for a way to set user permissions in the TYPO3 backend (Version 4.5.25 LTS in this special case) as follows:
User should be able to see the modules "Extension Manager" and "Template"
he is not allowed to edit the Templates, only read them (for evaluation or training purpose)
he is not allowed to un/install extensions, languages etc, but read the extension list and the extensions informations provided in the list of installed extension.
Is this possible somehow? I know you can't restrict admin users like that.
Is it possible to extend normal BE users like that? Or is there another way?
Thanks in advance!
This is not possible unless you create an extension for this that hooks into the access right evaluation.
For your usecase, I recommend to put all TypoScript templates into files and give the user read only access to the filesystem.
You can also ship all templates inside an extension, then you just need to share the typo3conf/folder.