TypoScript By Example¶

This document¶

This document is an introduction to using TypoScript. It tries to get your thoughts aligned with the way TypoScript works. A lot of small examples are used to help you grasp TypoScript little by little preparing you for bigger adventures.

Other documentation¶

A very important document is the TypoScript reference (TSref) , which contains all details on TypoScript. The problem with the reference is that very few examples follow it. So therefore this is a more reader-friendly way to approach TypoScript.

Tutorials

There's a series of tutorials that are very good to follow also.

Content rendering

A separate PDF-document, content_rendering.pdf, with topic on content rendering is available.

Do I need it?¶

Yes. If you are working in the layers above F1 in the Typo3 Overview. But it's certainly up to you how much you want to utilize it. If you find TypoScript very confusing, you'll do fine with a very few options and then render the content with your own PHP-scripts. You can also base your project on a standard template which is a fixed layout but extremely easy to configure for different options.

Overview¶

Normally a "template" is a HTML-file that describes a layout and certain areas that should be substituted with some other content. In Typo3 you can use this approach, even with TypoScript. See the tutorials for more information.

But a "template" or "template record" as refered to in these documents is a record from the database table "sys_template" in Typo3 and the existence of such a record on a certain page defines how the page displays. Thats a template.

In order to understand templates, you should read this introduction to TypoScript. You'll also find thorough information in the TSref.

This page is an overview of the fields of the template-table:

"Template title": The title of the template. This is shown in the recordlist on the web-tab. Choose whatever you like.

"Website title": This is the title of the entire website. This is shown in the HTML-title before the page-titles. Look at this website (typo3): In the titlebar of the browserwindow "Typo3:" is prepended the title of the specific page.

"Constants": The "Constants-field". This is where you put constants that is substituted in the setup-field. Eg. a constant "styles.content.textStyle.size" is inserted in the setup-field as "{$styles.content.textStyle.size}". Constants are substituted in the order they are introduced in this field. It is important to understand that constants are not used as programming variables. They only substitute constants items in Setup. Note that the Constants-field is "summed-up" (concatenated) with previous templates in the rootline and constants-fields from included templates (see below "Clear" (6)).

"Setup": This field contains the TypoScript setup-code. Use constants from the "Constants-field" (3) to insert easily changable properties or global values. Note that the Setup-field is "summed-up" (concatenated) with previous templates in the rootline and Setup- fields from included templates (see below "Clear" (6)).

"Resources": This field may contain media like images, masks, truetype-fonts, stylesheets, html- and text-documents. These can be referenced from within TypoScript (Datatype "resource") and are copied with templates.

When you create a reference to a "resource" do like this: "image*.gif" instead of this: "image.gif". If you use the asterisk, you prepare your template for duplication as "image*.gif" will also match a filename like "image_01.gif" which will be produced when a template is duplicated.

"Clear" and "Rootlevel": "Clear" lets you clear the Constants and/or Setup code of template from earlier in the rootline. For a deeper explanation of this, refer to the TSref.

"Rootlevel" defines, that this point in the page-structure should act as the root (the startpage) of a new website.

"Include static": This lets you include the static templates that comes with Typo3 by default. The order (from top) is the order by which, the templates are included. Static templates are included before the template in the field "Include basis template" (8).

"Include basis template": Here you can include other templates, which you have made yourself. See the case below.

"Template on next level": Here you can include a template that will be included for pages on the next level in the tree-structure!

"Description": Enter your own notes here.

Case: "Include basis template"¶

A nice way to use templates is to create libraries of TypoScript code in a template and then include that template in another template an reuse the TypoScript code. This is the point of static templates.

But static templates cannot be edited. They are distributed with Typo3 and are not subject to change. Only subject to "expand" (new static templates will be written by time). Therefore you have the ability of including templates in templates.

In this example I'll show you how I made the www.typo3.com and www.typo3.dk websites. They are very much alike. Therefore I have created a common template to control the design. But I have also made individual "extensions" with respect to the danish and english language.

In order to share a template between two or more sites, the sites must reside in the same database. This is the case of the Typo3 website in the two languages. The advantages of this is very obvious: All graphics, pages and layout are easy to copy around and maintain when they are accessible from the same Typo3-interface.

Look at the first picture below (click it for a separate window). In the "rootpage" of both the ".com" and ".dk" site there's a template (with "Rootlevel" clicked). Each template includes the main template, which is found in the "Skabeloner"-folder (means "templates" in danish...). The main template controls almost the entire layout of the sites. And each site share this template!!

Now look at the second and third picture below. These are parts of the content in each of the ".com" and ".dk" templates. Here you see some values being overridden. For each site the content of the meta-tags "keywords" and "description" is different. The proper constants are therefore overridden in order to change this. You will also notice that the danish template changes a few other parameters.

This is very interesting. Local changes are possible in one branch of the website while the global layout may still be changed from the main template. This is pretty much how you can utilize the standard templates. They have a set of constants, you may alter in order to customize you site.

Managing the hierarchy of templates¶

You can easyly monitor which templates are included for your site by the Template Analyzer function in the web_ts module:

This shows not only which templates and static_template are included but also in which order (read "from top") they are processed and if any of the templates has switches set like "Clear constants" and "Clear setup".

Case: "Extension"¶

The above examples indirectly showed the strength of extensions; The site-specific changes was extensions (overridden TypoScript or constants) of the main template.

Here I'll show you how the FAQ-pages in the developer-section of this website is created:

First of all I use another kind of header for the FAQ-section. This headertype has a grey box around and you may choose this header for content-items whereever on the site ("Layout 2"). But the default header type is "Layout 1". So for the FAQ-section (the "blueish" pages on the first picture below) I made an extension, that the default header type should be "2" and not "1" for all pages in this section - which means "all pages from FAQ and outwards".

The task is done by creating a new template on the "FAQ"-page. In this template the "Clear"-fields and "Rootline" must not be checked. If they are, the whole website will "start over" from that point instead of being an extension to the original template!

The content of the template is shown on the second picture. As you see the default header type is set to "2" and the default bodytext size is set to "1" (normally "2").

Of course I could change the font-size and header-type for each content-item... but frankly, that's a quite boring way to do it, if you can fix it like this...

Check the FAQ-section and see for yourself! It works. No hassle.

Managing extensions¶

Again the Template Analyzer comes in handy here:

Read more¶

In the TSref there's also an explanation of how templates work.

Introduction¶

Typo3 offers an easy way to create websites and get started with TypoScript. A bunch of standard templates is bundled with Typo3.

Most websites based on Typo3 rely on TypoScript templates. In order to understand templates, you should read this introduction to TypoScript. You'll also find thorough information in the TSref.

If you want to test some of the standard-templates and study live examples, please refer to the demosite at demo.typo3.com.

static_template table¶

The static templates are records from the table "static_template". The records are root-level records, which means they are always found in the root of the pagetree and can only be viewed by administrators. The table is also "read only" (setup in tables.php). This is because "static_template" contains records which are not meant to be changed by anyone. They act as preset chunks of TypoScript code. The table "static_template" is distributed in new versions (with added records) with every Typo3-version.

