CONFIG & config

If set, the Admin Panel displays at the bottom of pages.

Note: In addition, the panel must be enabled for the user as well, using the TSconfig for the user. See the TSconfig reference for more information.

This writes the <base> tag in the header of the document. Set this to the value that is expected to be the URL and append a "/" to the end of the string.

Determine the maximum cache lifetime of a page.

The maximum cache lifetime of a page can not only be determined by the start and stop times of content elements on the page itself, but also by arbitrary records on any other page. However, the page has to be configured so that TYPO3 knows the start and stop times of which records to include. Otherwise, the cache entry will be used although a start/stop date already passed by.

To include records of type <table name> on page <pid> into the cache lifetime calculation of page <page-id>, add the following TypoScript:

config.cache.<page-id> = <table name>:<storage-pid>

Multiple record sources can be added as comma-separated list, see the examples.

You can use the keyword "all" instead of a <page-id> to consider records for the cache lifetime of all pages.

You can use the keyword "current" instead of a <storage-pid> to consider records on the current page for the cache life of itself.

This includes the fe_users records on page 2 in the cache lifetime calculation for page 10:

config.cache.10 = fe_users:2

This includes records from multiple sources, namely the fe_users records on page 2 and the tt_news records on page 11:

config.cache.10 = fe_users:2,tt_news:11

Consider the fe_user records on the storage page 2 for the cache lifetime of all pages:

config.cache.all = fe_users:2

Each pages cache lifetime is influenced if fe_users stored on the page itself get changed:

config.cache.all = fe_users:current

The number of second a page may remain in cache.

This value is overridden by the value set in the page-record (field="cache_timeout") if this value is greater than zero.

If set, CSS files referenced in page.includeCSS and the like will be minified and compressed. Does not work on files, which are referenced in page.headerData.

Minification will remove all excess space. The more significant compression step (using gzip compression) requires $GLOBALS['TYPO3_CONF_VARS']['FE']['compressionLevel'] to be enabled in the Install Tool. For this to work you also need to activate the gzip- related compressionLevel options in .htaccess, as otherwise the compressed files will not be readable by the user agent.

TYPO3 comes with a built-in compression handler, but you can also register your own one using $GLOBALS['TYPO3_CONF_VARS']['FE']['cssCompressHandler'] .

$GLOBALS['TYPO3_CONF_VARS']['FE']['cssCompressHandler'] =
   \TYPO3\CMS\Core\Extension\ExtensionManager::extPath($_EXTKEY) .
   'Classes/CssCompressHandler.php:Vendor\MyExt\CssCompressHandler->compressCss';

Enabling this option together with $GLOBALS['TYPO3_CONF_VARS']['FE']['compressionLevel'] in the Install Tool delivers Frontend JavaScript files referenced in page.includeJS and the like using GZIP compression. Does not work on files, which are referenced in page.headerData.

Please note that this requires .htaccess to be adjusted, as otherwise the files will not be readable by the user agent. Please see the description of $GLOBALS['TYPO3_CONF_VARS']['FE']['compressionLevel'] in the Install Tool.

TYPO3 comes with a built-in compression handler, but you can also register your own one using $GLOBALS['TYPO3_CONF_VARS']['FE']['jsCompressHandler'] .

$GLOBALS['TYPO3_CONF_VARS']['FE']['jsCompressHandler'] =
   \TYPO3\CMS\Core\Extension\ExtensionManager::extPath($_EXTKEY) .
   'Classes/JsCompressHandler.php:Vendor\MyExt\JsCompressHandler->compressJs';

Setting config.concatenateCss merges Stylesheet files referenced in the Frontend in page.includeCSS and the like together. Files are merged only, if their media attribute has the same value, e.g. if it is "all" for several files. Does not work on files, which are referenced in page.headerData.

TYPO3 comes with a built-in concatenation handler, but you can also register your own one using $GLOBALS['TYPO3_CONF_VARS']['FE']['cssConcatenateHandler'] .

$GLOBALS['TYPO3_CONF_VARS']['FE']['cssCompressHandler'] =
   \TYPO3\CMS\Core\Extension\ExtensionManager::extPath($_EXTKEY) .
   'Classes/CssCompressHandler.php:Vendor\MyExt\CssCompressHandler->compressCss';

Setting config.concatenateJs merges JavaScript files referenced in the Frontend in page.includeJS and the like together. Does not work on files, which are referenced in page.headerData.

