In Typo3, what is the difference between setup, constants, and TSConfig - typo3

It seems there are three different places where I can write TypoScript: in templates, there is the constants field and the setup field, and in each page, there is a TSConfig field. However, it seems each TypoScript command need to go in a specific field. Most of the time, I have to try before finding if a given configuration goes into template setup, or in root page TSConfig.
Why are there three different places to write TypoScript? What is the use of each of them?

TSconfig is mainly for the backend
configuration. You can
add/alter/remove values from forms,
change the behavior what kind of
records users can add, default
usergroups etc. see About TSconfig for more
details.
Typoscript in the template is used to change the frontend behavior, template parsing, Extension configuration, navigation etc. Typoscript in the template has so called cObjects which provide useful functionality like Image manipulation (IMAGE), getting records from the database (RECORDS), creating menus (HMENU), see TypoScript Reference.
Typoscript constants are much like variables, which can be used within your template Typoscript. e.g. you have an email address which occurs in many different places within the Typoscript template, you might want to define it as constant. See documentation for more info.

Related

Ensure generated links in TYPO3 use the absolute path

I have a website in TYPO3, it has a header and footer and a load of generated page links.
Is there any parameters or TypoScript that can be used that would enable all links to have absolute paths? e.g. the item that generates the menu might look like
<f:cObject includeAbsolutePath="true" typoscriptObjectPath="lib.content_subMenu" />
I basically need all page links to be absolute.
I am using Typo3 V7.6
config.absRefPrefix might be your solution. But this could lead to drawbacks as well, e.g. in multi-domain environments. But in that case, you might work with conditions to set a proper domain name.
See details in the documentation.

How to remove an entry out of $GLOBALS['TCA'] (Table configuration array) in the Backend in TYPO3

I want to remove an entry in the select field in the plugins section of TYPO3. Basically where on can pick the list_type. I'd like to remove one. When I open the Configuration in the TYPO3 backend I see that all the configured extensions listed in:
$GLOBALS['TCA']['tt_content']['columns']['list_type']['config']['items']
But how can I remove an entry of this array now in my Editor (PhpStorm)? I can't find the entries in the TCA/Overrides/tt_content...
Any help or hints are appreciated!
Best
If you want to remove content element types (Ctypes) for editors, you could use Page TSConfig or User TSConfig. Add this to your backend user group or to the page (in the page properties Resources / Page TSConfig):
TCEFORM.tt_content.CType.removeItems := addToList(textpic,bullets,table,uploads)
This removes the element "textpic,bullets,table,uploads" in the backend for tt_content records.
TCEFORM.tt_content.list_type.removeItems := addToList(my_pi1,my_pi2)
But in addition to this you should also study the documentation for MOD pageTSconfig, specifically the section about the new content wizard. Remember that removing an empty from TCA is far, far from enough to remove the corresponding meta configuration from all places. You will also create pageTSconfig and TypoScript setup by registering a plugin and this setup may also need to be removed.
https://docs.typo3.org/typo3cms/TSconfigReference/8.7/PageTsconfig/Mod/Index.html#new-content-element-wizard-mod-wizards-newcontentelement
The easiest way if this is one of your own plugins and you don't need it at all: avoid registering it. One way to do so is to make a condition for whether or not to register the plugin and control this with a toggle (ENV, context, extension config, etc.)
When you register a plugin in TYPO3 it creates quite a bit of configuration in addition to adding the items to either the CType or list_type selectors depending on registration method. This other configuration is as important as the TCA item.

Custom CType vs. CType list & list_type

In my custom TYPO3 Extbase extension, I created a backend module to manage person records. Now I need a content element to show the records in the frontend.
I see two ways to achieve this:
Use the CType "list" and a custom list_type. Provide a FlexForm for additional fields
Use a custom CType, a FSC DataProcessor and TCA for additional fields
What's the best, most future-proof way to achieve this in TYPO3 CMS 7.6? What's the (dis-)advantage from one over the other?
The short answer
It doesn't matter, both ways are valid and will be supported in the future as well.
The long answer
I would always differ between a content element and a plugin but I agree that sometimes the difference might be hard to get.
A content element holds all information it should show inside its own record. As an example you could take an image gallery where all images are saved in a relation with FAL. Processors can be used to add additional information like done with FAL records.
A plugin contains controllers and actions and shows data which are saved somewhere else, e.g. records or from an XML or any other source.
Both types could be enhanced by providing a configuration using flexforms or additional fields.

May I use variables in Page TSConfig - Typo3 in order to set dynamic content?

I am looking for a way to be able to set some content dynamically in the layout of a typo3 site.
For example, is there a way to set dynamically the title of the site?
So, I am wondering if is it possible to define some variables in Page TSConfig area as shown in the following image.
This option would be very usefull in cases where users are not so experienced to edit this content from Template tools --> Setup.
Thanks a lot!!!
Only admins have access to pages TSconfig field. They have access to the template record (and the TypoScript module) too.
Therefore you should use constants instead which do exactly what you want to archive.
Have a look at the TYPO3 documentation: https://docs.typo3.org/typo3cms/TyposcriptSyntaxReference/TypoScriptTemplates/Index.html
Define in constants:
# cat=page type=string; label=Page Title
title = foo
And use in setup:
config.pageTitle = {$title}

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.