Below you see the content of the static template as it was in september 2000. This may have changed for the current version of Typo3. But it's useful for explain how it works:

"template: ...": This is the standard templates. When you want to create a website based on a standard-template you add this to the top of the list of included static-templates in your template.

All standard templates includes the "content (default)" template for content-rendering.

"content (default)": This template contains a cObject "tt_content" which is used to render the content-items of a page. Included by all templates so far. Some of the more exotic types (CType) of content- items are not rendered though. "styles.content (default)" is included in this template.

"styles.content (default)": This contains a lot of predefined TS- objects for use with eg. content-rendering, "powered-by"-logos, content-inserting and so on. The objects are widely use by "content (default)" and many properties are adjustable as constants for easy change of behavior.

"cSet (default)": This is kind of extension to the "styles.content (default)" template. The point is to substitute eg. target-definitions in many objects of the "styles.content (default)"-template with a common constant, which makes it much more convenient to adjust the target through all objects. It also takes care of such as background colors, font-faces/colors. It's a layer on top. Very useful for fast creation of websites based on the standard-templates; Include the standard template. Include "cSet (default)". Override some parameters of "cSet. ....". See how it's used in the templates on the demo-site.

"frameset...": Different standard framesets. Used by some standard templates.

"styles...": Some standard objects like menus, sitemaps, headers and so on. This section may grow with lots of interesting presets like boards, catalogues, calender-systems and so on.

Content rendering details¶

Read the PDF-document content_rendering.pdf or refer to

http://www.typo3.com/Content-rendering_an.1102.0.html

Typical setup of a standard template¶

This is the hierarchy of a fictive website based on the standard tempalte BUG:

In the Template Analyzer it looks like this:

A simple website from the ground¶

If you want to start up a website from the ground, you must create a template on the first page of the website. This page may be refered to as "the root of the website" or more commonly the frontpage. The frontpage is not automatically the very first page in the Typo3 pagetree but can be any page in the tree, you want to act as a startingpoint of a website!

The initial template must have the checkboxes "Clear constants and setup" and "Rootlevel" checked. In order to understand this, you must know that templates are read from the root of the pagetree and outwards. This is called the "rootline":

In the picture to the right, the rootline from the page “Experienced we....” (3) goes all the way down to the page “www.typo3.com” (zero). This is because there is a template record on page “www.typo3.com” with the rootlevel flag set (see below). To the left you see how the rootline is represented in a PHP-array internally.

If you meet an expression like “Is page 730 in the rootline?” then the answer is yes in this case, because the page with id 730 (“Introduction”) happens to be the second page in the rootline (at index 1). Please see TSref for more info.

"Rootlevel" defines that the template signifies a start of a new website from the page the template lies on. If you do not set this checkbox, the template acts as an extension to any template in the rootline before it.

"Clear constants" defines that any constants from previous templates in the rootline are cleared before this template is loaded.

"Clear setup" defines that any TypoScript code from previous templates in the rootline are cleared before this template is loaded.

If you try to look at the page at this point, an errormessage appears.

You must write some TypoScript in the fields "Constants" and "Setup". Normally you include some of the static templates to start, but for this example we make a little template from scratch. Write the following in the field "Constants":

bgCol = red

You have now defined a so called constant - "bgCol" - to the value "red". We'll insert this constant in the "setup"-field.

Write the following in the field "Setup":

page = PAGE
page.typeNum = 0

page.bodyTag = <BODY bgColor="{$bgCol}">
page.10 = HTML
page.10.value = Hello World
page.10.value.case = upper

This looks like this in the webbrowser:

This example shows a number of things about TypoScript. Lets start with the first two lines. Here "page" is defined to be a PAGE-object. A required property for a PAGE-object is the value typeNum, which is especially used, when a website uses frames (in that case typeNum would identify the various frames). If typeNum is zero then it just corresponds to a page refered to without the type-value, eg. "?id=51". That's the case for websites without frames.

Another property of a PAGE-object is "bodyTag". Here you enter the body-tag of the page. Please note that the background-color is red because we have inserted the constant from the "Constants"-field.

At last a Content-object of the kind "HTML" is defined. The value is set to "Hello World". This is sent off to the website. But you'll see, that it's shown in upper case as the value and any properties is parsed through the "stdWrap"-function. A property for "stdWrap" is "case" which can be either "upper" or "lower". Take a wild guess what "lower" does...

A website with a little menu¶

Now we'll add a little menu to the website. This menu must be located above the text "Hello World". Now add this in the bottom of the "Setup"-field:

page.5 = HMENU
page.5.1 = TMENU
page.5.1.wrap = | <BR><BR>
page.5.1.NO {
  linkWrap = &nbsp;<font color=yellow> | </font>&nbsp;
  ATagBeforeWrap = 1
}

Here you define a new content-object at position 5 in "page"'s content-array. The object-type is HMENU. HMENU has a numerical array of menu-objects. Here we use "TMENU" as menu-object on the first level. This gives us a textbased menu. For the TMENU-object we set the property "wrap". As you might remember "a wrap" means that it'll be split up by the character "|" and the first two parts will be placed around "something". In this case (page.5.1.wrap = | <BR><BR>) the whole menu is wrapped so that two new lines appear after the menu.

Then some properties is defined for ".NO" under TMENU. ".NO" denotes the setup of menu-items in "normal"-condition. Other conditions could be "ACT" (Active), which means when a menu-item is somewhere in the "path" you're at on the website. For instance you could change the color of the item to white if you want to indicate it visually on the menu-item that a surfer has entered a certain section on the site.

Under ".NO" you define that every menu-item is wrapped in a font-tag making the link yellow. "ATagBeforeWrap" is an option that tells you that the link-tag (<A>) must be wrapped around the menu-item before the font-tag (or else the yellow color will be overridden by the normal tag-color).

Inserting the graphical menu.¶

Instead of the textual menu you just defined, you could insert the graphical menu from the Typo3 website. This would be done by this instead of the previous code:

page.5 < temp.topmenu

Content on the site¶

Now you would like to add content to the website. In the standard TypoScript solution the main content-table is "tt_content". So you add a new content-object of the type CONTENT. You set the property "table" to tt_content.

To configure the sql-select statement you define the property "pidInList" of the "select"-object. When you set it to "this" the pid of the content-records MUST match the id of the current page! "orderBy" is set to "sorting" which is the column in the table tt_content which decides the sorting of the elements.

page.10 = CONTENT
page.10 {
  table = tt_content
  select {
    pidInList = this
    orderBy = sorting
  }
}

In order for this to work, you must define how each content-record is layouted. As default this is defined by the root-object "tt_content".

Here is a short example of TypoScript which would generate the content for the CTypes "header" and "text":

tt_content = CASE
tt_content.key.field = CType

tt_content.header {
  1 = TEXT
  1.field = header
  1.wrap = {$cHeaderWrap}
  1.space = 3 | 2
}

tt_content.text < tt_content.header
tt_content.text {
  3 = TEXT
  3.field = bodytext
  3.fontTag = {$cBodyTextWrap}
  3.br = 1
  3.space = | 10
  3.parseFunc {
    makelinks = 1
    makelinks.http.keep = path
    makelinks.http.wrap = <B>|</B>
    makelinks.mailto.keep = path
    makelinks.mailto.wrap = <FONT color="blue">|</FONT>
    makelinks.mailto.ATagBeforeWrap = 1
  }
}