If all files to be concatenated are marked with the async flag, the async attribute is assigned to the script tag.

TYPO3 comes with a built-in concatenation handler, but you can also register your own one using $GLOBALS['TYPO3_CONF_VARS']['FE']['jsConcatenateHandler'] .

$GLOBALS['TYPO3_CONF_VARS']['FE']['jsConcatenateHandler'] =
   \TYPO3\CMS\Core\Extension\ExtensionManager::extPath($_EXTKEY) .
   'Classes/JsConcatenateHandler.php:Vendor\MyExt\JsConcatenateHandler->concatenateJs';

Exceptions which occur during rendering of content objects (typically plugins) will be caught by default in production context and an error message is shown along with the rendered output.

If this is done, the page will remain available while the section of the page that produces an error (i.e. throws an exception) will show a configurable error message. By default this error message contains a random code which references the exception and is also logged by the logging framework for developer reference.

If this is not set or set to false, the PAGE object automatically outputs a HTML skeleton, see Output of the PAGE object.

To disable this default behaviour set disableAllHeaderCode = 1. The page outputs only the result of the cObject array (1,2,3,4...) of the PAGE object.

Use this feature in templates supplying other content-types than HTML. That could be an image, a RSS-feed, an ajax request in a format like XML or JSON.

This property can also be used to generate the complete HTML page, including the <html> and <body> tags manually.

A page type providing JSON:

json = PAGE
json {
   typeNum = 1617455215
   10 =< tt_content.list.20.tx_myextension_myjsonplugin
   config {
      disableAllHeaderCode = 1
      additionalHeaders.10.header = Content-type:application/json
   }
}

If this option is set, the TYPO3 core will not generate the opening <body ...> part of the body tag. The closing </body> is not affected and will still be issued.

disableBodyTag takes precedence over the PAGE properties bodyTagCObject, bodyTag and bodyTagAdd. With config.disableBodyTag = 1 the others are ignored and don't have any effect.

TYPO3 by default sends a Content-language: XX HTTP header, where "XX" is the ISO code of the according language. The value is based on the language defined in the Site Configuration.

If config.disableLanguageHeader is set, this header will not be sent.

If set, then a document type declaration (and an XML prologue) will be generated. The value can either be a complete doctype or one of the following keywords:

xhtml\_trans for the XHTML 1.0 Transitional doctype.

xhtml\_strict for the XHTML 1.0 Strict doctype.

xhtml\_basic for the XHTML basic doctype.

xhtml\_11 for the XHTML 1.1 doctype.

xhtml+rdfa\_10 for the XHTML+RDFa 1.0 doctype.

html5 for the HTML5 doctype.

none for no doctype at all.

See config.htmlTag_setParams for more details on the effect on the HTML tag.

Default is the HTML 5 doctype:

<!DOCTYPE html>

If set, a header "content-length: [bytes of content]" is sent.

If a backend user is logged in, this is disabled. The reason is that the content length header cannot include the length of these objects and the content-length will cut off the length of the document in some browsers.

Force the &type value of all TYPO3 generated links to a specific value (except if overruled by local forceTypeValue values).

Useful if you run a template with special content at - say &type=95 - but still wants to keep your targets neutral. Then you set your targets to blank and this value to the type value you wish.

Sets the attributes for the <html> tag on the page. Allows to override and add custom attributes via TypoScript without having to re-add the existing attributes generated by SiteHandling.

This property supersedes the previous config.htmlTag_setParams option by providing a more flexible API to add attributes.

config.htmlTag.attributes.class = no-js

Results in :

<html lang="fr" class="no-js">

config.htmlTag.attributes.amp =

Results in :

<html lang="fr" amp>

Sets the attributes for the <html> tag on the page. If you set doctype to a keyword enabling XHTML then some attributes are already set. This property allows you to override any preset attributes with your own content if needed.

Special: If you set it to "none" then no attributes will be set at any event.

Enables cached pages to be indexed.

Automatically enabled when EXT:indexed_search is enabled.

If set, external media linked to on the pages is indexed as well.

Automatically enabled when EXT:indexed_search is enabled.

If set, the inline styles TYPO3 controls in the core are written to a file, typo3temp/assets/css/stylesheet_[hashstring].css, and the header will only contain the link to the stylesheet.

The file hash is based solely on the content of the styles.

HTTP_GET_VARS, which should be passed on with links in TYPO3. This is compiled into a string stored in $GLOBALS['TSFE']->linkVars

The values are rawurlencoded in PHP.

