This document is included as part of the official TYPO3 documentation.
It has been approved by the TYPO3 Documentation Team following a peer-
review process. The reader should expect the information in this
document to be accurate - please report discrepancies to the
Documentation Team (documentation@typo3.org). Official documents are
kept up-to-date to the best of the Documentation Team's abilities.

This document is a Core Manual. Core Manuals address the built in
functionality of TYPO3 and are designed to provide the reader with in-
depth information. Each Core Manual addresses a particular process or
function and how it is implemented within the TYPO3 source code. These
may include information on available APIs, specific configuration
options, etc.

Core Manuals are written as reference manuals. The reader should rely
on the Table of Contents to identify what particular section will best
address the task at hand.

If you find a bug in this manual, please be so kind as to check the
online version on.
From there you can hit the "Edit me on GitHub" button in the top right corner
and submit a pull request via GitHub. Alternatively you can just file an issue
using the bug tracker.

Maintaining high quality documentation requires time and effort
and the TYPO3 Documentation Team always appreciates support.

If you want to support us, please join the slack channel #typo3-documentation
on Slack.
Visit forger to gain access to Slack.

And finally, as a last resort, you can get in touch with the documentation team
by mail.

All names and references in TypoScript are case sensitive! This
is very important to notice. For example watch the words "TEXT" and "value"
in this TypoScript code:

myObject =TEXT
myObject.value =<strong>Some HTML code</strong>

This is not the same as

myObject = text
myObject.Value =<strong>Some HTML code</strong>

While the first will be recognized as the content object "TEXT" and
will produce the desired output, the latter will not be recognized and
will not output anything. Even if you wrote "TEXT" in uppercase in the
second example, it would still not work, because the property "value"
is misspelled.

TYPO3 CMS does not provide a definite templating method out of the box.
However a minimal amount of TypoScript will always be necessary to
tell TYPO3 CMS which templating method to use.
It could be any of the following:

Fluid templates: Configure TYPO3 to use Extbase and Fluid
for templating. This allows to use external HTML templates, but
with fluid-style variables with curly braces. A content object
FLUIDTEMPLATE is available, which uses Fluid
from inside TypoScript.

In both the "Constants" and "Setup" fields, the
INCLUDE_TYPOSCRIPT syntax can be
used to include TypoScript contained inside files.