There are two constants in this case, cBodyTextWrap and cHeaderWrap. These would be defined in the Constants-field in the template and could be value like this:

cHeaderWrap = <FONT face="Verdana" size="3" color="#333333"><B>|</B></FONT>
cBodyTextWrap = <FONT face="verdana" size="2"> | </FONT><BR>

Now, this would give us a size-3 Verdana header in gray and bold. The bodytext would be formatted also with verdana but size 2 and with a <BR>-tag after a section.

Numerical arrays¶

It's neccessary to understand that TypoScript is not a language like javascript. TypoScript is more a list of definitions. The order of the definitions is set by the array numbers. In fact TypoScript is stored in a PHP array. But it's not true that you only store definitions with TypoScript. Because some 'definitions' call real PHP functions (like stdWrap). They can manipulate or even get data for output. That's why TypoScript is much more flexible and powerfull than simple HTML templates.

A good example of properties being a numerical array is the PAGE- object. The point of the pageobject is that it should return some content. In order for it to do so, you must attach some content objects (cObject) to it (see later). A simple cObject is "HTML" or "TEXT". They do the same (but not in the same way).

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world

This (defines a PAGE-object and) outputs the text "hello world" to the browser. The position "10" could have been 934290873 or any integer number. But why "10" then. For me it's tradition, but the point comes now, because if you would like to add some more content to the page, how do you do that? Well, you just add another cObject to the array!

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world
page.20 = TEXT
page.20.value = <BR>Are you listening?

Now why use "20"? Well, use whatever number greater than 10. But leave some "room" for new cObjects between 10 and 20. You never know...

An important thing to understand is that the numerical arrays are always sorted. Non-numerical arrays never have any order attached to them, but numerical arrays have. The consequence of numerical arrays being sorted by their number is that:

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world
page.5 = TEXT
page.5.value = <BR>Are you listening?

... the line"<BR>Are you listening?" is now output before "Hello world" although they are defined in reversed order.

Normally you'll see TypoScript which is nicely coded in the numerical order, but that's just a good habit of the programmer as it's more readable that way.

String arrays¶

Whenever a string-array is defined (like the META object in TypoScript) it's because the keys (elements in the array) are unique and means something. The example with META is good. If you want to put META-tags "description" and "keywords" on your page, do this:

page = PAGE
page.typeNum=0
page.meta.REFRESH =  60; index.php?id=34
page.meta.DESCRIPTION = This is the description of the content in this document
page.meta.KEYWORDS = key, words, ...

This results in this HTML-code in the header of the site (which is very, very blank, if you try this in real life...)

<meta http-equiv="REFRESH" content="60; index.php?id=34">
<meta name="DESCRIPTION" content="This is the description of the content in this document">
<meta name="KEYWORDS" content="key, words, ...">

Example from "content (default)"¶

# CType: image
tt_content.image = COA
tt_content.image {
  10 = < lib.stdheader
  20  < styles.content.imgtext
}

In this example a object from the static_template "styles.content (default)" is copied to the position "tt_content.image.20". That looks like this in the object browser:

Looking in the static_template "styles.content (default)" we see that the object "styles.content.imgtext" is defined like this:

  # imgtext
styles.content.imgtext = IMGTEXT
styles.content.imgtext {
  imgList.field = image
  textPos.field = imageorient
  imgPath = uploads/pics/
  imgObjNum = 1
  1 {
     file.import.current = 1
     file.width.field = imagewidth
     params = align="top"
     imageLinkWrap = 1
    ....
  }
  maxW = {$styles.content.imgtext.maxW}
  maxW.override.data = register:maxImageWidth
....
}

Now, if I want to change the value of "styles.content.imgtext.maxW" to "400", then I have two options. But a very common error here is to try this:

styles.content.imgtext.maxW = 400

See, this will not help you anywhere. The reason is that this changes the value in the object "styles.content.imgtext" and not in " tt_content.image.20" where it's ultimately used in this case. So you can do one of the following.

1) Because "styles.content.imgtext" is copied to "tt_content.image.20" by the "<" operator of TypoScript, any properties of "styles.content.imgtext" are now in "tt_content.image.20" also. Therefore you can change the value this way:

tt_content.image.20.maxW = 400

This is kind of obvious according to the nodetree of the object browser, isn't it?

2) If you change the value of "styles.content.imgtext.maxW" directly, you must also re-copy it to the proper position of it's use:

styles.content.imgtext.maxW = 400
     tt_content.image.20 < styles.content.imgtext

This works also, but be aware that this clears any previous changes made to "tt_content.image.20" (in the manner of method 1 in this example)

I recommend method 1.

Anyway you must be aware that the fine advantage of "styles.content.[xxx]" objects is that they provide default properties that may be used throughout your template. So changing "styles.content.[xxx]" and recopying it one place doesn't bring the change to the other objects that has been based on "styles.content.[xxx]".

For an example, consider " tt_content.textpic.20" which also uses "styles.content.imgtext":

tt_content.textpic = COA
tt_content.textpic {
  10 = COA
  10.if.value = 25
  10.if.isLessThan.field = imageorient
  10.10 = < lib.stdheader

  20  < styles.content.imgtext
  20.text.10 = COA
  20.text.10 {
    if.value = 24
    if.isGreaterThan.field = imageorient
    10 = < lib.stdheader
  }
  20.text.20 = < tt_content.text.20
}

So in order to change the value here also you must add this line:

tt_content.textpic.20.maxW = 400

Now, could you right away do this?

styles.content.imgtext.maxW = 400
     tt_content.image.20 < styles.content.imgtext
     tt_content.textpic.20 < styles.content.imgtext

The answer is "no" in this case, because if you take a look at the TypoScript for tt_content.textpic, the properties of styles.content.imgtext is altered after the object is copied:

...
  20  < styles.content.imgtext
  20.text.10 = COA
  20.text.10 {
    if.value = 24
    if.isGreaterThan.field = imageorient
    10 = < lib.stdheader
  }
  20.text.20 = < tt_content.text.20
...

This situation is generally solved by using the widely implemented constants, and in this specific case you have the opportunity of changing the constant "styles.content.imgtext.maxW".

((generated))¶

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world

page.10 = TEXT
page.10.value = Hello world

page.10 = TEXT
page.10.value = Hello world
page.10.case = upper

...
page.10.case = upper

((generated))¶

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world
page.10.case = upper

page = PAGE
page.typeNum=0
page.10 = HTML
page.10.value = Hello world
page.10.value.case = upper

Get data¶

The primary property here is .field. This fetches the value of the field given by the property. The very good question is, "... value of a field from where, which record?".