You can specify a range of valid values by appending a () after each value. If this range does not match, the variable won't be appended to links. This is very important to prevent that the cache system gets flooded with forged values.

The range may contain one of these values:

• [a]-[b] -A range of allowed integer values
• int -Only integer values are allowed
• [a]\|[b]\|[c] -A list of allowed strings (whitespaces will be removed)
• /[regex]/ -Match against a regular expression (PCRE style)

You can use the pipe character (|) to access nested properties.

config.linkVars = print

This will add &print=[print-value] to all links in TYPO3.

config.linkVars = tracking|green(0-5)

With the above configuration the following example GET parameters will be kept: &tracking[green]=3. But a get parameter like tracking[blue] will not be kept.

Charset used for the output document. For example in the meta tag:

<meta charset=... />

It is used for a) HTML meta tag, b) HTTP header (unless disabled with disableCharsetHeader) and c) xhtml prologues (if available).

If metaCharset is not UTF-8, the output content is automatically converted to metaCharset before output and likewise are values posted back to the page converted from metaCharset to UTF-8 for internal processing. This conversion takes time of course so there is another good reason to use the same charset for both.

If an unknown charset is provided a \RuntimeException will be thrown.

Allows you to set a list of page id numbers which will always have a certain "&MP=..." parameter added.

Syntax:

[id],[id],... : [MP-var] | [id],[id],... : [MP-var] | ...

config.MP_defaults = 36,37,48 : 2-207

This will by default add &MP=2-207 to all links pointing to pages 36,37 and 48.

Defines a list of ID numbers from which the MP-vars are automatically calculated for the branch.

The result is used just like MP_defaults are used to find MP-vars if none has been specified prior to the call to \TYPO3\CMS\Frontend\Typolink\PageLinkBuilder.

You can specify root as a special keyword in the list of IDs and that will create a map-tree for the whole site (but this may be VERY processing intensive if there are many pages!).

The order of IDs specified may have a significance; Any ID in a branch which is processed already (by a previous ID root point) will not be processed again.

The configured IDs have to be the uids of Mount Point pages itself, not the targets.

config.namespaces.dc = http://purl.org/dc/elements/1.1/
config.namespaces.foaf = http://xmlns.com/foaf/0.1/

This configuration will result in an <html> tag like:

<html xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:foaf="http://xmlns.com/foaf/0.1/">

If you only want to have the site name (from the template record) in your <title> tag, set this to 1. If the value is 2 then the <title> tag is not printed at all.

Please take note that this tag is required for (X)HTML compliant output, so you should only disable this tag if you generate it manually already.

TYPO3 by default prints a title tag in the format "website: page title".

If pageTitleFirst is set (and if the page title is printed), then the page title will be printed IN FRONT OF the template title. So it will look like "page title: website".

In order to keep setting the titles in control, an API to set the page title is available. The API uses PageTitleProviders to define the page title based on page record and the content on the page.

Based on the priority of the providers, the PageTitleProviderManager will check the providers if a title is given by the provider. It will start with the highest priority PageTitleProviders and will end with the lowest in priority.

By default, TYPO3 ships with two providers:

config.pageTitleProviders {
   record {
      provider = TYPO3\CMS\Core\PageTitle\RecordPageTitleProvider
   }
   seo {
      provider = TYPO3\CMS\Seo\PageTitle\SeoTitlePageTitleProvider
      before = record
   }
}

The ordering of the providers is based on the before and after parameters. If you want a provider to be handled before a specific other provider, set that provider in the before, do the same with after.

You can find information about creating own PageTitleProviders in the section PageTitle API.

This produces a title tag with the content "website . page title":

config.pageTitleSeparator = .

This produces a title tag with the content "website - page title":

config.pageTitleSeparator = -
config.pageTitleSeparator.noTrimWrap = | | |

This produces a title tag with the content "website*page title":

config.pageTitleSeparator = *
config.pageTitleSeparator.noTrimWrap = |||

If you want to remove the web page title from the displayed title, choose a separator that is not included in the web page title. Then split the title from that character and return the second part only:

config.pageTitleSeparator = *
config.pageTitle.stdWrap {
    split {
        token = *
        returnKey = 1
    }
}

If set, the default JavaScript in the header will be removed.

The default JavaScript is the decryption function for email addresses.

Special case: If the value is "external", then the default JavaScript is written to a temporary file and included from that file. See inlineStyle2TempFile.