Apart from this, it is also possible to include other TypoScript template
records (in the field called "Include Basis Template") and
TypoScript provided by extensions (in the field called "Include static
(from extensions)").

With all those inclusions, it may happen that you lose the overview of the
template structure. The "Template Analyzer" provides an overview of this
structure. It shows all the templates that apply to the currently selected page,
taking into account inclusions and inheritance along the page tree.

Templates are taken into consideration from top to bottom, which means
that properties defined in one template may be overridden in templates
considered at a later point by the TypoScript parser.

In the Template Analyzer, you can click on any listed template to view
the content of its "Setup" and "Constants" fields.

The line numbers are compiled from the first template to be included,
which is why the numbers are so high.

Constants are values defined in the "Constants" field of a template. They
follow the syntax of ordinary TypoScript and are case sensitive! They are used to
manage in a single place values, which are later used in several places.

When a TypoScript Template is parsed by TYPO3 CMS, constants are replaced, as
one would perform any ordinary string replacement. Constants are used in the
"Setup" field by placing them inside curly braces and prepending them with a
$ sign:

{$bgCol}{$topimg.width}{$topimg.file.pic2}{$file.toplogo}

Only constants, which are actually defined in the "Constants" field, are
substituted.

Constants in included templates are also substituted, as the whole
template is one large chunk of text.

A systematic naming scheme should be used for constants. As "paths" can be
defined, it's also possible to structure constants and prefix them with a common
path segment. This makes reading and finding of constants easier.

It's possible to add comments in TypoScript. Comments are always ignored by the
parser when the template is processed. But the backend module WEB > Template
has the ability to use comments in the constant editor to make simple
configuration of a template even easier than constants already make it
themselves.

The Constant Editor showing a category with constants

When the "Constant Editor" parses the template, all comments before every
constant-definition are registered. A certain syntax is available to define
what category the constant should be in, which type it has and to provide a
description for the constant.

Comma-separated list of the categories (case-insensitive) that the constant is
a member of. Only one category should be used, because it usually turns out to
be confusing for users, if the same constant appears in multiple categories.

If the chosen category is not found among the default categories listed
below, and is not a custom category either, it's regarded a new category.

If the category is empty (""), the constant is excluded from the editor.

Constants of superior importance for the template. This is typically
dimensions, image files and enabling of various features. The most
basic constants, which would almost always needed to be configured.

To define a new category, a comment including the parameter customcategory
has to be added. Example:

# customcategory=mysite=LLL:EXT:myext/locallang.xlf:mysite

This line defines the new category "mysite" which will be available for any
constant defined after this line. The LLL: reference points to the
localized string used to "name" the custom category in the Constant Editor.
Usage example:

The third part of the category definition is optional and represents
the order in which the constants are displayed in the Constant Editor.
The values are sorted alphabetically, so it is traditional to use letters.
Example:

The "Special cache" constant will be displayed after the "Global no_cache"
constant, because it is ranked with letter "b" and the other constant
has letter "a". Constants without any ordering information will come last.

There exists a number of predefined types, which define what kind of field is
rendered for inputting the constant.

Type

Description

int [low-high]

Integer, optional in range "low" to "high".

int+

Positive integer

offset [L1,L2,...L6]

Comma-separated list of integers. Default is "x,y", but as comma separated
parameters in brackets one can specify up to 6 labels being comma separated.
If wished to omit one of the last 4 fields, leave the label empty
for that element.

color

HTML color

wrap

HTML code that is wrapped around some content.

options [item1,item2,...]

Selectbox with values/labels item1, item2 etc. Comma-separated. Split
by "=" also and in that case, first part is label, second is value.

boolean [truevalue]

Boolean, optional can define the value of "true", default is 1.

comment

Boolean, checked= "", not-checked = "#".

string (the default)

A string value

user

Path to the file and method which renders the option HTML,
for example type=user[Vendor\Extension\Namespace\ClassName->myCustomField].
The method should have following signature:
publicfunctionmyCustomField(array$params).

It is possible to store variable values into a memory stack which is called
"register". The cObjects LOAD_REGISTER and
RESTORE_REGISTER provide this storage functionality.
Some TYPO3 cObjects use internal registers. Esp. the menus are built be
registers (e.g. count_HMENU, count_HMENU_MENUOBJ, count_menuItems).

Registers in TypoScript can be seen as stack array variables in programming
languages. Each register can store a complex TypoScript block. Use
LOAD_REGISTER to put a variable to the stack, use
RESTORE_REGISTER to pull a variable from the stack
and curly braces around a variable name to read the current value of the
variable. You need a stdWrap.data or a
stdWrap.dataWrap cObject. The registers cannot be read
on other places than inside of these cObjects.

This example shows a part of a TypoScript which builds a 2 column menu based on
a spacer page. A class is added to the ul tag depending on the value of the
register variable ulClass. The first pages will have the class col-left and
the pages following the spacer page will get the class col-right.

{register:variablename} returns the "current" value of the variable
variablename. A register stack can be like any TypoScript setup.

The "current" value is just an internal variable that can be used by functions
to pass a single value on to another function later in the TypoScript
processing. It is like "load accumulator" in the good old C64 days. Basically
you can use a "register" as you like. The TSref will tell if functions are
setting this value before calling some other object so that you know if it holds
any special information.

Debugging TypoScript can be complicated as there are many influences like the
active page and conditions. Also constants can be used which get substituted.
The following sections provide information about how to debug TypoScript and how
to find errors within TypoScript.

There are no tools that will tell whether the given TypoScript code is 100%
correct. The TypoScript Object Browser will warn about syntax errors though:

Errors will also appear in the Template Analyzer, when viewing the content of a
give template. It is also possible to see the full TypoScript code by clicking
on the "View the complete TS listing" button at the bottom of the Template
Analyzer:

The result is a long listing with all compiled line numbers, which makes it
possible to find the error reported by the TypoScript Object Browser.

In the frontend, the Admin Panel is another possibility to debug TypoScript; use
its section called "TypoScript". It shows selected rendered (configuration)
values, SQL queries, error messages and more.

The values assigned to properties in TypoScript are often of a
specific format. These formats are described in this chapter.

For example, if a value is defined as the type <tag>, HTML code has to be
supplied. If it is of the type resource, it's a reference to a file from
the resource-field in the template. If the type is GraphicColor, a
color-definition is expected and an HTML color code or comma-separated
RGB-values have to be provided.

The following is a list of available data types, their usage, purpose and
examples.

Indicates a function or method in a class to call. See more information at
the USER cObject.

If no namespaces are used, then the class or function name, but not the method
name, should probably be prefixed with user_. The prefix can be
changed in the $GLOBALS['TYPO3_CONF_VARS'] config though. The function
/ method is normally called with 2 parameters, $conf which is the
TypoScript configuration and $content, some content to be processed and
returned.

If no namespaces are used and if a method in a class is called, it is checked (when using the
USER/USER_INT objects) whether a class with the same name, but
prefixed with ux_ is present and if so, this class is instantiated
instead. See the document "Inside TYPO3" for more information on extending
classes in TYPO3!

The getText data type is some kind of tool box allowing to retrieve
values from a variety of sources, e.g. from GET/POST variables, from
registers, values from the page tree, items in the page menus, records from any database table, etc.

The general syntax is as follows:

key : code

where key indicates the source and code is some form of path or
pointer to the value, which depends on the key used. The various keys and
their possible codes are described below.

The code can contain pipe characters | to separate keys
in a multi-dimensional array. This e.g. works with TSFE:

foo = TSFE : fe_user|user|username

Some codes work with different separator, which is documented right at the
code.
Spaces around the colon (:) are irrelevant. The key is
case-insensitive.

By separating the value of getText with // (double slash) a number of
codes can be supplied and getText will return the first one, which is not
empty ("" or zero).

To get the content of the field "header". If "header is empty, "title" is
retrieved. If "title" is empty as well, it finally gets the field "uid":

Retrieves a property from a file object (FAL) by identifying it through its
sys_file UID. Note that during execution of the FILES cObject,
it's also possible to reference the current file with "current" as UID like
file:current:size.

Furthermore when manipulating references (such as images in content elements
or media in pages), additional properties are available (not all are
available all the time, it depends on the setup of references of the
FILES cObject): title, description, link, alternative.

Additionally, any data in the "sys_file_metadata" table can be accessed too.

This property can be used to retrieve values from "above" the current page's
root. Take the below page tree and assume that we are on the page "Here you
are!". Using the levelfield property, it is possible
to go up only to the page "Site root", because it is the root of a new
(sub-)site. With fullRootLine it is possible to go all the way up to page
tree root. The numbers between square brackets indicate to which page each
value of pointer would point to:

Returns the value of a System Environment Variable denoted by
name regardless of server OS, CGI/MODULE version etc. The result is
identical to the $_SERVER variable in most cases. This method should
be used instead of getEnv to get reliable values for all situations. The
internal processing is handled by
TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv()

Available names:

Name

Definition

Example or result

_ARRAY

Return an array with all available key-value pairs for debugging purposes

leveltitle, leveluid, levelmedia: [levelTitle, uid or media in
root line, 0- , negative = from behind, " , slide" parameter forces a
walk to the bottom of the root line until there's a "true" value to
return. Useful with levelmedia.]

Description:

Returns values from up or down the page tree.

Examples:

Get the title of the page on the first level of the root line:

foo = leveltitle :1

Get the title of the page on the level right below the current page AND if
that is not present, walk to the bottom of the root line until there's a
title:

page.10=TEXT
page.10.data = siteLanguage:navigationTitle
page.10.wrap = This is the title of the current site language:|page.10=TEXT
page.10.dataWrap = The current site language direction is {siteLanguage:direction}

century number (the year divided by 100 and truncated to an integer, range 00 to 99)

%d

day of the month as a decimal number (range 00 to 31)

%D

same as %m/%d/%y

%e

day of the month as a decimal number, a single digit is preceded by a space (range ' 1' to '31'). Note that the %e modifier is not supported in the Windows implementation of 'strftime'.

%h

same as %b

%H

hour as a decimal number using a 24-hour clock (range 00 to 23)

%I

hour as a decimal number using a 12-hour clock (range 01 to 12)

%j

day of the year as a decimal number (range 001 to 366)

%m

month as a decimal number (range 01 to 12)

%M

minute as a decimal number

%n

newline character

%p

either `am' or `pm' according to the given time value, or the corresponding strings for the current locale

%r

time in a.m. and p.m. notation

%R

time in 24 hour notation

%S

second as a decimal number

%t

tab character

%T

current time, equal to %H:%M:%S

%u

weekday as a decimal number [1,7], with 1 representing Monday

%U

week number of the current year as a decimal number, starting with the first Sunday as the first day of the first week

%V

The ISO 8601:1988 week number of the current year as a decimal number, range 01 to 53, where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week.

%W

week number of the current year as a decimal number, starting with the first Monday as the first day of the first week

Used to wrap something. The vertical bar ("|") is the place, where
your content will be inserted; the parts on the left and right of the
vertical line are placed on the left and right side of the content.

Spaces between the wrap-parts and the divider ("|") are trimmed off
from each part of the wrap.

If you want to use more sophisticated data functions, then you
should use stdWrap.dataWrap instead of wrap.

A wrap is processed and rendered as the last of the other components of
a cObject.

Example:

This will cause the value to be wrapped in a p-tag coloring the
value red:

Whenever you see ->[object name] in the tables it means that the
property is an object "object name" with properties from object
object name. You don't need to define the object type. You will
often find the according documentation on its own page.

Sometimes a data type is set to "something +calc". "+calc" indicates
that the value is calculated with "+-/*". Be aware that the
operators have no "weight". The calculation is just done from left to
right.

optionSplit is the codename of a very tricky - but very useful! - function
and functionality. It is primarily used with the menu objects where it is
enable for MANY properties. This make optionSplit really powerful.

So let's take an example from menu building.
As a result all A-tags generated from this definition will have the class attribute
set like this: <aclass="z"...>:

topmenu.1.NO{
ATagParams = class="z"
}

How many A-tags will there be? Usually we cannot answer that question in advance
as we cannot know how long the list of menu items is. From zero to many everything
is possible. Let's describe this as: We have an output sequence of 0 to N items.

In real life one more thing is important: We often want to have a different properties
for the first and the last or odd and even elements. optionSplit tries to offer
an easy solution for this task as well. We can specify more than just one shaping
of a value for a property. Let's describe this as: We have an input sequence M items.

Now we can precisely define what optionSplit is.

Definition:

optionSplit is a syntax to define an input sequence of a fixed amount M
of values. It has a fixed, builtin ruleset. Its functionality is to
apply ONE of the input values to each output item according to the position of
the output item and the ruleset.

In other words:

We have an input sequence of M items. M is known.

We have an output sequence of 0 to N items. N is unknown and may be zero, one, or "large".

We have a ruleset delivered with optionSplit that specifies how the input sequence
should be applied to the output sequence.

With no delimiters at all we still have - implicitly - one mainpart
A with one subpart a:

input:
wrap = a
output:
N output sequence
1 a
2 a a
3 a a a
4 a a a a
5 a a a a a
6 a a a a a a
7 a a a a a a a
8 a a a a a a a a
9 a a a a a a a a a
10 a a a a a a a a a a
11 a a a a a a a a a a a
12 a a a a a a a a a a a a
13 a a a a a a a a a a a a a
14 a a a a a a a a a a a a a a
15 a a a a a a a a a a a a a a a
16 a a a a a a a a a a a a a a a a
17 a a a a a a a a a a a a a a a a a
18 a a a a a a a a a a a a a a a a a a
19 a a a a a a a a a a a a a a a a a a a
20 a a a a a a a a a a a a a a a a a a a a

input:
wrap = a |*||*| z
output:
N output sequence
1 z
2 a z
3 a a z
4 a a a z
5 a a a a z
6 a a a a a z
7 a a a a a a z
8 a a a a a a a z
9 a a a a a a a a z
10 a a a a a a a a a z
11 a a a a a a a a a a z
12 a a a a a a a a a a a z
13 a a a a a a a a a a a a z
14 a a a a a a a a a a a a a z
15 a a a a a a a a a a a a a a z
16 a a a a a a a a a a a a a a a z
17 a a a a a a a a a a a a a a a a z
18 a a a a a a a a a a a a a a a a a z
19 a a a a a a a a a a a a a a a a a a z
20 a a a a a a a a a a a a a a a a a a a z

Each condition is encapsulated by square brackets. For a list of
available conditions see below.

[ELSE] is available as else operator. It is a condition, which will
return TRUE, if the previous condition returned FALSE.

Each condition block is ended with [END].

[GLOBAL] is a condition by itself that always returns "true".
It ensures that the following TypoScript code is located in the
global scope. So you can be sure that it's not affected by previous
TypoScript, for example if a closing bracket is missing.
The Template Analyzer shows this very well: TYPO3 places a
[GLOBAL] condition at the beginning of each TypoScript file.

Values are normally trimmed before comparison, so leading and trailing
blanks are not taken into account.

Note that conditions cannot be used inside of curly brackets.

You may combine several conditions with two operators: && (and), ||
(or). Alternatively you may use "AND" and "OR" instead of "&&" and
"||". The AND operator always takes higher precedence over OR. If no
operator has been specified, it will default to OR.

The existing conditions are available as variables and/or functions but were already marked as deprecated. So expect deprecation messages when using the old syntax with TYPO3 9. The existing conditions will be removed early in version 10.
If you want to know what your conditions did until now, have a look at an older version of this document .

[page["uid"] in 18..45]
# This condition matches if current page uid is between 18 and 45
[END]
[userId in [1,5,7]]
# This condition matches if current logged in user has the uid 1, 5 or 7
[END]
[not ("foo" matches "/bar/")]
# This condition does match if "foo" **not** matches the regExp: `/bar/`
[END]
[applicationContext == "Production"] && [userId == 15]
# This condition match if application context is "Production" AND logged in user has the uid 15
# This condition could also be combined in one condition:
# [applicationContext == "Production" && userId == 15]
[END]
[request.getNormalizedParams().getHttpHost() == 'typo3.org']
# This condition matches if current hostname is typo3.org
[END]
[like(request.getNormalizedParams().getHttpHost(), "*.devbox.local")]
# This condition matches if current hostname is any subdomain of devbox.local
[END]
[request.getNormalizedParams().isHttps() == false]
# This condition matches if current request is **not** https
[END]

The following variables are available. The values are context related.

Variable

Type

Description

applicationContext

String

current application context as string

page

Array

current page record as array

{$foo.bar}

Constant

Any TypoScript constant is available like before.
Depending on the type of the constant you have to use
different conditions, see examples below:
- if constant is an integer:
- [{$foo.bar} == 4711]
- if constant is a string put constant in quotes:
- ["{$foo.bar}" == "4711"]

tree
.level
.rootLine
.rootLineIds

Object
Integer
Array
Array

object with tree information
current tree level
array of arrays with uid and pid
an array with UIDs of the rootline

object with backend information (available in BE only)
object with current backend user information
true if current user is admin
true if current user is logged in
UID of current user
comma list of group UIDs

frontend
.user
.user.isLoggedIn
.user.userId
.user.userGroupList

Object
Object
Boolean
Integer
String

object with frontend information (available in FE only)
object with current frontend user information
true if current user is logged in
UID of current user
comma list of group UIDs

Get current date in given format.
Examples:
- true if day of current month is 7:
- [date("j") == 7]
- true if day of current week is 7:
- [date("w") == 7]
- true if day of current year is 7:
- [date("z") == 7]
- true if current hour is 7:
- [date("G") == 7]

like

String

This function has two parameters:
the first parameter is the string to search in
the second parameter is the search string
Example:
- [like("foobarbaz", "bar")]

ip

String

Value or Constraint, Wildcard or RegExp possible
special value: devIP (match the devIPMask

get value from site configuration, or null if
no site was found or property does not exists
Example, matches if site identifier = foo
- [site("identifier") == "foo"]
Example, matches if site base = http://localhost
- [site("base") == "http://localhost"]

siteLanguage

String

get vale from siteLanguage configuration, or
null if no site was found or property not exists
Example, match if siteLanguage locale = foo
- [siteLanguage("locale") == "de_CH"]
Example, match if siteLanguage title = Italy
- [siteLanguage("title") == "Italy"]

Extending the expression language with own functions (like old userFunc)¶

It is possible to extend the expression language with own functions like before userFunc in the old conditions.
An example could be TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionFunctionsProvider which implements
the most core functions.

Add new methods by implementing own providers which implement the ExpressionFunctionProviderInterface and
register the provider in ext_localconf.php:

Stores the rendered content into the caching framework and reads it
from there. This allows you to reuse this content without prior
rendering. The presence of cache.key will trigger this feature. It
is evaluated twice:

Content is read from cache directly after the stdWrapPreProcess hook and
before setContentToCurrent. If there is a cache entry for the given cache key,
stdWrap processing will stop and the cached content will be returned. If
no cache content is found for this key, the stdWrap processing continues as
usual.

Writing to cache happens at the end of rendering, directly before the
stdWrapPostProcess hook is called and before the "debug*" functions. The
rendered content will be stored in the cache, if cache.key was set. The
configuration options cache.tags and cache.lifetime allow to control
the caching.

The cache identifier that is used to store the rendered content into
the cache and to read it from there.

Note

Make sure to use a valid cache identifier. Also take care to choose a
cache key that is accurate enough to distinguish different versions of the
rendered content while being generic enough to stay efficient.

In the above example the current time will be cached with the key
"mycurrenttimestamp". This key is fixed and does not take the current
page id into account. So if you add this to your TypoScript, the
cObject will be cached and reused on all pages (showing you the same
timestamp).

The commented part is stdWrap.cache. property available since 4.7,
that does not stop the rendering of COA including all sub-cObjects.

Additionally, stdWrap support is added to key, lifetime and tags.

If you've previously used the cache. property in your custom cObject,
this will now fail, because cache. is unset to avoid double caching.
You are encouraged to rely on the core methods for caching cObjects or
rename your property.

stdWrap.cache continues to exists and can be used as before. However
the top level stdWrap of certain cObjects (e.g. TEXT cObject)
will not evaluate cache. as part of stdWrap, but before starting
the rendering of the cObject.
In conjunction the storing will happen after the stdWrap
processing right before the content is returned.

Top level cache. will not evaluate the hook
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['stdWrap_cacheStore']
any more.

For all non-wrapped lines, you can here set a tag in which they
should be wrapped. Example would be "p". This is an alternative to
wrapNonWrappedLines and has the advantage that its attributes are
set by addAttributes as well as defaultAlign.
Thus you can match the wrapping tags used for non-wrapped and wrapped
lines more easily.

This example shows how to handle content rendered by TYPO3 and
stylesheets where the <p> tag is used to encapsulate each line.

Say, you have made this content with the Rich Text Editor:

This is line # 1[Above is an empty line!]<divstyle="text-align:right;">This line is right-aligned.</div>

After being processed by encapsLines with the above configuration, the
content looks like this:

<p>This is line # 1 </p><p>&nbsp;</p><p>[Above is an empty line!] </p><pstyle="text-align: right;">This line is right-aligned.</p>

Each line is nicely wrapped with <p> tags. The line from the database
which was already wrapped (but in <div>-tags) has been converted to
<p>, but keeps it's alignment. Overall, notice that the Rich Text Editor
ONLY stored the line which was in fact right-aligned - every other line from the
RTE was stored without any wrapping tags, so that the content in the database
remains as human readable as possible.

This is an example of how to wrap traditional tt_content bodytext
with <p> tags, setting the line-distances to regular space like that
generated by a <br> tag, but staying compatible with the RTE features
such as assigning classes and alignment to paragraphs.

The filename of the icon used is the one of the filetype of the file
given in path (see above) plus extension (by default .gif).
For example for CSS files the icon file css.gif will be used
by default.
If for a certain filetype no icon file is found in icon.path, the file
default plus extension (for example default.gif) will be used.

The following sub-properties are available and have stdWrap functionality:

path

Path to the icon set.
Default is typo3/sysext/frontend/Resources/Public/Icons/FileIcons/.

icon needs to be set for the option to take effect and the file
extension of the image file must be part of icon_image_ext_list.
You can set one or two values, see the examples. If you set two
values, the first value will define the maximum width and the second
one the maximum height. The aspect ratio of the original image will be
preserved.

This property can be used to pass additional typolink settings for
the generated file link.
Please note that the following properties will be ignored because they are
set by the filelink function:
ATagParams,
fileTarget,
parameter,
title.

The modifier checks if the variable given as its argument is set
and reads the value if so, overriding any existing value. If the environment variable is not set, the variable given on
the left-hand side of the expression is not changed.

To have a value actually inserted, your PHP execution environment (webserver, PHP-FPM) needs to have these variables
set, or you need a mechanism like dotenv to set them in your running TYPO3.

As it is a syntax feature you can use it in both constants and setup plus it gets cached, as opposed to the
getText.getenv feature.

If set true, then this tag must have starting and ending tags in the
correct order. Any tags not in this order will be discarded. Thus
</B><B><I></B></I></B> will be converted to <B><I></B></I>.

Is the value "global" then true nesting in relation to other tags
marked for "global" nesting control is preserved. This means that if
<B> and <I> are set for global nesting then this string
</B><B><I></B></I></B> is converted to <B></B>

This property is checked after all other properties. If set, it
negates the result, which is present before its execution.

So if all other conditions, which were used, returned true, with
this property the overall return ends up being false. If at least
one of the other conditions, which were used, returned false, the
overall return ends up being true.

The "if"-function is a very odd way of returning true or false!
Beware!

"if" is normally used to decide whether to render an object or to return
a value (see the cObject and stdWrap).

Here is how it works:

The function returns true or false. Whether it returns true or false
depends on the properties of this function. Say if you set isTrue=1
then the result is true. If you set isTrue.field=header, the
function returns true if the field "header" in $cObj->data is set!

If you want to compare values, you must load a base-value in the
value-property. Example:

.value =10.isGreaterThan =11

This would return true because the value of isGreaterThan is
greater than 10, which is the base-value.

More complex is this:

.value =10.isGreaterThan =11.isTrue.field = header
.negate =1

There are two conditions - isGreaterThan and isTrue.
If they are both true, the total is true (both are connected with an AND).
BUT(!) then the result of the function in total would be false because the
negate-flag inverts the result!

sample is a switch which determines how the image
processor (often GraphicsMagick or ImageMagick) calculates the preview
image. If sample is true then - sample is used with
GraphicsMagick or ImageMagick instead of - geometry to calculate the
preview image. sample does not use antialiasing and is therefore
much faster than the geometry procedure of
GraphicsMagick or ImageMagick.

This specifies the target attribute of the link. The attribute
will only be created if the current Doctype
allows it. Needs JSwindow = 1. Default: 'thePicture'.

Examples:

# (1) to produce: <a target="preview" ... >imageLinkWrap.target = preview
# (2) to use the default: <a target="thePicture" ...>// do nothing - use the built in default value of ".target"# (3) to use a new window for each image# let there be: <a target="<hash-code>" ... >imageLinkWrap.JSwindow =1imageLinkWrap.JSwindow.newWindow =1

If the Doctype allows the target
attribute then the image will be opened in a window with the name given
by target. If that windows is kept open and the next image with the
same target attribute is to be shown then it will appear
in the same preview window.
If JSwindow.newWindow is set to True,
then a unique hash value is used as target value for each image.
This guarantees that each image is opened in a new window.

When the direct link for the preview image is calculated all
attributes of linkParams are used as settings for the
typolink function. In other words: Use the same parameters
for linkParams that you would use for typolink.
Needs JSwindow = 0.

If set to True (= 1) then this function attaches a link to an image
that opens a special view of the image. By default the link points to
the a "showpic" script that knows how to deal with several parameters.
The script checks an md5-hash to make sure that the parameters are unchanged.
See Basic example: Create a link to the showpic script.

There is an alternative. You may set directImageLink to True
(= 1). In that case the link will directly point to the image
- no intermediate script is involved. This method can well be used to display
images in a lightbox. See Basic example: Link directly to the original image
and the lightbox examples on this page.

If JSwindow is True (= 1) more fancy
features are available since the preview now is opened by Javascript.
Then the Javascript window title, size, background-color and more can be set to
special values.

10=IMAGE10{# point to the image
file =fileadmin/demo/lorem_ipsum/images/a4.jpg# make it rather small
file.width =80# add a link to tx_cms_showpic.php that shows the original imageimageLinkWrap=1imageLinkWrap{
enable =1# JSwindow = 1}}

page=PAGEpage.10=IMAGEpage.10{# the relative path to the image# find the images in the 'lorem_ipsum' extension an copy them here
file =fileadmin/demo/lorem_ipsum/images/b1.jpg# let's make the normal image small
file.width =80# yes, we want to have a preview link on the imageimageLinkWrap=1imageLinkWrap{# must be TRUE for anything to happen
enable =1# "m" = at most 400px wide - keep proportions
width =400m
# "m" = at most 300px high - keep proportions
height =300# let's use fancy Javascript features
JSwindow =1# black background
bodyTag =<bodystyle="background-color:black;margin:0;padding:0;"># place a Javascript "close window" link onto the image
wrap =<ahref="javascript:close();">|</a># let there be a new and unique window for each image
JSwindow.newWindow =1# make the preview window 30px wider and 20px higher# than what the image requires
JSwindow.expand =30,20}

Target file extension for the processed image. The value web checks if
the file extension is one of gif, jpg, jpeg, or png and if not it will find
the best target extension. The target extension must be in the list of file
extensions perceived as images. This is defined in
$GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] in the install
tool.

If both the width and the height are set and one of the numbers is
appended by an m, the proportions will be preserved and thus
width and height are treated as maximum dimensions for the image. The
image will be scaled to fit into the rectangle of the dimensions
width and height.

If both the width and the height are set and at least one of the
numbers is appended by a c, crop-scaling will be enabled. This means
that the proportions will be preserved and the image will be scaled to
fit around a rectangle with width/height dimensions. Then, a
centered portion from inside of the image (size defined by
width/height) will be cut out.

The c can have a percentage value (-100 ... +100) after it, which
defines how much the cropping will be moved off the center to the
border.

Notice that you can only use either morc at the same time!

Examples

This crops 120x80px from the center of the scaled image:

.width =120c
.height =80c

This crops 100x100px; from landscape-images at the left and portrait-
images centered:

.width =100c-100
.height =100c

This crops 100x100px; from landscape-images a bit right of the center
and portrait-images a bit higher than centered:

If set, the image itself will never be scaled. Only width and height
are calculated according to the other properties, so that the image is
displayed resized, but the original file is used. Can be used for
creating PDFs or printing of pages, where the original file could
provide much better quality than a rescaled one.

It is possible to define an area that should be taken (cropped) from the image.
When not defined in typoscript the value will be taken from the file_reference when
possible. With this setting you can override this behavior.

Default

not-set (when file/image is a file_reference the crop value of
the file reference is used)

HTMLtableCells.addChr10BetweenParagraphs:boolean. If set, then
all appearances of </P><P> will have a chr(10) inserted between them.

}

Example

This example is used to split regular bodytext content so that tables
and blockquotes in the bodytext are processed correctly. The
blockquotes are passed into parseFunc again (recursively) and further
their top/bottom margins are set to 0 (so no apparent line breaks are
seen)

The tables are also displayed with a number of properties of the cells
overridden.

plainTextStdWrap works an ALL non-tag pieces in the text.
nonTypoTagStdWrap is post processing of all text
(including tags) between special TypoTags
(unless breakoutTypoTagContent is not set for the TypoTag).

Like userFunc.
Differences is (like nonTypoTagStdWrap)
that this is post processing of all content pieces around TypoTags while
userFunc processes all non-tag content.
(Notice: breakoutTypoTagContent must be set for the TypoTag
if it's excluded from nonTypoTagContent).

This object performs an ordered search and replace operation on the
current content with the possibility of using PCRE regular expressions.
An array with numeric indices defines the order of actions and thus
allows multiple replacements at once.

This property allows to use optionSplit for the replace
property. That way the replace property can be different depending on the
occurrence of the string (first/middle/last part, ...). This works for
both normal and regular expression replacements. For examples see below.

Comma-separated list of pids of the record. This will be page uids (pids). For
example when the select function works on the table tt_content, then this
will be pids of tt_content records, the parent pages of these records.

Pages in the list, which are not visible for the website user, are
automatically removed from the list. Thereby no records from hidden,
timed or access-protected pages will be selected! Nor will be records
from recyclers. Exception: The hidden pages will be listed in preview mode.

Special keyword:this

Is replaced with the id of the current page.

Special keyword:root

Allows to select records from the root-page level (records with pid=0,
e.g. useful for the table "sys_category" and others).

If content language overlay is activated and the option languageField is not disabled,
includeRecordsWithoutDefaultTranslation allows to additionally fetch records,
which do not have a parent in the default language.

The markers defined in this section can be used, wrapped in the usual
###markername### way, in any other property of select. Each value is
properly escaped and quoted to prevent SQL injection problems. This
provides a way to safely use external data (e.g. database fields,
GET/POST parameters) in a query.

This example selects all records from table tt_content, which are on page 73 and
which don't have the header set to the value provided by the Get/Post variable
"first", ordered by the content of the column "sorting".

This is an example of TypoScript code that imports the content of
field "bodytext" from the $cObj->data-array (ln 2). The content is
split by the line break character (ln 4). The items should all be
treated with a stdWrap (ln 5) which imports the value of the item (ln
6). This value is wrapped in a table row where the first column is a
bullet-gif (ln 7). Finally the whole thing is wrapped in the proper
table-tags (ln 9). :

Here the content of the object "10" is uppercased before it is
returned.

stdWrap properties are executed in the order they appear in the table
below. If you want to study this further please refer to
typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php,
where you will find the function stdWrap() and the array $stdWrapOrder,
which represents the exact order of execution.

Note that the stdWrap property "orderedStdWrap" allows you to execute
multiple stdWrap functions in a freely selectable order.

The properties in this table are parsed in the listed order. The
properties data, field, current, cObject
(in that order!) are special as they are used to import content
from variables or arrays. The above example could be rewritten to this:

Calls the provided PHP function. If you specify the name with a '->'
in it, then it is interpreted as a call to a method in a class.

Two parameters are sent to the PHP function: As first parameter a
content variable, which contains the current content. This is the
value to be processed. As second parameter any sub-properties of
preUserFunc are provided to the function.

This flag requires the content to be set to some value after any
content-import and treatment that might have happened until now
(data, field, current, listNum, trim). Zero is not regarded as
empty! Use "if" instead!

Note: If you enter a string as value, this will be taken as a
reference to an object path globally in the TypoScript object tree.
This will be the basis configuration for parseFunc merged with any
properties you add here. It works exactly like references does for
content elements.

Example

parseFunc= < lib.parseFunc_RTE
parseFunc.tags.myTag =TEXTparseFunc.tags.myTag.value = This will be inserted when &lt;myTag&gt; is found!

Performs an ordered search/replace on the current content with the
possibility of using PCRE regular expressions. An array with numeric
indices defines the order of actions and thus allows multiple
replacements at once.

Calculation of the value using operators -+*/%^ plus respects
priority to + and - operators and parenthesis levels ().

. (period) is decimal delimiter.

Returns a doublevalue.

If prioriCalc is set to "intval" an integer is returned.

There is no error checking and division by zero or other invalid
values may generate strange results. Also you should use a proper syntax
because future modifications to the function used may allow for more
operators and features.

Content is set to chr(*value*). This returns a one-character
string containing the character specified by ascii code. Reliable
results will be obtained only for character codes in the integer
range 0 - 127. See
the PHP manual:

This is for number values. When the 'bytes' property is added and set
to 'true' then a number will be formatted in 'bytes' style with two
decimals like '1.53 KiB' or '1.00 MiB'.
Learn about common notations at
Wikipedia "Kibibyte".
IEC naming with base 1024 is the default. Use sub-properties for
customisation.

.labels = iec

This is the default. IEC labels and base 1024 are used.
Built in IEC labels are "|Ki|Mi|Gi|Ti|Pi|Ei|Zi|Yi".
You need to append a final string like 'B' or '-Bytes' yourself.

.labels = si

In this case SI labels and base 1000 are used.
Built in IEC labels are "|k|M|G|T|P|E|Z|Y".
You need to append a final string like 'B' yourself.

.labels = "..."

Custom values can be defined as well like with
.labels="Byte|Kilobyte|Megabyte|Gigabyte". Use a
vertical bar to separate the labels. Enclose the whole string in
double quotes.

.base = 1000

Only with custom labels you can choose to set a base of1000. All
other values, including the default, mean base 1024.

Attention

If the value isn't a number the internal PHP function may issue a
warning which - depending on you error handling settings - can
interrupt execution. Example:

Crops the content to a certain length. In contrast to stdWrap.crop it
respects HTML tags. It does not crop inside tags and closes open tags.
Entities (like ">") are counted as one char. See stdWrap.crop below
for a syntax description and examples.

Note that stdWrap.crop should not be used if stdWrap.cropHTML is
already used.

You can define up to three parameters, of which the third one is
optional. The syntax is:
[numbers of characters to keep] | [ellipsis] | [keep whole words]

numbers of characters to keep (integer): Define the number of characters
you want to keep. For positive numbers, the first characters from the
beginning of the string will be kept, for negative numbers the last
characters from the end will be kept.

ellipsis (string): The signs to be added instead of the part, which was
cropped of. If the number of characters was positive, the string will
be prepended with the ellipsis, if it was negative, the string will
be appended with the ellipsis.

keep whole words (boolean): If set to 0 (default), the string is always
cropped directly after the defined number of characters. If set to 1,
only complete words are kept. Then a word, which would normally be cut
in the middle, is removed completely.

Examples

20|... => max 20 characters. If more, the value will be truncated
to the first 20 characters and prepended with "..."

-20|... => max 20 characters. If more, the value will be truncated
to the last 20 characters and appended with "..."

20|...|1 => max 20 characters. If more, the value will be
truncated to the first 20 characters and prepended with "...". If
the division is in the middle of a word, the remains of that word is
removed.

Encodes content to be used safely inside strings in JavaScript.
Characters, which can cause problems inside JavaScript strings, are
replaced with their encoded equivalents. The resulting string is
not enclosed in quotes. If needed, quotes can be added using
TypoScript.

Passes the content through the core function
\TYPO3\CMS\Core\Utility\GeneralUtility::quoteJSvalue.

This wraps the content without trimming the values. That means that
surrounding whitespaces stay included! Note that this kind of wrap
does not only need a special character in the middle, but that it also
needs the same special character to begin and end the wrap (default
for all three is "|").

Additional property:

splitChar

Can be set to define an alternative special character. stdWrap is
available. Default is "|" - the vertical line. This sub-property is
useful in cases when the default special character would be recognized
by optionSplit (which takes precedence over noTrimWrap).

Example

noTrimWrap =| val1 | val2 |

In this example the content with the values val1 and val2 will be
wrapped; including the whitespaces.

Execute multiple stdWrap statements in a freely selectable order. The order
is determined by the numeric order of the keys. This allows to use multiple
stdWrap statements without having to remember the rather complex sorting
order in which the stdWrap functions are executed.

In this example orderedStdWrap is executed on the value "a".
10.innerWrap is executed first, followed by 10.wrap.
Then the next key is processed which is 20. Afterwards 30.wrap
is executed on what already was created.

Calls the provided PHP function. If you specify the name with a '->'
in it, then it is interpreted as a call to a method in a class.

Two parameters are sent to the PHP function: As first parameter a
content variable, which contains the current content. This is the
value to be processed. As second parameter any sub-properties of
postUserFunc are provided to the function.

The description of the cObjectUSER contains some
more in-depth information.

Your methods will get the parameters $content and $conf
(in that order) and need to return a string.

namespaceYour\NameSpace;/** * Example of a method in a PHP class to be called from TypoScript * */classYourClass{/** * Reference to the parent (calling) cObject set from TypoScript */public$cObj;/** * Custom method for data processing. Also demonstrates how this gives us the ability to use methods in the parent object. * * @param string When custom methods are used for data processing (like in stdWrap functions), the $content variable will hold the value to be processed. When methods are meant to just return some generated content (like in USER and USER_INT objects), this variable is empty. * @param array TypoScript properties passed to this method. * @return string The input string reversed. If the TypoScript property "uppercase" was set, it will also be in uppercase. May also be linked. */publicfunctionreverseString($content,$conf){$content=strrev($content);if(isset($conf['uppercase'])&&$conf['uppercase']==='1'){// Use the method caseshift() from ContentObjectRenderer.php.$content=$this->cObj->caseshift($content,'upper');}if(isset($conf['typolink'])){// Use the method getTypoLink() from ContentObjectRenderer.php.$content=$this->cObj->getTypoLink($content,$conf['typolink']);}return$content;}}

For page.10 the content, which is present when postUserFunc is
executed, will be given to the PHP function
reverseString(). The result will be "!DLROW OLLEH".

The content of page.20 will be processed by the function
reverseString() from the class YourClass. This also returns
the text "!DLROW OLLEH", but wrapped into a link to the page
with the ID 11. The result will be <ahref="index.php?id=11">!DLROWOLLEH</a>.

Note how in the second example $cObj, the reference to the
calling cObject, is utilised to use functions from
ContentObjectRenderer.php!

Calls the provided PHP function. If you specify the name with a '->'
in it, then it is interpreted as a call to a method in a class.

Two parameters are sent to the PHP function: As first parameter a
content variable, which contains the current content. This is the
value to be processed. As second parameter any sub-properties of
postUserFuncInt are provided to the function.

The result will be rendered non-cached, outside the main
page-rendering. Please see the description of the cObjectUSER_INT.

Possible values are 1, 0 and -1. If set (1), the icon will be inserted
before the last HTML tag in the content. If -1, the icon will be prepended
to the content. If zero (0), the icon is appended in the end of the
content.

.styleAttribute: String.

Adds a style-attribute to the icon image with this value. For instance you
can set "position:absolute" if you want a non-destructive insertion of the
icon. Notice: For general styling all edit icons has the class
"frontEndEditIcons" which can be addressed from the stylesheet of the
site.

.iconTitle: String.

The title attribute of the image tag.

.iconImg: HTML.

Alternative HTML code instead of the default icon shown. Can be used to
set another icon for editing (for instance a red dot or otherwise... :-)

Example

This will insert an edit icon which links to a form where the header
and bodytext fields are displayed and made available for editing
(provided the user has access!).

editIcons = tt_content: header, bodytext

Or this line that puts the header_align and date field into a
"palette" which means they are displayed on a single line below the
header field. This saves some space.

The character(s) to pad with. The value of padWith may be
truncated, if the required number of padding characters cannot
be evenly divided by the length of the value of padWith. Note
that leading and trailing spaces of padWith are stripped! If
you want to pad with spaces, omit this option.

page.10=TEXTpage.10.value = Link to the page with the ID in the current language
page.10.typolink.parameter =23page.20=TEXTpage.20.value = Link to the page with the ID in the language 3page.20.typolink.parameter =23page.20.typolink.language =3

If set, the additionalParams list is exploded and calculated into a
hash string appended to the URL, like "&cHash=ae83fd7s87". When the
caching mechanism sees this value, it calculates the same value on the
server based on incoming values in HTTP_GET_VARS, excluding
id, type, no_cache, ftu, cHash, MP values. If the incoming cHash value
matches the calculated value, the page may be cached based on this.

The $GLOBALS['TYPO3_CONF_VARS']['SYS']['encryptionKey']
is included in the hash in order to make it unique for the
server and non-predictable.

Add the QUERY_STRING to the start of the link. Notice that this does
not check for any duplicate parameters! This is not a problem: Only
the last parameter of the same name will be applied.

.method

If set to GET or POST, then the parsed query arguments
(GET or POST data) will be used. This setting is useful, if you use
URL processing extensions like Real URL, which translate part of the
path into query arguments.

It's also possible to get both, POST and GET data, on setting this to

"POST,GET" or "GET,POST". The last method in this sequence takes
precedence and overwrites the parts that are also present for the
first method.

.exclude

List of query arguments to exclude from the link. Typical examples
are 'L' or 'cHash'.

Attention

This property should not be used for cached contents without a valid
cHash. Otherwise the page is cached for the first set of parameters
and subsubsequently taken from the cache no matter what parameters
are given. Additionally the security risk of cache poisoning has to
be considered.

This is the main data that is used for creating the link. It can be
the id of a page, the URL of some external page, an email address or
a reference to a file on the server. On top of this there can be
additional information for specifying a target, a class and a title.
Below are a few examples followed by full explanations.

Examples

Most simple. Will create a link to page 51 (if this is not default language,
the correct target language will be resolved from the parameter):

parameter = t3://page?uid=51

A full example. A link to page 51 that will open in a new window.
The link will have a class attribute with value "specialLink" and a
title attribute reading "Very important information":

As you can see from the examples, each significant part of the
parameter string is separated by a space. Values that can themselves
contain spaces must be enclosed in double quotes. Each of these values
are described in more detail below.

Resource reference

The link

The first value is the destination of the link. It may start with:

t3://: internal TYPO3 resource references.
See Resource references for an in depth explanation on the
syntax of these references.

http(s)://: regular external links

mailto:info@typo3.org: regular mailto links

It's also possible to direct the typolink to use a custom function (a
"link handler") to build the link. This is described in more detail
below.

Target or popup settings

Targets are normally as described above (extTarget, fileTarget,
target). But it is possible to override them by explicitly defining
a target in the parameter property. It's possible to use a dash (-)
to skip this value when one wants to define a third or fourth
value, but no target.

Instead of a target, this second value can be used to define the
parameters of a JavaScript popup window into which the link will be
opened (using window.open). The height and width of the window can be
defined, as well as additional parameters to be passed to the
JavaScript function. Also see property "Jswindow".

Examples

Open page 51 in a popup window measuring 400 by 300 pixels:

typolink.parameter =51400x300

Open page 51 in a popup window measuring 400 by 300 pixels. Do
not make the window resizable and show the location bar:

typolink.parameter =51400x300:resizable=0,location=1

Class

The third value can be used to define a class name for the link tag.
This class is inserted in the tag before any other value from the
"ATagParams" property. Beware of conflicting class attributes. It's
possible to use a dash (-) to skip this value when one wants to define
a fourth value, but no class (see examples above).

Title

The standard way of defining the title attribute of the link would
be to use the title property or even the ATagParams
property. However it can also be set in this fourth value, in which
case it will override the other settings. Note that the title
should be wrapped in double quotes (") if it contains blanks.

Attention: When used from parseFunc, the value should not
be defined explicitly, but imported like this:

A feature allows you to register a link handler
for a keyword you define. For example, you can link to a page with id
34 with "<link 34>" in a typical bodytext field which converts <link>
tags with "->typolink". But what if you have an extension,
"pressrelease", and wanted to link to a press release item displayed
by a plugin on some page you don't remember? With this feature it's
possible to create the logic for this in that extension.

So, in a link field (the "parameter" value for ->typolink) you could
enter "pressrelease:123":

Some TypoScript will usually transfer this value to the "parameter"
attribute of the ->typolink call. When "pressrelease:123" enters
->typolink as the "parameter" it will be checked if "pressrelease" is
a keyword with which a link handler is associated and if so, that
handler is allowed to create the link.

In this function, the value part after the keyword is set as the value
of a GET parameter, &tx_pressrelease[showUid] and the "parameter"
value of a new ->typolink call is set to "34" which assumes that on
page ID 34 a plugin is put that will display pressrelease 123 when
called with &tx_pressrelease[showUid]=123. In addition you can see
the "userCacheHash" attribute for the typolink function used in order
to produce a cached display.

These top-level object names are reserved. That means you can risk
static_templates to use them:

plugin is used for rendering of special content like boards,
e-commerce solutions, guestbooks and so on. Normally set from
static_templates.

tt_, e.g. tt_content (from "content (default)") is used to
render content from tables.

temp and styles are used for code-libraries you can
copy during parse-time, but they are not saved with the template in
cache. temp and styles are unset before the template is
cached! Therefore use these names to store temporary data.

lib can be used for a "library" of code, you can reference in
TypoScript (unlike styles which is unset).

This is used for extensions in TYPO3 set up as frontend plugins.
Typically you can set configuration properties of the plugin here. Say
you have an extension with the key "myext" and it has a frontend
plugin named "tx_myext_pi1" then you would find the TypoScript
configuration at the position plugin.tx_myext_pi1 in the object
tree!

Most plugins are USER and USER_INT objects
which means that they have at least 1 or 2 reserved properties.
Furthermore this table outlines some other default properties.
Generally system properties are prefixed with an underscore:

Use this to have some default CSS styles inserted in the header
section of the document. _CSS_DEFAULT_STYLE outputs a set of
default styles, just because an extension is installed. Most likely
this will provide an acceptable default display from the plugin, but
should ideally be cleared and moved to an external stylesheet.

This value is for all plugins read by the PageGenerator script when
making the header of the document.

This is e.g. used by css_styled_content and indexed_search. Their
default styles can be removed with:

Use this to have some page-specific CSS styles inserted in the header
section of the document. _CSS_PAGE_STYLE can be used to render
certain styles not just because an extension is installed, but only in
a special situation, e.g. some styles will be output, when
css_styled_content is installed and a textpic element with an
image positioned alongside the text is present on the current page.
Most likely this will provide an acceptable display from the plugin
especially for this page, but should ideally be cleared and moved to
an external stylesheet.

This value is for all plugins read by the PageGenerator script when
making the header of the document.

All variables, which are used inside an extension with
$this->pi_getLL('list_mode_1','Text,ifnoentryinlocallang.xlf',true);
can that way be overwritten with TypoScript. The locallang.xlf file in
the plugin folder in the file system can be used to get an overview of
the entries the extension uses.

If this value is set, then all relative links in TypoScript are
prepended with this string.

Special keyword: "auto" lets TYPO3 autodetect the site root based
on path prefixes (and not based on host name variables from the
server, making this value safe for multi-domain environments).

Note: Using an URI in absRefPrefix will require additional conditions
if you use different domains for your deployment stages in CI environments.

Note: If you're working on a server where you have different domain
names or different path segments leading to the same page (e.g. for internal
and external access), you might do yourself a favor and set absRefPrefix to
the URL and path of your site, e.g. https://typo3.org/. If you do not,
you risk to render pages to cache from the internal network and thereby
prefix image-references and links with a wrong path or a path not accessible
from outside.

By default TYPO3 sends a "Content-Type" header with the defined
encoding, unless this is disabled using disableCharsetHeader.
It then sends cache headers, if configured via sendCacheHeaders.
Then additional headers are send, plus finally a "Content-Length"
header, if enabled via enableContentLengthHeader.

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>=<tablename>:<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.

Examples

config.cache.10= fe_users:2

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

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

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

config.cache.all = fe_users:2

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

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'].

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'].

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'].

Using the "Show content from this page instead" feature allows you to
insert content from the current domain only. Setting this option will
allow content included from anywhere in the page tree!

Another use case is mount points: By means of the page type "Mount Point" you can virtually
insert a whole subtree from somewhere else by just pointing to it. However, usually this
only works within the page tree of the given domain. Setting
config.content_from_pid_allowOutsideDomain=1 removes that restriction.

Exceptions which occur during rendering of content objects (typically plugins)
will now 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.

Important

Instead of breaking the whole page when an exception occurs, an error message
is shown for the part of the page that is broken.
Be aware that unlike before, it is now possible that a page with error message gets cached.

To get rid of the error message not only the actual error needs to be fixed,
but the cache must be cleared for this page.

Examples

# Use 1 for the default exception handler (enabled by default in production context)config.contentObjectExceptionHandler =1# Use a class name for individual exception handlersconfig.contentObjectExceptionHandler = TYPO3\CMS\Frontend\ContentObject\Exception\ProductionExceptionHandler
# Customize the error message. A randomly generated code is replaced within the message if needed.config.contentObjectExceptionHandler.errorMessage = Oops an error occurred. Code:%s
# Configure exception codes which will not be handled, but bubble up again (useful for temporary fatal errors)tt_content.login.20.exceptionHandler.ignoreCodes.10=1414512813# Disable the exception handling for an individual plugin/ content objecttt_content.login.20.exceptionHandler =0# ignoreCodes and errorMessage can be both configured globally …config.contentObjectExceptionHandler.errorMessage = Oops an error occurred. Code:%s
config.contentObjectExceptionHandler.ignoreCodes.10=1414512813# … or locally for individual content objectstt_content.login.20.exceptionHandler.errorMessage = Oops an error occurred. Code:%s
tt_content.login.20.exceptionHandler.ignoreCodes.10=1414512813

If this is set, none of the features of the PAGE object is processed
and the content of the page will be the result of the cObject array
(1,2,3,4...) of the PAGE object. This means that the result of the
cObject should include everything from the <HTML> .... to the </HTML>
tag!

Use this feature in templates supplying other content-types than HTML.
That could be an image or a WAP-page!

TYPO3 by default sends a Content-language:XX HTTP header,
where "XX" is the ISO code of the according language.

For the default language (sys_language_uid = 0), this header is based
on the value of config.sys_language_isocode_default. If this is unset,
config.language is used. If that is unset as well, it finally falls
back to "en".

For other languages, it uses the value from language_isocode from
sys_language. That value may be overwritten by config.sys_language_isocode.

If set, the order of <?xml...> and <!DOCTYPE...> will be reversed.
This is needed for MSIE to be standards compliant with XHTML.

Background:

By default TYPO3 outputs the XML/DOCTYPE in compliance with the
standards of XHTML. However a browser like MSIE will still run in
"quirks-mode" unless the <?xml> and <DOCTYPE> tags are ordered
opposite. But this breaks CSS validation...

With this option designers can decide for themselves what they want
then.

If you want to check the compatibility-mode of your webbrowser you can
do so with a simple JavaScript that can be inserted on a TYPO3 page
like this:

If the 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.

"&ftu=[hash]" is always inserted in the links on the first page a user
hits. If it turns out in the next hit that the user has cookies
enabled, this variable is not set anymore as the cookies does the job.
If no cookies is accepted the "ftu" remains set for all links on the
site and thereby we can still track the user.

You should not set this feature if grabber-spiders like Teleport are
going to grab your site!

You should not set this feature if you want search-engines to index
your site.

You can also ignore this feature if you're certain, website users will
use cookies.

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.

The value must correspond to the key used for the backend system language if
there is one. See inside typo3/sysext/core/Classes/Localization/Locales.php
or look at the translation page on typo3.org for the official 2-byte key for
a given language. Notice that selecting the official key is important if you
want to get labels in the correct language from "locallang" files.

If the language you need is not yet a system language in TYPO3 you can
use an artificial string of your choice and provide values for it via
the TypoScript template where the property _LOCAL_LANG for most
plugins will provide a way to override/add values for labels. The keys
to use must be looked up in the locallang-file used by the plugin of
course.

If language is used, this can be set to another
language key which will be used for labels if a label was not found
for the main language. For instance a brazil portuguese website might
specify "pt" as alternative language which means the portuguese label
will be shown if none was available in the main language, brazil
portuguese. This feature makes sense if one language is incompletely
translated and close to another language.

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.

Note

Do not include the type parameter in the linkVars
list, as this can result in unexpected behavior.

Examples

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.

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.

The signs which should be printed in the title tag between the website
name and the page title. If pageTitleSeparator is set, but no
sub-properties are defined, then a space will be added to the end of the
separator. stdWrap is useful to adjust whitespaces at the beginning and
the end of the separator.

Remove CSS generated by _CSS_PAGE_STYLE configuration of extensions.
(_CSS_PAGE_STYLE renders certain styles not just because an
extension is installed, but only in a special situation. E.g. some
styles will be output, when a textpic element with an image
positioned alongside the text is present on the current page.)

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.

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!

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 ("Advanced" page types) 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
spam bots cannot detect them.

If you set this value to a number, then the encryption is simply 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. Now hardcoded range)

Alternatively you can set this value to the keyword "ascii". This way
every character of the "mailto:" address will be translated to a
Unicode HTML notation. Have a look at the example to see how this
works.

Example

mailto:a@b.c will be converted to mailto:&#97;&#64;&#98;&#46;&#99;

The big advantage of this method is that it does not need any
JavaScript!

ISO 639-1 language code for the according language. By default this
is being set by TSFE:sys_language_isocode. The value is derived
from the ISO code that is stored within the sys_language record.
You can override the value, which was retrieved that way, with this
setting.

The ISO code is also used for the language attribute of the HTML tag.
Therefore the setting htmlTag_langKey
is not needed anymore, if it is the same as the ISO code.

Configures what the system should do when a page is not translated
to the requested language.
It is only evaluated when sys_language_uid is greater than 0
and the requested page translation is NOT available.
Internally this setting corresponds to
LanguageAspect->contentId.

The syntax is "[keyword] ; [value]".

Possible keywords are:

[empty] (not set)

If not set and the page is not translated, the system will
behave as if the default language was requested.
In that case both LanguageAspect->contentId
and LanguageAspect->id will be set to 0.

content_fallback

Recommended. The system will always operate
with the selected language even if the page is not translated and has no
page overlay record. This will keep menus etc. translated. However,
the content on the page can still fall back to another language,
defined by the value of this keyword, e.g. content_fallback;1,3,0,
to fall back to the content of sys_language_uid 1, after that to the
content of sys_language_uid 3 and if that is not present either,
to default (0).

Note that the fallback affects all content of the page.
This means that once a translated page record is found in the fallback
chain, the system will try to use this language for the rendering even
if there is no properly translated content.

strict

If the requested translation does not exist the system
will report a Page Not Found (404) error.
Basically this means that all pages with
gray background in the Web > Info / Localization overview module will
fail (they would otherwise fall back to default language in one way
or another).

ignore

The system will stay with the selected language even if
the page is not translated and there is no content available for this
language, so you can handle that situation on your own then.
The system will render the page and the content as if the translation would exist.
Internally LanguageAspect->contentId is set to the value of
LanguageAspect->id.

Defines whether TYPO3 should use the content overlay technique when
fetching translated content. Content overlay means fetching records
from the default language first and then replacing specific fields
with the translation if that is found.

It is only evaluated when LanguageAspect->contentId>0.
Internally it sets the property LanguageAspect->overlayType at a request.
Further calls via $TSFE->sys_page->getRecordOverlay receive this value
to see if overlaying should take place.

The requirements for this is that the table is configured with
languageField and transOrigPointerField in the ['ctrl'] section of
$GLOBALS['TCA']. Also, exclusion of certain fields can be done with the
"l10n_mode" directive in the field-configuration of $GLOBALS['TCA'].

For backend administration this requires that you configure the
"Web > Page" module to display content elements accordingly; That each
default element is shown and next to it any translation found. This
configuration can be done with Page TSconfig for a section of the
website using the object path mod.web_layout.defLangBinding=1.

Possible values:

0

Just fetch records from the selected language as given by
LanguageAspect->contentId.
No overlay will happen, no fetching of the records from the default language.
This boils down to "free mode" language handling. This is the only mode which shows
records without a default language parent.

An exception to this rule can be made with the TypoScript
CONTENT object if you manually set
select.includeRecordsWithoutDefaultTranslation=1.

1

Fetch records from the default language and overlay them with translations.
If a record is not translated the default language will be used.

hideNonTranslated

Fetch records from the default language and overlay
them with translations. If some record is not translated it will not be shown.

This property holds the value of the field "uid" of a record of table "sys_language".
Various parts of the frontend rendering code will select records
which are assigned to this language.
See ->SELECT

Internally this value is used to initialize the TypoScriptFrontendController
LanguageAspect->id property.
The LanguageAspect->contentId property is set based
on the value of the sys_language_uid and other settings like
sys_language_mode.

It is usually resolved internally by a middleware during bootstrap, taking site configuration setting
into account. No manual interference necessary.

Configuration space for extensions. This can be used – for example –
by plugins that need some TypoScript configuration, but that don't
actually display anything in the frontend (i.e. don't receive their
configuration as an argument from the frontend rendering process).

Disclaimer: it must be understood that while link is generated to
another domain, it is still generated in the context of current
domain. No side effects are known at the time of writing of this
documentation but they may exist. If any side effects are found, this
documentation will be updated to include them.

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).

This object can be used to define constants for replacement inside a
parseFunc. If parseFunc somewhere is configured with .constants=1,
then all occurrences of the constant in the text will be substituted
with the actual value. This is useful, if you need one and the same
value at many places in your website. With constants, you can
maintain it easily.

Note

The constants defined here are not the ones, which can be defined
in the constants section of your template and which then in the setup
section can be used as {$myconstant}.

The "id" points to the uid of the page (or the alias). Thus the
page is found.

The "type" is used to define how the page should be rendered. This
is primarily used with different representations of the same content.
Your default page will most likely have type 0 while a JSON stream with the same
content could go with type 1.

A good habit is to use page as the top-level object name for
the content-page on a website.

Most of this code is executed in the PHP script
typo3/sysext/frontend/Classes/Page/PageGenerator.php.

Inserts content in the head section of the website. Could e.g. be Meta
tags.

While you can also use this to include stylesheet references or JavaScript,
you should better use page.includeCSS
and page.includeJS for such files.
Features like file concatenation and file compression will not work on files,
which are included using headerData.

Inserts a stylesheet (just like the stylesheet property), but allows
setting up more than a single stylesheet, because you can enter files
in an array.

The file definition must be a valid resource data type,
otherwise nothing is inserted.

Each file has optional properties:

allWrap: Wraps the complete tag, useful for conditional
comments.

allWrap.splitChar: Defines an alternative splitting character
(default is "|" - the vertical line).

alternate: If set (boolean) then the rel-attribute will be
"alternate stylesheet".

disableCompression: If config.compressCss is enabled, this
disables the compression of this file.

excludeFromConcatenation: If config.concatenateCss is
enabled, this prevents the file from being concatenated.

external: If set, there is no file existence check. Useful for
inclusion of external files.

forceOnTop: Boolean flag. If set, this file will be added on top
of all other files.

if: Allows to define conditions, which must evaluate to TRUE for
the file to be included. If they do not evaluate to TRUE, the file
will not be included. Extensive usage might cause huge numbers of
temporary files to be created. See ->if for details.

import: If set (boolean) then the @import way of including a
stylesheet is used instead of <link>

inline: If set, the content of the CSS file is inlined using
<style> tags. Note that external files are not inlined.

The file definition must be a valid resource data type,
otherwise nothing is inserted. This means that remote files cannot be referenced
(i.e. using https://...), except by using the .external property.

Each file has optional properties:

allWrap: Wraps the complete tag, useful for conditional
comments.

allWrap.splitChar: Defines an alternative
splitting character (default is "|" - the vertical line).

alternate: If set (boolean) then the rel-attribute will be
"alternate stylesheet".

disableCompression: If config.compressCss is
enabled, this disables the compression of this file.

excludeFromConcatenation: If config.concatenateCss
is enabled, this prevents the file from being concatenated.

external: If set, there is no file existence check. Useful for
inclusion of external files.

forceOnTop: Boolean flag. If set, this file will be added on top
of all other files.

if: Allows to define conditions, which must
evaluate to TRUE for the file to be included. If they do not evaluate
to TRUE, the file will not be included. Extensive usage might cause
huge numbers of temporary files to be created. See ->if for details.

import: If set (boolean) then the @import way of including a
stylesheet is used instead of <link>

Inserts one or more (Java)Scripts in <script> tags.
With moveJsFromHeaderToFooter set to TRUE all files
will be moved to the footer.
The file definition must be a valid resource data type,
otherwise nothing is inserted. This means that remote files cannot be referenced
(i.e. using https://...), except by using the .external property.

Each file has optional properties:

allWrap: Wraps the complete tag, useful for conditional
comments.

allWrap.splitChar: Defines an alternative splitting character
(default is "|" - the vertical line).

async: Allows the file to be loaded asynchronously.

crossorigin: Allows to set the crossorigin attribute in script tags.
Is automatically set to anonymous for external JavaScript files if an
.integrity is set.

defer Allows to set the HTML5 attribute defer.

disableCompression: If config.compressJs is enabled,
this disables the compression of this file.

excludeFromConcatenation: If config.concatenateJs is enabled,
this prevents the file from being concatenated.

external: If set, there is no file existence check. Useful for
inclusion of external files.

forceOnTop: Boolean flag. If set, this file will be added on top
of all other files.

if: Allows to define conditions, which must evaluate to TRUE for
the file to be included. If they do not evaluate to TRUE, the file will
not be included. Extensive usage might cause huge numbers of temporary
files to be created. See ->if for details.

type: Setting the MIME type of the script (default: text/javascript).

integrity: Adds the integrity attribute to the script element to let
browsers ensure subresource integrity. Useful in hosting scenarios with
resources externalized to CDN's. See SRI for
more details. Integrity hashes may be generated using https://srihash.org/.

Example

includeJS {
file1 =fileadmin/helloworld.js
file1.type =application/x-javascript# Include a second file, but only if myConstant is set# in the TS constants field.
file2 = javascript_uploaded_to_template*.js
file2.if.isTrue ={$myConstant}}

The file definition must be a valid resource data type,
otherwise nothing is inserted. This means that remote files cannot be
referenced (i.e. using https://...), except by using the .external
property.

Each file has optional properties:

allWrap: Wraps the complete tag, useful for conditional
comments.

allWrap.splitChar: Defines an alternative splitting character
(default is "|" - the vertical line).

async: Allows the file to be loaded asynchronously.

crossorigin: Allows to set the crossorigin attribute in script
tags. Is automatically set to anonymous for external JavaScript
files if an .integrity is set.

defer Allows to set the HTML5 attribute defer.

disableCompression: If config.compressJs is enabled, this
disables the compression of this file.

excludeFromConcatenation: If config.concatenateJs is enabled,
this prevents the file from being concatenated.

.external: If set, there is no file existence check. Useful for
inclusion of external files.

.forceOnTop: Boolean flag. If set, this file will be added on top
of all other files.

.if: Allows to define conditions, which must evaluate to TRUE for the
file to be included. If they do not evaluate to TRUE, the file will not be
included. Extensive usage might cause huge numbers of temporary files to be
created. See ->if for details.

.integrity: Adds the integrity attribute to the script element to let
browsers ensure subresource integrity. Useful in hosting scenarios with
resources externalized to CDN's. See SRI for
more details. Integrity hashes may be generated using https://srihash.org/.

This determines the typeId of the page. The &type= parameter in the URL
determines, which page object will be rendered. The value defaults to 0 for
the first found PAGE object, but it must be set and be unique as
soon as you use more than one such object (watch this if you use frames
on your page)!

value is the content of the meta tag. If the value is empty (after
trimming), the meta tag is not generated.

The key can be the name of any meta tag, for example description or
keywords. If the key is refresh (case insensitive), then the
http-equiv attribute is used in the meta tag instead of the name
attribute.

For each key the following sub-properties are available:

httpEquivalent

If set to 1, the http-equiv attribute is used in the meta
tag instead of the name attribute. Default: 0.

replace

If set to 1, the tag will replace the one set earlier by a plugin. If set
to 0 (default), the meta tag generated by the plugin will be used. If
there is none yet, the one from TypoScript is set.

Examples:

Simple definition:

meta.description = This is the description of the content in this document.
meta.keywords = These are the keywords.

Fetch data from the keywords field of the current or any parent page:

meta.keywords.data = levelfield:-1, keywords, slide

Make a meta.refresh entry:

meta.refresh =[seconds]; [URL, leave blank for same page]

Usage of httpEquivalent:

meta.X-UA-Compatible = IE=edge
meta.X-UA-Compatible.httpEquivalent =1

Result:

<metahttp-equiv="X-UA-Compatible"content="IE=edge">.

Meta tags with a different attribute name are supported like the
Open Graph meta tags:

The content objects (cObjects) are primarily controlled by the PHP-
script "typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php".
The PHP-class is named "ContentObjectRenderer" and often this is also
the variable-name of the objects ($cObj).

The $cObj in PHP has an array, $this->data, which holds records of
various kind. See data type "getText".

This record is normally "loaded" with the record from a table
depending on the situation. Say if you are creating a menu it's often
loaded with the page-record of the actual menu item or if it's about
content-rendering it will be the content-record.

When dealing with "cObjects", you're allowed to use a special syntax
in order to reuse cObjects without actually creating a copy. This has
the advantage of minimizing the size of the cached template. But on
the other hand it does not give you the flexibility of overriding
values.

First lib.stdheader is defined. This is (and must be) a cObject! (In
this case it is COA.)

Now lib.stdheader is copied to tt_content.header.10 with the
"<" operator. This means that an actual copy of lib.stdheader is
created at parsetime.

But this is not the case with tt_content.bullets.10. Here
lib.stdheader is just pointed to and lib.stdheader will be used as the
cObject at runtime.

The reason why lib.stdheader was copied in the first case is the fact
that it's needed to unset ".stdWrap.space" inside the cObject
("10.stdWrap.space >"). This could not be done in the second case
where only a pointer is created.

If lib.stdheader was temp.stdheader instead, the pointer would
not work! This is due to the fact that the runtime-reference would
find nothing in "temp." as this is unset before the template is stored
in cache!

This goes for "temp." and "styles." (see the top-level object
definition elsewhere).

Overriding values anyway:

Although you cannot override values TypoScript-style (using the
operators and all) the properties of the object which has the
reference will be merged with the configuration of the reference.

This is a very flexible object whose rendering can vary depending on a
given key. The principle is similar to that of the "switch" construct
in PHP.

The value of the "key" property determines, which of the provided
cObjects will finally be rendered.

The "key" property is expected to match one of the values found in the
"array of cObjects". Any string can be used as value in this array,
except for those that match another property. So the forbidden values
are: "if", "setCurrent", "key", and "stdWrap". "default" also cannot
be used as it has a special meaning: If the value of the "key"
property is not found in the array of cObjects, then the cObject
from the "default" property will be used.

The key, which determines, which cObject will be rendered. Its
value is expected to match the name of one of the cObjects from
the array of cObjects; this cObject is then rendered. If no name
of a cObject is matched, the cObject from the property "default"
is rendered.

This defines the source of the value that will be matched against
the values of the "array of cObjects". It will generally not be a
simple string, but use its stdWrap properties to retrieve a
dynamic value from some specific source, typically a field of the
current record. See the example below.

Array of cObjects. Use this to define cObjects for the different
values of "key". If "key" has a certain value, the according
cObject will be rendered. The cObjects can have any name, but not
the names of the other properties of the cObject CASE.

Use this to define the rendering for those values of "key" that
do not match any of the values of the "array of cObjects". If no
default cObject is defined, an empty string will be returned for
the default case.

If in this example the field "header" turns out not to be set ("false"), an
empty string is returned. Otherwise TYPO3 chooses between two different
renderings of some content depending on whether the field "layout" is "1"
or not ("default"). The result is in either case wrapped with "|<br>".

stuff =CASE
stuff.if.isTrue.field = header
# This value determines, which of the following cObjects will be rendered.
stuff.key.field = layout
# cObject for the case that field layout is "1".
stuff.1=TEXT
stuff.1{....}# cObject for all other cases.
stuff.default =TEXT
stuff.default {....}
stuff.stdWrap.wrap =|<br>

COA stands for "content object array" and is a cObject, in which you
can place several other cObjects using numbers to enumerate them.

You can also create this object as a COA_INT in which case it works
exactly like the USER_INT object does: It's
rendered non-cached! That way you cannot only render non-cached
USER_INT objects, but COA_INT allows
you to render every cObject non-cached.

This object is designed to generate content by allowing to
finely select records and have them rendered.

What records are visible is controlled by start and end fields and
more standard fields automatically. The internal value SYS_LASTCHANGED
is raised to the maximum timestamp value of the respective records.

See also

The cObject RECORDS in contrast is for displaying
lists of records from a variety of tables without fine graining.

See PHP class \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController\ContentContentObject
for details on code level.

Preamble:

# Note: TypoScript (TS) is just another way to define an array of settings which# is later on INTERPRETED by TYPO3. TypoScript can be written in ANY order# as long as it leads to the same array. Actual execution order is TOTALLY# INDEPENDENT of TypoScript code order.## The order of TS in this example however tries to reflect execution order.# The denoted steps are taking place in that order at execution time.

If set and no content element is found by the select command, the
rootLine will be traversed back until some content is found.

Possible values are -1 (slide back up to the siteroot), 1 (only
the current level) and 2 (up from one level back).

Use -1 in combination with collect.

slide.collect

(integer /stdWrap) If set, all content elements found
on the current and parent pages will be collected. Otherwise, the sliding
would stop after the first hit. Set this value to the amount of levels
to collect on, or use -1 to collect up to the siteroot.

slide.collectFuzzy

(boolean /stdWrap) Only useful in collect mode. If
no content elements have been found for the specified depth in collect
mode, traverse further until at least one match has occurred.

slide.collectReverse

(boolean /stdWrap) Reverse
order of elements in collect mode. If set, elements of the current
page will be at the bottom.

Note: The sliding will stop when reaching a folder.
See $cObj->checkPid_badDoktypeList.