The answer is " by default, the page record... " (here "page" refers to the current page, we're on) " ... but 'inside of' CONTENT, RECORD and HMENU cObjects, it's the 'current record' we're dealing with in that particular case ". You'll find notes about this by the object descriptions.

Technically all this is going on in the class tslib_cObj in tslib_content and the 'current record' is defined by cObj->data.

.current - what is that?

Often the "current value" is refered to. Some functions need to pass a single value to the "public" (that's us and stdWrap...) and therefore sets a "register" called "current", the value of which we can easily get by the stdWrap property ".current = 1" (boolean). Whenever the "current" register is used, there will be a notice in the TSref.

page.10 = TEXT
page.10.value = Hello world
page.10.field = title

page.10 = TEXT
page.10.value = Hello world
page.10.field = crdate

page.10 = TEXT
page.10.field = title

page.10 = TEXT
page.10.data = field:title

page.10 = TEXT
page.10.data = global:id

page.10 = TEXT
page.10.data = global:HTTP_GET_VARS|id

page.10 = TEXT
page.10.data = leveltitle:1

Override / Conditions¶

stdWrap provides simple "control structures" by means of comparing properties. To mention some of them, they are named override, ifEmpty, required, if, fieldRequired.

page.10 = TEXT
page.10.value = Hello world
page.10.override = Hello heaven

outputs "Hello heaven" instead becuase if override returns something, the original value is substituted.

page.10 = TEXT
page.10.value = Hello world
page.10.override.field = subtitle

Better example, because now "Hello world" is substituted only if the Subtitle field of the current page record is not blank. In most cases this field is blank, but try "index.php?id=20"...

COA¶

An array of cObjects. A quick demonstration:

page.10 = COA
page.10.10 = TEXT
page.10.10 {
  value = This is the page title:
  wrap = <font face="verdana" size=1>|</font>
  wrap2 = | <BR>
  case = upper
}
page.10.20 = TEXT
page.10.20.field = title

outputs this:

That could fit into one line actually, but whether or not that's an advantage depends on your situation.

page.10 = TEXT
page.10.field = title
page.10.wrap = <font face="verdana" size=1>THIS IS THE PAGE TITLE:</font><BR> |

So lets take another example:

page.10 = COA

# Header to this section
page.10.10 = TEXT
page.10.10 {
  value = This is the page title:
  wrap = <font face="verdana" size=1>|</font>
  wrap2 = | <BR>
  case = upper
}

# Output page title / subtitle
page.10.20 = COA
page.10.20 {
  10 = TEXT
  10.field = title
  10.wrap = Page title: <B> | </B><BR>
  20 = TEXT
  20.field = subtitle
  20.wrap = Subtitle: <B> |</B>
}

outputs this:

FILE¶

This is very simple, so I'll just make a short example:

page.10 = FILE
page.10.file = fileadmin/tsbyex/include_me.txt

outputs:

This is a simple textfile with a few HTML-tags in.

... which is the exact content of the file. Notice that the .file property is a "resource" datatype which means that files must reside in the media/, fileadmin/, uploads/ or typo3temp/ folder. This is a security feature in order to prevent TS-programmers from including everything on the server.

This is technically setup by the array $allowedPaths = Array ("media/","fileadmin/","uploads/","typo3temp/"); from class t3lib_tstemplate

If you include image-files, they are shown as <IMG-tags> instead.

IMAGE¶

Includes an image with <img>-tag.

page.10 = IMAGE
page.10.file = fileadmin/tsbyex/alligator.jpg

page.10 = IMAGE
page.10 {
  file = fileadmin/tsbyex/alligator.jpg
  file.width = 200
  imageLinkWrap = 1
  imageLinkWrap.enable = 1
}

IMG_RESOURCE¶

This does the same as the IMAGE cObject but the very important difference is that the <IMG>-tag is not wrapped around the file.

page.10 = IMG_RESOURCE
page.10 {
  file = fileadmin/tsbyex/alligator.jpg
  file.width = 200
}

typo3temp/3de305c72b.jpg

CLEARGIF¶

Inserts a clear gif-file, clear.gif:

page.10 = CLEARGIF
page.10.width = 200

outputs this HTML -code:

<img src="clear.gif" width=200 height=1 border=0><BR>

Notice the <BR>-tag is always prepended.

You're always free to use the clear.gif file which are found in the root of the site.

HRULER¶

This inserts a horizontal "ruler". Not the HTML-kind, but made with a table and a background color.

page.5 = TEXT
page.5.value = Before ruler

page.10 = HRULER
page.10 {
  lineThickness = 3
  lineColor = red
}

page.15 = TEXT
page.15.value = After ruler

CTABLE and OTABLE¶

These cObjects are meant supply you with quick tables to position your content.

page.10 = OTABLE
page.10 {
  tableParams = border=1
  offset = 10,10
  10 = TEXT
  10.value = What a cute little alligator! Dear Lord, may it never grow up!
  10.wrap = |<BR>
  20 = IMAGE
  20.file = fileadmin/tsbyex/alligator.jpg
  20.file.width=200
}

page.10 = OTABLE
page.10 {
  tableParams = border=0 cellpadding=0 cellspacing=0 width=100
  offset = 10,10
...

page.bodyTagMargins = 0
page.10 = CTABLE
page.10 {
  tableParams = border=1 cellpadding=0 cellspacing=0
  offset = 0,20
  c.10 = TEXT
  c.10.value = CONTENT cell
}

page.bodyTagMargins = 0
page.10 = OTABLE
page.10 {
  tableParams = border=1 cellpadding=0 cellspacing=0
  offset = 0,20
  10 = TEXT
  10.value = CONTENT cell
}

page.bodyTagMargins = 0
page.10 = CTABLE
page.10 {
  tableParams = border=1 cellpadding=0 cellspacing=0
  offset = 0,20
  c.10 = TEXT
  c.10.value = CONTENT cell

  rm.10 = TEXT
  rm.10.value = RIGHT cell

  lm.10 = TEXT
  lm.10.value = LEFT cell

  tm.10 = TEXT
  tm.10.value = TOP cell

  bm.10 = TEXT
  bm.10.value = BOTTOM cell
}

...
  offset = 0,20
  cMargins = 10,20,30,40
  cWidth=300
  rm.TDParams = bgcolor=red valign=bottom
...

TEMPLATE¶

Sometimes you may want to use a HTML template instead of doing it all in TypoScript. This is what the TEMPLATE object is for.

page.10 = TEMPLATE
page.10.template = FILE
page.10.template.file = fileadmin/tsbyex/template.html

...
// End Hiding Script -->
</script>

</head>
<body bgcolor="#FFFFFF">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
  <title>Untitled</title>
</head>
<body>
This is a template that demonstrates the concept of subparts and markers.
<!-- ###DOCUMENT### -->
  This is a <i>###SIMPLE_WORD###</i> textfile with a few HTML-tags in.<br>
  <br>
  Check out the <!--###LINK###-->link to the front page.<!--###LINK###-->
<!-- ###DOCUMENT###-->
</body>
</html>


</body></html>

page.10 = TEMPLATE
page.10.template = FILE
page.10.template.file = fileadmin/tsbyex/template.html
page.10.workOnSubpart = DOCUMENT

...
</head>
<body bgcolor="#FFFFFF">


  This is a <i>###SIMPLE_WORD###</i> textfile with a few HTML-tags in.<br>
  <br>
  Check out the <!--###LINK###-->link to the front page.<!--###LINK###-->

</body></html>

page.10 = TEMPLATE
page.10 {
  template = FILE
  template.file = fileadmin/tsbyex/template.html
  workOnSubpart = DOCUMENT
  marks.SIMPLE_WORD = TEXT
  marks.SIMPLE_WORD.field = title
  subparts.LINK = TEXT
  subparts.LINK.current = 1
  subparts.LINK.debugFunc = 1
}

...
// End Hiding Script -->
</script>

</head>
<body bgcolor="#FFFFFF">


        This is a <i>Content elements</i> textfile with a few HTML-tags in.<br>
        <br>
        Check out the link to the front page.

</body></html>

subparts.LINK = TEXT
subparts.LINK.current = 1
subparts.LINK.debugFunc = 1

...
  subparts.LINK = TEXT
  subparts.LINK.current = 1
  subparts.LINK.typolink {
    parameter = 1
  }
}

...
  subparts.LINK = TEXT
  subparts.LINK.current = 1
  subparts.LINK.typolink {
    parameter.data = leveluid:0
  }
}

FORM¶

Of cource you can create forms manually, but the advantage of letting Typo3 do it is that the syntax is simple enough to teach it to non- techies and you can have it automatically validated (simple way) by JavaScript.

page.10 = FORM
page.10.data = Label | input
page.10.layout = ###LABEL###: ###FIELD###<BR>

page.10 = FORM
page.10.data = Name|input    ||    Address|textarea    ||    Send|submit|Send the form
page.10.layout = ###LABEL###: ###FIELD###<BR>

page.10 = FORM
page.10.data = Name|*input,40 || Address|textarea,40,10 || Send it...|formtype_mail=submit|Send the form || |subject=hidden|This is the subject
page.10.recipient = your@email.com
page.10.layout = ###LABEL###: ###FIELD###<BR>
page.10.locationData = 1
page.10.REQ=1
page.10.REQ.layout = ###LABEL### (Required): ###FIELD###<BR>

CASE¶

This cObject provides yet a "control structure" to TypoScript. It works like a switch-construct:

page.10 = CASE
page.10.key = cheese

page.10.cheese = IMAGE
page.10.cheese {
  file = fileadmin/tsbyex/alligator.jpg
  file.width=200
  wrap = Cheese....  |   is what this guy says
}

page.10.tomatoes = TEXT
page.10.tomatoes.value = Tomatoes are so tasty

page.10.default = TEXT
page.10.default.value = If nothing else is going on, this happens...

temp.cheese = IMAGE
temp.cheese {
  file = fileadmin/tsbyex/alligator.jpg
  file.width=200
  wrap = Cheese....  |   is what this guy says
}

temp.tomatoes = TEXT
temp.tomatoes.value = Tomatoes are so tasty

temp.default = TEXT
temp.default.value = If nothing else is going on, this happens...

page.10 = CASE
page.10.key.data = level:1
page.10.1 < temp.cheese
page.10.2 < temp.tomatoes
page.10.default < temp.default

page.20 = TEXT
page.20.data = level:1
page.20.wrap = <HR> | -
page.30 = TEXT
page.30.field = title

...
page.10.1 < temp.cheese
page.10.2 < temp.tomatoes
page.10.default < temp.default
...

LOAD_REGISTER¶

This cObject does not return any values. Rather you can use it to set some values in the "register". It's a kind of way to pass values around between the TypoScript objects but it is a hack in order to enable just a tiny degree of this. Remember TypoScript is not "executed" like a JavaScript. It's still just a bunch of configuration.

But anyway this example shows how it works:

page.10 = LOAD_REGISTER
page.10.MY_VALUE = The register value!

page.5 = TEXT
page.5.value = The default value
page.5.override.data = register:MY_VALUE
page.5.wrap = | <HR>

page.15 < page.5

This is the result:

Explanation:

Consider the TypoScript:

The object at position "5" in the cObject array of the PAGE object "page" is 'executed" before position "10" which is where the register MY_VALUE is set for the first time. Because the register value until then was empty "page.5" returned the value of the .value property. That was "The default value"

When "page.10" is executed the register-value is set.

When "page.20" is executed, the register is not empty anymore, therefore the value overrides the default value. And the output becomes "The register value!"

Bitmap masks¶

Before we go on, lets have a bit of fun.

We're going to use a bitmap image concept called masking. Basically a mask is a grayscale image used to combine two images in a way where the black and white areas of the mask determines which areas of the two combined images are visible or not.

This is our masks, "mask.jpg":

Now try this:

page.bgImg = fileadmin/tsbyex/sunset_keywest.jpg
page.bgImg.width = 200
page.bgImg.m.bgImg = fileadmin/tsbyex/alligator.jpg
page.bgImg.m.mask = fileadmin/tsbyex/mask.jpg

Result:

Try this

page.bgImg = fileadmin/tsbyex/sunset_keywest.jpg
page.bgImg.width = 300
page.bgImg.m.bgImg = fileadmin/tsbyex/alligator.jpg
page.bgImg.m.bgImg.params = -rotate 90
page.bgImg.m.mask = fileadmin/tsbyex/mask.jpg

Result:

[N/A...]

Import an image¶

OK, we would like the background image to be attached to the individual pages, so we can change the image easily for each page. For that purpose we need to attach the image to the page-record in the media-field.

Do this:

Try to insert this TypoScript on the page:

page.10 =TEXT
page.10.debugData = 1

You should see this when you hit the page (first time, remember it's a debug-output!)

The "media" field contains references to the images by listing them separated by commas. Simple, eh?

We would like to extract a single file from the list, more precisely the second image, "doggiebus.jpg":

page.10 =TEXT
page.10.field = media
page.10.listNum = 1

".listNum" is the great trick here. See the TSref for a description...

All we need now is to know where the images are actually stored, so we can prepend the correct filepath. So we go to the "Tools" module and in the "Configuration" submodule (tools_config), we browse the $tc array:

As you see, the upload path was uploads/media.

In order to use this knowledge with the imgResource, look that the .import property (TSref). From this, we can conclude that the TypoScript should look like:

page.bgImg {
  import = uploads/media/
  import.field = media
  import.listNum = 1
}

Result:

[N/A]

Doggiebus all over. Of course you can still add "page.bgImg.width = 200" if you like a smaller tile for a greater smile :-)

GIFBUILDER basics¶

Back to the basics. The first example showed us how to create a colored box. Now we're going to add some text:

page.10 = IMAGE
page.10.file = GIFBUILDER
page.10.file {
  XY = 200,300
  backColor = olive
  10 = BOX
  10.dimensions = 20,20,160,260
  10.color = green

  20 = TEXT
  20.text = Hello World
  20.offset = 10,10
}

This results in:

+calc¶

Many integet values can be defined by simple arithmetic operations like +, -, / and *. A special feature is that you can insert codes in these expressions that are substituted with the width or height of either a TEXT- or an IMAGE-GIFBUILDER object. In that way we're able to control eg. the width of the image based on the width of the text.

page.10 = IMAGE
page.10.file = GIFBUILDER
page.10.file {
  XY = [20.w]+20, 30
  backColor = olive
  10 = BOX
  10.dimensions = 20,20,160,260
  10.color = green

  20 = TEXT
  20.text = Hello World
  20.offset = 10,15
}

...
  10.dimensions = 11,20,[20.w],1
  10.color = blue

  20 = TEXT
  20.text = Hello World
  20.offset = 10,15
  20.niceText = 1
}