If set, TYPO3 will output cache-control headers to the client based mainly on whether the page was cached internally. This feature allows client browsers and/or reverse proxies to take load off TYPO3 websites.

The conditions for allowing client caching are:

• page was cached
• No *_INT or *_EXT objects were on the page (e.g. USER and USER_INT)
• No frontend user is logged in
• No backend user is logged in

If these conditions are met, the headers sent are:

• Last-Modified [SYS_LASTCHANGED of page id]
• Expires [expire time of page cache]
• ETag [md5 of content]
• Cache-Control: max-age: [seconds til expiretime]
• Pragma: public

In case caching is not allowed, these headers are sent to avoid client caching:

• Cache-Control: private, no-store

Notice that enabling the browser caches means you have to consider how log files are written. Because when a page is cached on the client it will not invoke a request to the webserver, thus not writing the request to the log. There should be ways to circumvent these problems but they are outside the domain of TYPO3 in any case.

Tip: Enabling cache-control headers might confuse editors seeing old content served from the browser cache. "Shift-Reload" will bypass both browser- and reverse-proxy caches and even make TYPO3 regenerate the page. Teach them that trick!

Thanks to Ole Tange, www.forbrug.dk for co-authoring this feature.

If this is set, then cache-control headers allowing client caching is sent only if user-logins are disabled for the branch. This feature makes it easier to manage client caching on sites where you have a mixture of static pages and dynamic sections with user logins.

The background problem is this: In TYPO3 the same URL can show different content depending on whether a user is logged in or not. If a user is logged in, cache-headers will never allow client caching. But if the same URL was visited without a login prior to the login (allowing caching) the user will still see the page from cache when logged in (and so thinks he is not logged in anyway)! The only general way to prevent this is to have a different URL for pages when users are logged in.

Another way to solve the problem is using this option in combination with disabling and enabling logins in various sections of the site. In the page records you can disable frontend user logins for branches of the page tree. Since many sites only need the login in a certain branch of the page tree, disabling it in all other branches makes it much easier to use cache-headers in combination with logins; Cache-headers should simply be sent when logins are not allowed and never be send when logins are allowed! Then there will never be problems with logins and same-URLs.

If set, then all email addresses in typolinks will be encrypted so that it is harder for spam bots to detect them.

If you set this value to a number, then the encryption is an offset of character values. If you set this value to "-2" then all characters will have their ASCII value offset by "-2". To make this possible, a little JavaScript code is added to every generated web page!

(It is recommended to set the value in the range from -5 to 1 since setting it to >= 2 means a "z" is converted to "|" which is a special character in TYPO3 tables syntax – and that might confuse columns in tables.)

It is required to enable the default JavaScript and not disable it. (see removeDefaultJS)

Used by the parseFunc-substitution of search Words (sword):

If set, the words MUST be the exact same case as the search word was.

Used by the parseFunc-substitution of search Words (sword):

If set, the words MUST be surrounded by whitespace in order to be marked up.

If set, typolinks pointing to access restricted pages will still link to the page even though the page cannot be accessed. If the value of this setting is an integer it will be interpreted as a page id to which the link will be directed.

If the value is NONE the original link to the page will be kept although it will generate a page-not-found situation (which can of course be picked up properly by the page-not-found handler and present a nice login form).

See showAccessRestrictedPages for menu objects as well (similar feature for menus)

config.typolinkLinkAccessRestrictedPages = 29
config.typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###

Will create a link to page with id 29 and add GET parameters where the return URL and original page id is a part of it.

Sets the document type for the XHTML version of the generated page.

If doctype is set to a string then xhtmlDoctype must be set to one of these keywords:

xhtml\_trans for XHTML 1.0 Transitional doctype.

xhtml\_strict for XHTML 1.0 Strict doctype.

xhtml\_basic for XHTML basic doctype.

xhtml\_11 for XHTML 1.1 doctype.

This is an example to use MathML 2.0 in an XHTML 1.1 document:

config.doctype (
  <!DOCTYPE html
      PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
      "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd">
)
config.xhtmlDoctype = xhtml_11

If empty (not set) then the default XML 1.0 prologue is set, when the doctype is set to a known keyword (e.g. xhtml_11):

<?xml version="1.0" encoding="utf-8">

If set to one of the following keywords then a standard prologue will be set:

xml\_10: XML 1.0 prologue (see above)

xml\_11: XML 1.1 prologue

none: The default XML prologue is not set.

Any other string is used as the XML prologue itself.