.niceText¶

See, this is a workaround to compensate for the fact that the freetype library used by GDLib in PHP is not always able to provide a satisfying antialias ("soft edges" to prevent the jagged, pixelated edges). So this flag makes Typo3 render the text in double size on a mask-file which is then scaled down to correct size and used with ImageMagick's combine-tool to "superimpose" (mask) the text onto the background. It takes more CPU power. The result is also better (usually).

Left: Normal text. Antialiased by Freetype. Middle: .niceText=1 Right: .antiAlias=0 (Antialias totally disabled)

The GIFBUILDER TEXT object¶

Now, we'll try some more options for the text:

...
  20 = TEXT
  20.text = Hello World
  20.offset = 10,15
  20.niceText = 1
  20.fontSize= 20
  20.fontFile = t3lib/fonts/verdana.ttf
  20.fontColor = #660000
  20.shadow.offset = 2,2
  20.shadow.blur = 60
  20.shadow.opacity = 40
}

results in this:

The IMAGE object¶

You can also add an image to the GIFBUILDER objects.

page.10 = IMAGE
page.10.file = GIFBUILDER
page.10.file {
  XY = 200, [10.h]

  10 = IMAGE
  10.file = fileadmin/tsbyex/sunset_keywest.jpg
  10.file.width= 200

  20 = TEXT
  20.text.field = title
  20.offset = 0,120
  20.niceText = 1
  20.align=center
  20.fontSize= 40
  20.fontFile = t3lib/fonts/verdana.ttf
  20.fontColor = yellow

  30 = IMAGE
  30.file = fileadmin/tsbyex/alligator.jpg
  30.file.width=50
  30.tile = 2,2
  30.align = c,c

}

HMENU¶

The cObject HMENU is used to generate "hierarchical menus" - that is navigation.

page.10 = HMENU
page.10.1 = TMENU
page.10.1.NO {
  linkWrap = <B>|</B><BR>
}

page.10 = HMENU
page.10.entryLevel = 1
page.10.1 = TMENU
page.10.1.NO {
  linkWrap = <B>|</B><BR>
}

TMENU¶

The TMENU is a text-based menu. There are lots of examples around. Look in the static_template table. The "content (default)" template has a bunch of examples attached to the tt_content.menu definition.

Here's an example taken from the static_template "TEMPLATE; BUSINESS":

page.10 = HMENU
page.10.1 = TMENU
page.10.1.target = page
page.10.1 {
  expAll = 1
  wrap = <table width="300" border=1 cellspacing=0 cellpadding=0><tr><td><img src="clear.gif" width=1 hspace=200 height=1 vspace=3 border=0></td></tr> | </table>
  NO.linkWrap = <font face=Arial size=2 color=black><b> |</b></font>
  NO.allWrap = <tr><td><img src="clear.gif" width=1 height=1 vspace=3 border=0><br> | </td></tr>
}
page.10.2 = TMENU
page.10.2 {
  wrap = <tr><td nowrap> | </td></tr>
  target = page
  NO {
    beforeImg =  media/bullets/bullet1_n.gif
    beforeROImg = media/bullets/bullet1_h.gif
    beforeImgTagParams = hspace=2
    RO = 1
    after = <br>
    ATagBeforeWrap = 1
    linkWrap= <font face=Verdana size=1 color=black> | </font>
  }
}

Result:

You should know one thing about the TMENU: There are two properties, .before and .after. They have stdWrap properties both and they are actually identical. But - as stated in the TSref - the cObj->data array used by stdWrap's .field property is not loaded with the page-record of the current menu-item when executed. Originally that was a design error, but the workaround in order to be backwards compatible has been that stdWrap can retrieve the field-values of the menu-item page through the .data-property. So instead of "before.field = title" (which gets the main page title) use "before.data = page:title".

IMGMENU¶

This is an imagemap menu.

temp.topmenu = HMENU
temp.topmenu.1.target = _top
temp.topmenu.maxItems = 6
temp.topmenu.entryLevel = 0
temp.topmenu.1 = IMGMENU
temp.topmenu.1.imgMapExtras = <AREA SHAPE="rect" alt="Frontpage" COORDS="5,5,69,70" href="http://www.typo3.com" target="_top">
temp.topmenu.1 {
  wrap = |<BR>
  main.XY = [10.w] , [10.h]
  main.10 = IMAGE
  main.10.file = fileadmin/tsbyex/imglogo.gif
  main.reduceColors = 16

  dWorkArea = 77,68

  NO.distrib = textX+10, 0
  NO.10 = TEXT
  NO.10 {
    text.field = title
    fontSize = 11
    fontColor = black
    niceText = 1
    offset = 0,0
    imgMap.explode = 3,2
  }
  NO.20 =   || BOX
  NO.20 {
    dimensions = -5,-9,1,11
    color = white
  }
}

page.10 < temp.topmenu

main.

dWorkArea = 77,68

NO.

NO.distrib = textX+10,0

imgMap.explode

temp.topmenu.1.imgMapExtras = <AREA SHAPE="rect" alt="Frontpage" COORDS="5,5,69,70" href="http://www.typo3.com" target="_top">

NO.20 =   || BOX

optionSplit¶

But what is it anyway, optionSplit? Why would I care?

optionSplit is very powerful because it provides a way to set different values for the properties of your menu objects based on whether they are the first, the last or "middle" elements in the menu. optionSplit works on all properties and their values in the TypoScript of a whole menu object!

For instance, if I would like the first element to be yellow, the last element to be blue and any other elements to be white, I can specify the

fontColor = yellow |*| white |*| blue

like that. Result:

If I add another page to the testsite, the menu will be updated accordingly:

GMENU¶

Now lets get on with the GMENU menu object.

page.10 = HMENU
page.10.1 = GMENU
page.10.1.NO {
  XY = [10.w],[10.h]
  backColor = #cccccc || #eeeeee
  10 = TEXT
  10.text.field = title
  10.offset = 0,7
}

page.10 = HMENU
page.10.1 = GMENU
page.10.1.NO {
  XY = [10.w]+20,20
  backColor = |*| #cccccc || #eeeeee |*|
  10 = TEXT
  10.text.field = title
  10.offset = 0,13
  10.align = center
  10.niceText = 1
}

page.10 = HMENU
page.10.1 = GMENU
page.10.1.NO {
  XY = [10.w]+20,20
  backColor = |*| #cccccc || #eeeeee |*|
  10 = TEXT
  10.text.field = title
  10.offset = 0,13
  10.align = center
  10.niceText = 1
}
page.10.1.RO < page.10.1.NO
page.10.1.RO = 1
page.10.1.RO {
  backColor = red
  10.fontColor = white
}

Images on GMENUs¶

You can use background images for your menuitems

page.10 = HMENU
page.10.1 = GMENU
page.10.1.NO {
  wrap = | <BR>
  XY = [4.w], [4.h]
  backColor = olive

  4 = IMAGE
  4.file = fileadmin/tsbyex/menuback.gif

  10 = TEXT
  10.text.field = title
  10.offset = 0,14
  10.align = center
  10.niceText = 1
}

GMENU_LAYER¶

Typo3 also supports the use of DHTML menus on layers. But it requires the HMENU to consist of two menu objects where the first is GMENU_LAYER. The second can be either a TMENU or GMENU

page.includeLibs.gmenu_layers = media/scripts/gmenu_layers.php
page.10 = HMENU
page.10.1 = GMENU_LAYERS
page.10.1 {
  layerStyle = position:absolute;left:0px;top:30px;width:10px;VISIBILITY:hidden;
  xPosOffset =-10
  lockPosition = x
  expAll=1
  NO {
    backColor = #cccccc
    XY = [10.w]+10, 14
    10 = TEXT
    10.text.field = title
    10.offset = 5,10
  }
}
page.10.2 = GMENU
page.10.2.wrap = |<BR>
page.10.2.NO {
  backColor = #99cccc
  XY = 120, 14
  10 = TEXT
  10.text.field = title
  10.offset = 5,10
}

Extending a background image to the whole menu¶

I would like to demonstrate a final powerful feature of the GMENU object: Extending a background image over the whole menu:

Based on this menu:

page.includeLibs.gmenu_layers = media/scripts/gmenu_layers.php
page.10 = HMENU
page.10.1 = GMENU_LAYERS
page.10.1 {
  layerStyle = position:absolute;left:0px;top:30px;width:10px;VISIBILITY:hidden;
  xPosOffset =-10
  lockPosition = x
  expAll=1
  NO {
    backColor = #cccccc
    XY = [10.w]+10, 14
    10 = TEXT
    10.text.field = title
    10.offset = 5,10
  }
}
page.10.2 = GMENU
page.10.2.wrap = |<BR>
page.10.2.NO {
  backColor = #99cccc
  XY = 200, 20
  10 = TEXT
  10.text.field = title
  10.offset = 5,15
  10.fontColor = white
  10.niceText = 1
  10.fontSize = 20
}

... add these lines:

...
page.10.2 = GMENU
page.10.2.wrap = |<BR>
page.10.2.NO {
  backColor = #99cccc
  XY = 200, 20

  5 = IMAGE
  5.file = fileadmin/tsbyex/sunset_keywest.jpg

  10 = TEXT
  10.text.field = title
  10.offset = 5,15
...

That inserted the sunset-image as background. But we would like that image to extend over the whole menu which is done by addition a property to the GMENU-object about which GIFBUILDER-objects to modify regarding offset values. So add:

page.10.2.applyTotalH = 5

... and this is what you get!

Regarding the property .applyTotalH, look it up in the TSref. Basically it's a pointer that works like this:

Finally you may create such menus but wish that you menu will always be as high as the background image in order not to crop it in the bottom. Then add this:

...
page.10.2 = GMENU
page.10.2.applyTotalH = 5
page.10.2.min = , 200
page.10.2.max = , 200
page.10.2.wrap = |<BR>
page.10.2.NO {
  backColor = #99cccc
  XY = 200, 20

  5 = IMAGE
  5.file = fileadmin/tsbyex/sunset_keywest.jpg
  5.height = 200

  10 = TEXT
  10.text.field = title
...

Result:

Notice: The properties .min and .max defines both x and y dimensions. In this case we specify only the y-dimension by the comma:

page.10.2.min = , 200
page.10.2.max = , 200

PHP_SCRIPT cObject¶

There's not much to say about this, that hasn't been said already. So what I'm going to do is to direct you to the TSref, section "PHP include scripts" in the end of the document. There's a very fine "Casestory" which you can do as an execise.

Also there's a great demonstration on the testsite, you're working on. Unfortunately you've been working on a test-template, so directing you to page "index.php?id=30" will only display your last adventures with the test template. So, deactivate your test template for a while and check out the guide:

(Remember to "Clear All Cache" in the [menu] after deactivating...)

Inspiration¶

If you need inspiration to your scripts, you should really take a look at some of the default scripts. The most basic is the guestbook script af media/scripts/guest.inc. I'm not gonna list the code here. There's too much.

Remember to look at the "content.tt_guest" static_template also. The TypoScript in there is the key to understand how you connect TypoScript with your own scripts.

Example: Userdefined tags¶

I just thought of a great example of an include script. Really useful. On the www.typo3.com website I sometimes list TypoScript code. That's done with a special tag, I introduced there. In order to try this, we'll stick to the original testsite, because it features some content which come in handy here.

1. Open the testsite template and add this:

# Add the custom tag, <TS>...</TS> to the parseFunc of bodytext
tt_content.text.20.parseFunc.tags {
  ts.stripNL = 0
  ts = PHP_SCRIPT
  ts.file = fileadmin/tsbyex/testtag.inc
}

2) Open the document fileadmin/tsbyex/testtag.inc with your favourite text-browser and verify that this is the content:

<?
        $contentOfTag = $this->getCurrentVal();
        $content = '<B>'.$contentOfTag.'</b>';
?>

3) Open "Startpage" on the testsite and add <ts>...</ts> tags like you see here:

... and guess what. This is the outcome:

Moving a bit further, lets include a library with a class. By time that's a necessity anyway, so...

1. Add/modify this to the TypoScript template:

# Add the custom tag, <TS>...</TS> to the parseFunc of bodytext
tt_content.text.20.parseFunc.tags {
  ts.stripNL = 0
  ts = PHP_SCRIPT
  ts.file = fileadmin/tsbyex/testtag2.inc
}

includeLibs.testclass_example = fileadmin/tsbyex/testclass.inc

2) Open the document fileadmin/tsbyex/testtag2.inc and fileadmin/tsbyex/testclass.inc with your favourite text-browser and verify that this is the content:

fileadmin/tsbyex/testtag2.inc

<?
        $test_object = new testClass;
        $contentOfTag = $this->getCurrentVal();
        $content = $test_object->formatTS($contentOfTag, 1);
?>

fileadmin/tsbyex/testclass.inc

<?
class testClass {
        function formatTS($input, $ln)  {
                $input = ereg_replace("^[^".chr(10)."]*.","",$input);
                $input = chop($input);
                $cArr = explode(chr(10),$input);

                reset($cArr);
                $n = ceil(log10(count($cArr)));
                $lineNum="";
                while(list($k,$v)=each($cArr))  {
                        if ($ln)        $lineNum = sprintf("% ".$n."d",($k+1)).":   ";
                        $v=htmlspecialchars($v);
                        $cArr[$k] = str_replace(" ",chr(160),$lineNum.$v);
                }
                $output = implode($cArr, "<BR>")."<BR>";
                $output = '<font face=verdana size=1 color=maroon>'.$output.'</font>';
                return $output;
        }
}
?>

3) Finally enter this to the content record:

... and you should see this in your frontend, when you reload:

Introduction¶

You should read the PDF-document "content_rendering.pdf" on the topic.

But regular pagecontent is normally rendered by the static_template "content (default)" which you include with your template:

The static_template "content (default)" includes other static_template by itself. One of them is the famous "styles.content (default)" which holds a lot of premade TypoScript objects that is copied into useful locations in the nodetree.

Looking in the Object Browser you see a rootlevel object "tt_content" has appeared. *The toplevel object "tt_content" is the cObject that renders content from the table "tt_content" by default!* And it appears to start out with a CASE content object that determines the content type of the content element in question:

CONTENT¶

The cObject "CONTENT" is used to fetch the content from the "tt_content" table. It performs a SELECT-query on the database and the result is then - one record at a time - rendered by the "tt_content." toplevel object (unless we specify something else)

page.10 = CONTENT
page.10 {
  table = tt_content
  select.orderBy = sorting
  select.where = colPos=0
}

colPos¶

But what is "colPos=0"?

Well, Typo3 can (by default) work with four columns of content defined by the field "colPos" of the tt_content table. This is how the interface displays the columns and as you see, currently there are no items in the other columns:

Try to create some new content in the "border" column:

... and it nicely appears in the "border" column:

In order to insert the content on the website, you need to know which value the field "colPos" has for the border column. So go to the $tc- browser in the Tools-module:

The value is "3". So modify your TypoScript like this:

page.10 = CONTENT
page.10 {
  table = tt_content
  select.orderBy = sorting
  select.where = colPos=3
}

Result:

styles.content (default)¶

Let take a minute to look in the "styles.content (default)" static_template. As stated it contains premade chunks of TypoScript for our free use. Actually the tasks above could have been done much easier based on what we see here:

page.10 < styles.content.get

substitutes
page.10 = CONTENT
page.10 {
  table = tt_content
  select.orderBy = sorting
  select.where = colPos=0
}

and likewise with the "border"-column:

page.10 < styles.content.getBorder

Get it? Good.

lib.stdheader¶

In static_template "content (default)" you see a object "lib.stdheader" defined:

lib.stdheader = COA
lib.stdheader {
  stdWrap.wrapAlign.field = header_position
  stdWrap.typolink.parameter.field = header_link
  stdWrap.fieldRequired = header
  stdWrap.if {
    equals.field = header_layout
    value = 100
    negate = 1
  }
...

... and used many places:

# CType: bullet
tt_content.bullets = COA
tt_content.bullets {
  10 = < lib.stdheader
  20 = CASE
...

# CType: text
tt_content.text = COA
tt_content.text {
  10 = < lib.stdheader
  20 = TEXT
  20 {
...

# CType: multimedia
tt_content.multimedia = COA
tt_content.multimedia {
  10 = < lib.stdheader
  20 = MULTIMEDIA
...

Opposite to the normal use of "shared code" which is actually copied to other locations, cObjects can be shared by a reference to a toplevel object (see TSref, section "cObjects").

Looking in the Object Browser, we realize that this is true:

tt_content.text.10 has the value "< lib.stdheader" - not the object properties!

This is a very clever implementation in this case because if the header of all content elements is rendered through the same object, lib.stdheader, that is the only place to make changes if we would like to alter the header rendering!

page.10 < styles.content.getBorder

lib.stdheader >
lib.stdheader = TEXT
lib.stdheader.value = ALTERNATIVE HEADER !!

RECORD¶

This cObject is used to retrieve single records. CONTENT was designed to get a list of records - normally from the table tt_content. But it could be any table:

page.10 = RECORDS
page.10.source = 1
page.10.tables = tt_content
page.10.conf.tt_content = TEXT
page.10.conf.tt_content {
  field = header
  case = upper
  wrap = <B> | </B>
}

temp.tt_address = COA
temp.tt_address.wrap = | <HR>
temp.tt_address.10 = TEXT
temp.tt_address.10 {
  field = name
  case = upper
  wrap = <B> | </B><BR>
}
temp.tt_address.20 = IMAGE
temp.tt_address.20 {
  file.import.field = image
  file.import = uploads/pics/
  file.import.listNum = 0
  file.height = 100
}

page.10 = RECORDS
page.10.source = 3,1,5
page.10.tables = tt_address
page.10.conf.tt_address < temp.tt_address

tt_address = COA
tt_address.wrap = | <HR>
tt_address.10 = TEXT
tt_address.10 {
  field = name
  case = upper
  wrap = <B> | </B><BR>
}
tt_address.20 = IMAGE
tt_address.20 {
  file.import.field = image
  file.import = uploads/pics/
  file.import.listNum = 0
  file.height = 100
}

page.10 = RECORDS
page.10.source = 3,1,5
page.10.tables = tt_address

((generated))¶

page.10 = TEXT
page.10.field = crdate
page.10.date = d-m-y H:i

01-07-00 15:48

page.10 = TEXT
page.10.field = crdate
page.10.strftime = %A %e. %B, %I:%M %p

Saturday 1. July, 03:48 PM

page.10 = TEXT
page.10.field = crdate
page.10.strftime = %A %e. %B, %I:%M %p
config.locale_all = deutsch

Samstag 1. Juli, 03:48

page.10 = TEXT
page.10.data = leveltitle:-2

page.10 = TEXT
page.10.field = subtitle
page.10.ifEmpty = Hello world

page.10 = TEXT
page.10.field = subtitle
page.10.ifEmpty {
  field = title
  required = 1
  wrap = <font color="red">|</font>
}
page.10.wrap = <H3>|</H3>

page.10 = TEXT
page.10.field = subtitle
page.10.ifEmpty {
  field = title
  if.isTrue.field = title
  wrap = <font color="red">|</font>
}
page.10.wrap = <H3>|</H3>

page.10 = COA

# Header to this section
page.10.10 = TEXT
page.10.10 {
  value = This is the page title:
...
  20.wrap = Subtitle: <B> |</B>
  20.required=1
}

page.10 = COA
page.10.if.isTrue.field = subtitle
...

page.10 = COA
page.10.if.value = 1
page.10.if.isGreaterThan.data = level:1
...

page.10 = IMAGE
page.10 {
  file = fileadmin/tsbyex/alligator.jpg
  file.width = 200
  imageLinkWrap = 1
  imageLinkWrap.enable = 1
  imageLinkWrap.JSwindow = 1
}

page.10 = IMAGE
page.10 {
  file = fileadmin/tsbyex/alligator.jpg
  file.width = 200
  imageLinkWrap = 1
  imageLinkWrap.enable = 1
  imageLinkWrap.JSwindow = 1
  imageLinkWrap {
    bodyTag = <BODY bgColor=black>
    wrap = <A href="javascript:close();"> | </A>
    width = 400m
    height = 300
    JSwindow = 1
    JSwindow.expand = 22,30
  }
}

page.10 = IMG_RESOURCE
page.10 {
  file = fileadmin/tsbyex/alligator.jpg
  file.width = 200
}
page.10.stdWrap.wrap = <table border=1 cellpadding=30 background="|"><tr><td><BR><font color=white size=4><B>Hello World</b></font></td></tr></table>

page.5 = TEXT
page.5.value = Before ruler
page.5.wrap = | <BR>

page.10 = HRULER
page.10 {
  lineThickness = 3
  lineColor = red
}
page.10.stdWrap.spaceAfter = 20
page.10.stdWrap.spaceBefore = 10

page.15 = TEXT
page.15.value = After ruler