Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Documentation changes in 4.2

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Core Team (category Core Team)

This page contains all changes that were introduced in TYPO3 4.2.

notice - Note

What you find on this page is what we changed in the official documents. It does not make sense to correct any mistakes here - if you found one, please use the according bug trackers instead to inform us! Thank you!

doc_guide_install

Master version of the manual can be found at: https://github.com/TYPO3-Documentation/TYPO3CMS-Guide-Installation

Dmitry, 29.01.2007: Re: [TYPO3-core] RFC: performance improvemenets for database:

 Starting from version 4.1 TYPO3 uses InnoDB as database engine for several tables. This helps to prevent
 locks and to increase performance. 
 Also InnoDB is more crash-resistant compared to MyISAM. We recommend to review your MySQL configuration
 and to ensure that your table space has the "autoexpand" option enabled. See MySQL manual for more information
 about configuring InnDB. If you do not have InnoDB enabled, MySQL will use MyISAM automatically and you
 need not take any actions"

 I think it can go to section 2.1 before "Very Important: Changing...".


Rupert: Store separate extlist for the frontend 20717: TYPO3 Core - Store separate extlist for the frontend [Closed; assigned to Rupert Germann]

replacement for section "Cached files in typo3temp/":

Generally you should know that TYPO3 generates temporary “cached” scripts in typo3conf/. Those would look like these:

-rw-r--r--     1 www-data   www-data      61555    2009-08-11 16:28     temp_CACHED_ps3f58_ext_localconf.php
-rw-r--r--     1 www-data   www-data      81995    2009-08-11 16:28     temp_CACHED_ps3f58_ext_tables.php
-rw-r--r--     1 www-data   www-data      47098    2009-08-11 16:28     temp_CACHED_FE_ps3f58_ext_localconf.php
-rw-r--r--     1 www-data   www-data      45517    2009-08-11 16:28     temp_CACHED_FE_ps3f58_ext_tables.php

The temp_CACHED_FE* files have been introduced in TYPO3 v4.3. 

You can experience more than these files. In that case it will be because of multiple paths, symlinks or just old files.

You can at any time remove these files and on the next hit to the system they will be re-written. The "temp_CACHED" files simply 
contain all ext_tables.php and ext_localconf.php files from the installed extensions concatenated in the order they are loaded. 
Therefore including one of these files is the same as including potentially hundred PHP-files and that saves some milliseconds 
for the system. 
The "temp_CACHED_FE" files contain only the ext_tables.php and ext_localconf.php files from those extensions which are needed to 
render frontend output. Since these files are smaller than the temp_CACHED files with all extensions configuration this should save 
some additional milliseconds. 

But it also means that a) you can never make any local changes to these files since they can at anytime be removed and recreated 
from the “originals” and b) if you make changes to the original “ext_tables.php”/”ext_localconf.php” files you will have to clear 
these files away!

doc_core_tsref

Peter Klein, 2009-01-16

The text "Notice: Currently this works only with TCA fields of type "select" which are not database relations."
Should be changed to "Notice: Currently this works only with TCA fields of type "select" which are not database relations and not defined in dynamicConfigFile."
https://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.2.0/view/1/5/#id4149585
https://forge.typo3.org/issues/19198

Peter Niederlag, 2008-05-21

Property 'config.insertDmailerBoundaries' INVALID/REMOVED from TYPO3-Core(!)
the property is however still supported by the extension 'direct_mail' via a postUserFunc.
# This property was removed and replaced by a hook in revision 1091 in branches/TYPO3_4-0 in the year 2006!
# $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['CType-content-itemProc']

Removed

Michael Stucki, 2008-04-01 15040: TYPO3 Core - Logging with class.tslib_fe.php + awstats + realurl [Closed; assigned to Martin Kutschker]

Add new value to "config.stat_apache_pagenames" property:
request_uri: Insert the REQUEST_URI server value (useful for RealUrl)

Done with slight change in description: "inserts the REQUEST_URI server value (useful with RealUrl for example)"

Georg Ringer, 20008-03-2118490: TYPO3 Core - stdWrap for doNotLinkIt & doNotShowLink [Resolved; assigned to Steffen Kamper]

Change in TSref MENU Objects > TMENUITEM  
Property doNotLinkIt: Data type boolean to boolean /stdWrap
Property doNotShowLink: Data type boolean to boolean /stdWrap

Done

Georg Ringer, 20008-03-2118489: TYPO3 Core - recursive pidInList for select in cObj CONTENT [Closed; assigned to Dmitry Dulepov]

Add in TSref Functions > select > after pidInList:
Property: recursive
Data type: int
Default value: 0
Description: Recurive levels for the pidInList

Done (with correction of typo in "Recurive")

Ingo Renner, 20008-03-1618125: TYPO3 Core - hardcoded fieldset and legend around radio buttons [Closed; assigned to Ingo Renner]

Add in TSref FORM Object > add after radioWrap:
Property: radioWrap. accessibilityWrap
Data type: wrap
Default value: <fieldset###RADIO_FIELD_ID###><legend>###RADIO_GROUP_LABEL###</legend>|</fieldset>
Description: defines how radio buttons are wrapped

Done with enhanced description for more clarity: "Defines how radio buttons are wrapped when accessibility mode is turned on (see below “accessibility” property)"

Georg Ringer, 20008-03-13 18437: TypoScript Reference (TSref) - ATagParams of GMENU got stdWrap! [Closed; assigned to Michael Stucki]

Change in TSref MENU Objects > GMENU > Additional properties for Menu item states: [tsref:(cObject).HMENU.(mObj).GMENU.(itemState)] 
Property ATagParams
Data type string to string /stdWrap

Done

Dmitry Dulepov, 2008-02-19 16147: TYPO3 Core - Linking between domains in the pagetree ignores simulate static documents [Closed; assigned to Dmitry Dulepov]: Linking between domains in the pagetree ignores simulate static documents

Add in TSref [tsref:config/->CONFIG] after typolinkCheckRootline:

Property: typolinkEnableLinksAcrossDomains
Data type: boolean
Default value: 0
Description: 
// description start //
This option enables to create link across domains using current domain's linking scheme.
If this option is not set, then all cross-domain links will be generated as
"http://domain.tld/index.php?id=12345" (where 12345 is page id). If this option is set
and current site uses, for example, simulateStatic, then links will be generated as
"http://domain.tld/PageTitle.12345.html" (includes RTE links too). Setting this option requires
that domains, where pages are linked, have the same configuration for:
- linking scheme (i.e. all use simulateStatic or RealURL or CoolURI but not any mixture)
- all domains have identical localization settings (config.sys_language_XXX directives) 
- all domains have the same set of languages defined

This option implies "config.typolinkCheckRootline=1", which will be activated automatically.
Setting value of "config. typolinkCheckRootline" inside TS template will have no effect.

Disclamer: 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.
// description end //

Done with correction of a couple of typos

Dmitry Dulepov, 2008-01-08 17930: TYPO3 Core - Enable stdWrap for wrapItemAndSub [Closed; assigned to Dmitry Dulepov]: Enable stdWrap for wrapItemAndSub

Change in TSref [tsref:config/->TMENUITEM->wrapItemAndSub]:

Datatype: wrap/stdWrap

Done

Andreas Otto, 2007-08-21 17361: TYPO3 Core - class.indexer: Indexing of meta description and keywords [Closed; assigned to Andreas Otto †]: New TS option that makes indexing of metatags configurable

Change in TSref [tsref:config/->CONFIG]:
Add this after the description of index_descrLgd.

Property: index_metatags
Datatype: boolean   
Description: This allows to turn off indexing of metatags.
Default: true

Done with improved description (the original description feels like metatag indexing is turned off by default IMO): "This allows to turn on or off the indexing of metatags. It is turned on by default."

Stucki, 18.7.2007: 17483: TypoScript Reference (TSref) - config.disableImgBorderAttr is not documented in TSRef [Closed; assigned to Michael Stucki]

TSref > Setup > Config

Property: disableImgBorderAttr 
Datatype: boolean
Description: Returns the 'border' attribute for an <img> tag only if the doctype is not xhtml_strict,xhtml_11 or xhtml_2 or if the config parameter 'disableImgBorderAttr' is not set

Added after config.htmlTag_dir. There was no indication where to add this property. It is related to xhtmlDoctype, so I wanted to place it close to that property, but the properties that follow xhtmlDoctype are also very logically placed. So I decided to insert it after that group of properties. This could be changed.

Baschny, 28.3.2007: New feature in trunk (for 4.2): +stdWrap for "FRAME"

TSref -> "FRAME" -> parameter "src":

1) Data type:

- <frame>-data:src
+ <frame>-data:src
+  +stdWrap

2) Description:

- Manually set the src of the frame
- NOTE: Is set automatically and should not be overridden under normal
conditions!
+ Instead of using the "obj" destination, you can define a specific src
for your frame with this setting. This overrides the default behaviour
of using the "obj" parameter!

3) Default:

- could be index.php?$id&$type
+ typolink to id=[currentId]&type=[obj->typeNum]

Done

Andreas Otto, 2007-04-05: New conditions for "Condition reference"

year
See "Hour" above. Same syntax! For further information look at the date() function in the PHP manual, format string Y.
Syntax:
[year = 2007]

dayofyear
See "Hour" above. Same syntax! For further information look at the date() function in the PHP manual, format string z.
Syntax:
[dayofyear = 300]

Done with a few more explanations about the syntax, matching what exists for other conditions

Oliver Hader, 2007-04-26: New feature in trunk (for 4.2): RFC 5424 - Menu cache expire time should be configurable

HMENU, before property "entryLevel":
1) Property: cache_period
2) Data type: int
3) Description:
   The number of seconds a menu may remain in cache. If this value is not
   set, the first available value of the following will be used:
   1) cache_timeout of the current page
   2) config.cache_period defined globally
   3) 86400 (= 1 day)

Done

Franz Holzinger, RFC 17286 Typolink for logged in FE user:

typolink function: new property "linkAccessRestrictedPages"
If set, typolinks pointing to access restricted pages will still link to the page even though the page cannot be accessed.

Committed on 06/07/2007 by Stucki (rev. @2387).

Done. There was no indication where to place that new property, so I added it at the end, just before the "userFunc" property (which it seemed logical to leave as the last one)

Allow FORM to require checkbox fields (Masi):

In documentation of FORM TS object change

 check:Label | [fieldname =]check | [checked=1]

to
 check:Label | [* = required / must be checked][fieldname =]check | [checked=1]

Done

Oliver Hader, 2007-08-07: 15808: TYPO3 Core - imgResource doesn't support stdWrap on minW and minH [Closed; assigned to Oliver Hader]

  '''In doc_core_tsref -> Functions -> imgResource:'''
  * Property: "minW"
    Data type: "pixels" --> "pixels / stdWrap"
  * Property: "minH"
    Data type: "pixels" --> "pixels / stdWrap"

Done

Dmitry: add to CONFIG after removeDefaultJS:

minifyJS
----
boolean
----
If set inline or externalized (see removeDefaultJS) JavaScript will be minified. Minification will remove all excess space and cause faster page loading. Together with removeDefaultJS=external it will significally lower web site traffic.

Depends on the compatibility mode (see Tools>Install>Update wizard):

compatibility mode < 4.0:   0
compatibility mode >= 4.0:   1

Example:

config.minifyJS = 1
----

Done with 1 typo corrected ("significally")

Stucki: 17656: TypoScript Reference (TSref) - Incorrect link handler configuration in TSref [Closed; assigned to Francois Suter]

Done

17579: TYPO3 Core - Change config.uniqueLinkVars to 1 [Closed; assigned to Ingmar Schlecht] (rev. @2620 for 4.2): Set the default to 1 https://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.1.0/view/7/3/

Done with one typo corrected in the description ("cosmetical" => "cosmetic")

Ralf Hettinger, 2007-11-09 16593: TYPO3 Core - stdWrap for params in function cImage, class.tslib_content.php [Closed; assigned to Ingmar Schlecht]: stdWrap for IMG-params

TSref [tsref:(cObject).IMAGE]

Change Data type where Property is params

Data type:
<IMG>-params/stdWrap

Done

Oliver Hader, 2007-11-20: Missing documentation in "IMGTEXT" on property "image_compression"

TSref -> IMGTEXT -> image_compression
30= PNG/256
31= PNG/128
32= PNG/64
33= PNG/32
34= PNG/16
35= PNG/8
39= PNG

Done with added line "(adds png-extension and color-reduction command)" to make it like the other images compression types list


Steffen Kamper, 2007-11-29 17850: TYPO3 Core - Possibility to add inline JS to page [Closed; assigned to Benni Mack] new feature inlineJS TSref, section PAGE-Object

property: inlineJS
Data type: CARRAY
Description: Inserts inline Javascript in the header-section. Don't use script-tags as they are added by TYPO3.

Example:
page.inlineJS.10 = TEXT
page.inlineJS.10.value = function a(val) { alert(val); }

with config.removeDefaultJS=external the inlineJS is moved to external file.
with config.minifyJS=1 the inlineJS will be minified as well.

Added after includeJS property

Georg Ringer, 2008-01-02 18088: TYPO3 Core - stdWrap for menu > range & entrylevel [Closed; assigned to Bernhard Kraft] TsRef, section HMENU

property: entryLevel
Daty type: stdWrap
(Description: no change)

Done. Data type is actually int /stdWrap

Uschi Renziehausen, 2008-02-11 18088: TYPO3 Core - stdWrap for menu > range & entrylevel [Closed; assigned to Bernhard Kraft] TSref, section special.rootline

property: range
Data type: string/stdWrap
(Description: no change)

Done

Taken from the ERRATA section:

TypoScript PAGE.includeJS:

.style - setting the MIME type of the script (default: text/javascript)

It should read ".type" not ".style".

Corrected

doc_core_tsconfig

Stefan Geith: Related to feature 16318: TYPO3 Core - Patch: new option TSFE.jumpUrl_prefer301 = 1 [Closed; assigned to Jeff Segars] please add to 'Page TSconfig' TSFE, right after 'jumpUrl_transferSession':

Property: jumpURL_HTTPStatusCode
Data type: int
Description:
 Allowed values: 301, 302, 303, 307
 If set, the jumpUrl redirection will get the selected status code (301, 302, 303 or 307) as a header. For redirect to external URLs, 301 is recommended.
 If not set, no status code at all is used.
 See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for status code definitions and their intents.
 For redirection to external URLs, 301 is recommended: Search the Web for '301 vs 302' to get more details.


Dmitry: Add to Page TSConfig, mod.web_list section:

Property: tablename.hideTable
Data type: boolean
Description: If set to non-zero, the table is hidden. If it is zero, table is show if table name is not listed in "hideTables" list. Example: mod.web_list.tt_content.hideTable = 1
Default:

Added after "hideTables" property

Dmitry: New user TSConfig options:

options.workspaces.changeStageMode

Possible values are:

"any" - if page or element (meaning any record on the page) stage is changed (for example, from "editing" to "review"), all content elements on the page and page will change to that new stage as well (possibly bypassing intermediate stages).

"page" - if page stage is changed (for example, from "editing" to "review"), all content elements on the page will change stage as well (possibly bypassing intermediate stages). If stage is changed for element, all other elements on the page and page itself remain in the previous stage.

Default: normal behavior (same as in 4.0)


options.workspaces.swapMode

Possible values are:

"any" - if page or element (meaning any record on the page) is published, all content elements on the page and page itself will be published regardless of the current editing stage.

"page" - if page is published, all content elements on the page will be published as well. If element is published, its publishing does not affect other elements or page.

Default: normal behavior (same as in 4.0)

Done, placeholders already existed in the doc

Ingo Renner:

linkTitleToSelf.returnUrl

remove linkTitleToSelf.returnUrl = 1
from ->TCEFORM_confObj:linkTitleToSelf

see revision 2288/2289

Removed


Wolfgang Klinger:

https://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.1.0/view/1/2/#id3822379 edit:

Sets default values for records. The order of default values when creating new records in the backend is this:
   1. Value from $TCA
   2. Value from User TSconfig (these settings)
   3. Value from Page TSconfig
   4. Value from “defVals” GET vars (see alt_doc.php)
   5. Value from previous record based on 'useColumnsForDefaultValues'

https://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.1.0/view/1/3/#id3521576 new:

TCAdefaults.[tablename].[field]

string
	
Sets default values for records. The order of default values when creating new records in the backend is this:
   1. Value from $TCA
   2. Value from User TSconfig
   3. Value from Page TSconfig
   4. Value from “defVals” GET vars (see alt_doc.php)
   5. Value from previous record based on 'useColumnsForDefaultValues'

See https://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.1.0/view/1/2/#id3822379
for a complete description

I'm a bit perplex about these two as they seem redundant (and the second one actually refers to the first one). I found a single matching place in the doc_core_tsconfig and added the only line that seemed different "Value from Page TSconfig". I also changed the list styles from bulleted to numbered.

Thomas: New user TSConfig options:

options.pageTree.showNavTitle = boolean

If set, the navigation title is displayed in the page navigation tree instead of the normal page title. The page title is showed in a tooltip if the mouse hovers the navigation title.

Added after "pageTree.showDomainNameWithTitle" property

Remove disableDocModuleInAB option (rev. @2639, 4.2) https://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.1.0/view/1/2/#id3515957

Removed

Christian, 06.11.2007, 17749: TYPO3 Core - Rename TSconfig Options dontSeparateNotinmenuPages and dontAlphasortNotinmenuPages [Closed; assigned to Ingmar Schlecht], (rev @2662 for 4.2) New user TSConfig options https://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.1.0/view/1/2/#id3515957 :

options.pageTree.seperateNotinmenuPages
boolean
If set, not in menu and special pages are separated in the page tree from standard pages.

options.pageTree.alphasortNotinmenuPages
boolean
If set and pageTree.seperateNotinmenuPages=1, separated pages are sorted alphabetically.

Done

Kasper, 06.11.2007, "[TYPO3-core] Patches to be approved for the core" committed on Sunday, 28.10.2007, (rev @2630 for 4.2) (ChangeLog entry pasted here by Ingmar)

Added User TSconfig options to mount pages and folders for link-browsing 
purposes only. The point is that a user should be able to select pages 
which normally doesn't appear in his particular mount points of the page
tree. With this feature you can set an entirely different set of 
mountpoints which only appear in the Element Browser. It is for readonly 
purposes of course. (Normal page access restrictions will still apply 
though, only the mount point changes). These features can be useful in 
general where a user needs to link to files or pages outside their normal 
range. However, it becomes especially useful with workspaces where the db 
mount is usually smaller and filemounts are completely disabled! Here are
examples of configuration: 
options.folderTree.altElementBrowserMountPoints = _temp_/,templates
options.pageTree.altElementBrowserMountPoints = 34

Kasper had already added these properties. I just corrected a small typo.

Steffen, 2008-08-18, 19191: TYPO3 Core - Enable feature in element browser in rte like in normal one [Resolved; assigned to Steffen Kamper]

TSConfig -> Options

pageTree.altElementBrowserMountPoints
[list of page uids]
Sets alternative mountpoint for page tree in element browser.
If set, it replaces the user's mountpoint. This is useful to allow linking to pages which are not in the resources of the user.
Example:
options.pageTree.altElementBrowserMountPoints = 1,5


folderTree.altElementBrowserMountPoints
[list of folders relative to fileadmin]
Sets additional file mounts in element browser. If set, these file mounts will be added to existing ones and the whole folder tree is set to read-only.
Example:
options.folderTree.altElementBrowserMountPoints = _temp_,templates

Kasper had already documented these features. After discussion with Steffen, I added the following information to make these descriptions more complete:

for pageTree.altElementBrowserMountPoints

These alternative webmounts replace configured DB Mountpoints.

for folderTree.altElementBrowserMountPoints

If defined, the whole folderTree in Element  Browser is set to "read only". The alternative filemounts are added to the existing Filemounts.

Note: the thing with the folderTree becoming read-only is a bug with a patch pending in core list 19310: TYPO3 Core - Bugfix for temporary Filemounts [Resolved; assigned to Steffen Kamper]

Olly, 2007-11-19: 17606: TYPO3 Core - Enable overriding/renaming field labels by Page TSconfig [Closed; assigned to Oliver Hader] (by Malte Jansen)

Page TSconfig -> TCEFORM -> TCEFORM_confObj: Add new property

property: label
data type: string (LS)
description:
This allows you to enter alternative labels for any field.

Example:
TCEFORM.[table].[field] {
  label = LLL:EXT:my_ext/locallang_db.php:table.column
  label.default = New Label
  label.de = Neuer Feldname 
}

Added after the "disabled" property (which seemed logical, because the properties that follow are all related to items and not fields.

Olly, 2008-02-11: 17039: TYPO3 Core - Integrate mod.web_list.deniedNewTables as opposite of allowedNewTables [Closed; assigned to Oliver Hader]

Page TSconfig -> Web>List (mod.web_list): Add new property before "allowedNewTables"

* Property: deniedNewTables
* Data type: list of tablenames
* Description: If this list is set, then the tables listed here won't
have a link to "create news" in the page and subpages.
This also affects "db_new.php" (the display of "Create new record").
This is the oposite of the previous property "allowedNewTables".
If allowedNewTables and deniedNewTables contain a common subset,
deniedNewTables takes precedence.

Example:
mod.web_list {
  deniedNewTables = tt_news,tt_content
}

Done, corrected one typo"

Masi, 2008-03-21, add-on for Dmitry's work: 17886: TYPO3 Core - Disabling some or all controls in "group" field [Closed; assigned to Dmitry Dulepov]

Page TSconfig -> TCEFORM

* Property: [tablename].[field].config.[key]
* Description: "add 'disable_controls' to the list of values for 'group'"

Done

Francois: add missing "startModule" property to list of properties in ->SETUP

This was not in the pending documentation but was noticed by Clemens Riccabona in the Core list in response to my work, so I added it. Description was adapted from the CSH for that field in User Settings module.

doc_core_api

In "$TCA array reference" at "Reference for the ['columns'][fieldname]['config'] / TYPE: "select" section":

Key: noIconsBelowSelect
Datatype: boolean
Description: (add after iconsInOptionTags) Note: Disables the rendering of the icons after the select even when
icons for the <select>s <option> tags were supplied and iconsInOptionTags was set.
Scope: Display

Done

In "$TCA array reference" at "Reference for the ['columns'][fieldname]['config'] / TYPE: "group" section":

Key: internal_type
Datatype: string
Description: Add a new internal type: 3. "folder" - this will create a field where folders can be attached to the record
Scope: Display / Proc.

Done

In "$TCA array reference" at "Reference for the ['ctrl'] section":

Key: label
Description: (add to the end) Note: label_userFunc overrides this property (but it is still required).
Key: label_alt
Description: (add to the end) Note: label_userFunc overrides this property.
Key: label_alt_force
Description: (add to the end) Note: label_userFunc overrides this property.
(add this new key after label_alt_force)
Key: label_userFunc
Datatype: string
Description:
Function or method reference. This can be used whenever the label or label_alt options
don't offer enough flexibility, e.g. when you want to look up another table to create
your label. The result of this function overrules the “label”, “label_alt” or
“label_alt_force” settings.

If you want to call a function, just enter the function name. The function name must be
prefixed "user_" or "tx_".

If you want to call a method in a class, enter "[classname]->[methodname]". The class
name must be prefixed "user_" or "tx_".

Two arguments will be passed to the function/method: The first argument is an array which
contains the following information about the record for which to get the title:

$params['table'] = $table;
$params['row'] = $row;

The resulting title must be written to $params['title'] which is passed by reference.

The second argument is a reference to the parent object.

Notice: You must include the class manually on beforehand! (e.g. include it in your
ext_tables.php file)

Example:

in ext_tables.php:

include_once(t3lib_extMgm::extPath('myext').'class.tx_myext_title.php');

$TCA["tx_myext_table"] = Array (
    "ctrl" => Array (
        'title' => 'LLL:EXT:myext/locallang_db.xml:tx_myext_table',
        'label' => 'name',
        'label_userFunc' => 'tx_myext_title->getRecordTitle',
    ),
);
in your extension folder class.tx_myext_title.php:

class tx_myext_title {
    function getRecordTitle($params, $pObj) {
        $params['title'] = 'Whatever...';
    }
} 

(Francois 12:52, 29 August 2008 (CEST)) Check if all changes mentioned in the link below are described above

http://lists.typo3.org/pipermail/typo3-team-core/2006-December/006521.html

All done. Entries in the wiki matched the document included in the thread mentioned above.

Concerning IRRE (suggestion by Ingmar):

We need to clearly state in the type "inline" section of "TYPO3 Core APIs" that IRRE
only works on tables which are NOT versioning enabled. The parent as well as the child
table of IRRE fields must not be versioning enabled, otherwise unexpected behavior
might happen.

Added just before the reference table for type "inline"

Dmitry: error in "['ctrl'] section" of section 4.2 ("$TCA array reference") for "cruser_id" field. It says: "Typically the field name "cruser_id" is used for the time stamp value.". This is a copy/paste error from "crdate". Just remove the sentence completely.

Done

Ingmar: Adding documentation for "Newline for Tabs (--div--)" by Malte Jansen. 17578: TYPO3 Core - Newline for Tabs with divs2tabs [Closed; assigned to Ingo Renner]

In "$TCA array reference" at "Reference for the ['types'][key] section" at "'Description' of the Key 'showitem'":

...
Notice: Instead of a real fieldname you can theoretically insert "--div--" and you will have a divider line shown.
However this is not rendered by default so it has no significance. Using "newline" for Part 3., this Tab will be
show in a newline.

Example:
"types" => Array (
    "0" => Array("showitem" => "
        --div--;Your Label,field1,field2,
        --div--;Your Label2;newline,field3,field4
    ")
)
...

Done, but I found this notice to be particularly unclear. I may have overstepped my privileges, but I took the liberty of changing it to: "Notice: Instead of a real fieldname you can insert "--div--" and you should have a divider line shown. However this is not rendered by default. If you set the dividers2tabs option (see ['ctrl'] section), each –div-- will mark define a new tab. Furthermore using a value "newline" for Part 3, will start a newline with this tab." I found it important to repeat the alternate use of --div-- (to create tabs), especially since the "newline" parameter didn't make sense otherwise.

Stanislas: Adding property transformBoldAndItalicTags. Bugtracker reference: https://forge.typo3.org/issues/17792

In RTE API, Transformations, Page TSConfig, The ->PROC object, insert in table after property denyTags:

Property:
transformBoldAndItalicTags
Data type:
Boolean
Description:
(Applies for “ts_transform” and "css_transform" only (function getKeepTags))

Default is to convert b and i tags to strong and em tags respectively in the direction of the database, and to convert back strong and em tags to b and i tags in the direction of the RTE.

This transformation may be disabled by setting this property to 0.

Done

Stanislas: Adding property preserveDIVSections. Bugtracker reference: https://forge.typo3.org/issues/17857

In RTE API, Transformations, Page TSConfig, The ->PROC object, insert in table after property useDIVasParagraphTagForRTE:

Property:
preserveDIVSections
Data type:
Boolean
Description:
(Applies for "ts_transform" and "css_transform" only)

If set, div sections will be treated just like blockquotes. They will be treated recursively as external blocks. 

Done

Jeff: Feature #6672: Add tab filtering and file type filtering to TCA-defined link wizard

In "Wizard scripts in the core", "browse_links.php":

 These are the available parameters:
 
 Key: allowedExtensions
 Type: string
 Description: Comma separated list of allowed file extensions. By default, all
 extensions are allowed.
 
 Key: blindLinkOptions
 Type: string
 Description: Comma separated list of link options that should not be displayed.
 Possible values are file, mail, page, spec, and url. By default, all link
 options are displayed.

Added. Note that this wizard had no parameters list yet, so I added a new table for them. I also added examples of parameters values to the existing configuration example.


Ingmar, 24.11.2007: [TYPO3-core] Re: RFC: Feature #6770: Implement option to use different Flexform Datastructures per type field value:

 $TCA array reference => ['columns'][fieldname]['config'] / TYPE: "flex"
 Changed Property: ds_pointerField
Type: Array
 Description:
	Old: "Fieldname in the record which points to the field where the key for “ds” is found"
	New: "Fieldname(s) in the record which point to the field where the key for “ds” is found. Up to two fieldnames can be specified comma separated."

 ======================================

 $TCA array reference => ['columns'][fieldname]['config'] / TYPE: "flex"
 Changed Property: ds
 Type: Array (used to be incorrectly documented as "string")
 Description: (doc changes as unified diff)
	@@ -4,6 +4,8 @@
	 
	 Default key is “default” which is what you should use if you do not have a “ds_pointerField” value of course.
	 
	+If you specified more than one ds_pointerField, the keys in this “ds” array should contain comma-separated value pairs where the asterisk * matches all values (see the example below). If you don't need to switch for the second ds_pointerField, it's also possible to use only the first ds_pointerField's value as a key in the "ds" array without necesserily suffixing it with ",*" for a catch-all on the second ds_pointerField.
	+
	 For each value in the array there are two options:
	    1. Either enter XML directly
	    2. Make a reference to an external XML file
	@@ -41,6 +43,19 @@
	     'ds_pointerField' => 'list_type',
	     'ds' => array(
		 'default' => 'FILE:EXT:mininews/flexform_ds.xml',
	     )
	 )


	+Example using two ds_pointerFields (as used for tt_content.pi_flexform since TYPO3 4.2.0):
	+'config' => Array (
	+    'type' => 'flex',
	+    'ds_pointerField' => 'list_type,CType',
	+    'ds' => array(
	+        'default' => 'FILE:...',
	+	'tt_address_pi1,list' => 'FILE:EXT:tt_address/pi1/flexform.xml', // DS for list_type=tt_address_pi1 and CType=list
	+	'*,table' => 'FILE:EXT:css_styled_content/flexform_ds.xml', // DS for CType=table, no matter which list_type value
	+	'tx_myext_pi1' => 'FILE:EXT:myext/flexform.xml', // DS for list_type=tx_myext_pi1 without specifying a CType at all
	+    )
	+)
	 

Done

Added by Malte Jansen 07-11-26, confirmed by Ingo

TYPO3 Extension API -> 2.1. Extension Architecture -> ext_emconf.php

Remove Keys "TYPO3_version" and "PHP_version" because they are redundant.

Done, but we should pretty urgently update the description of the "dependencies" property since it has replaced those 2 properties, plus offers quite a good deal of configurations.

"Re: [TYPO3-core] RFC: #6259 Disabling Tabs with no fields II", 20.11.2007 14:03

$TCA array reference -> Reference for the ['ctrl'] section:
-> Key: dividers2tabs

Paramter: Integer (value of the description)

Description:
This key activates the interpreation of tabs

0: disabled (default)
1: activeated, empty tabs are removed
2: activeated, empty tabs are disabled

If Tabs are activeted, all “--div--” fieldnames in the types configuration will be interpreted as starting a new tab in a tab-menu for the record. The second part after “--div--” will be the title of the tab then.

If you place a “--div--” field as the very first element in the types configuration it will just be used to set the title of the first tab (which is by default “General”).

If you like to place the main palette on its own tab in the end, simply add “--div--” as the very last field.

Examples:

....

Done, with English corrected

Added 27.12.2007 by Dmitry Dulepov Additions to section 7.1 "<T3DataStructure>" regarding CSH in flexforms.

in the first table (describes <T3DataStructure>) add three rows after <T3DataStructure>:

Element: <TCEforms>
Description: Contains details about visual representation of sheets. If there is only a single sheet, applies to implicit single sheet.
Child elements: <sheetTitle> <cshFile>

Element: <sheetTitle>
Description: Title of the sheet. Mandatory for any sheet except the first (which gets "General" in this case). Can be a plain string or a reference to language file using standard LLL syntax. Ignored if sheets are not defined for the flexform.
Child elements:

Element: <cshFile>
Description: CSH language file for fields inside the flexform. Refer to section 7.2 of this document on the format of language files and to section 3.9 of "Inside TYPO3" document for information about CSH.
Child elements:

Done. I removed the chapter number references and replaced them with chapter names, because the headings are not numbered in the SXW files.

Additions to section 4.2 "$TCA array reference" section about "group" fields regarding disabling controls.

Add row before "wizards" (last row in the table):

Key: disable_controls Datatype: string Description: Disables subcontrols inside "group" control. Possible values are: browser (disabled browse button for list control), list (disables list and browse button) and upload (disables upload control). See example image below. Scope: Display/Proc.

Feature-6888.gif

Done

Manfred Widmann, 04.01.2008: [TYPO3-dev] Little Error in Core API Doc:

   On Page 120 (during description of TCA) it's about
   ['columns'][fieldname]['config'] / TYPE: "none"
   The documentation claims: "type string [Must be set to "" (blank string!)]"
   The later is wrong: it has to be set to "none" - not to ""!

Corrected


Benni, 2008-01-10: AJAX in the TYPO3 Backend

Maybe you want to add a new section in the Core Docs API for it.

==== AJAX in the TYPO3 Backend ====

In TYPO3 4.2beta1 a new model for writing AJAX code in the TYPO3 Backend was introduced. Although there were some parts in the TYPO3 Backend that used AJAX already, they are now unified into a single interface that handles errors and dispatches the different calls to their final locations. This way it is ensured that e.g. a BE user is logged in and all TYPO3 variables are loaded.
The whole architecture builds on top of successful techniques developers already know. It's a mixture between the eID concept from the TYPO3 Frontend, the hooking idea we know from other places in TYPO3, piped through a single small AJAX file "typo3/ajax.php" that creates a PHP AJAX object to see if an error occured or not. If something went wrong, the X-JSON header is set to false and the client-side AJAX request (an AJAX responder in the Prototype Javascript framework) will know that there is an error.

==== In-Depth Analysis ====

=== Client-Side programming ===

On the client-side we are using the Prototype JS library (located in typo3/contrib/prototype/prototype.js). If you have used it already, you know that you can make AJAX calls with AJAX.Request, AJAX.Updater and AJAX.PeriodicalUpdater. We extended the library and hooked in these objects, or better: in the callbacks users can define. If an AJAX request is made to our server-side component (typo3/ajax.php), everything developers need to do is to call this URL and add a unique, already registered parameter for their ajaxID. Their defined "onComplete" and "onSuccess" are only rendered if the X-JSON header is set to true by the server-side script. If the X-JSON header is set to false, the Responder checks if there is a callback function named "onT3Error" and executes it instead of the onComplete method. If the "onT3Error" method is not defined, the default TYPO3 error handler will be displaying the error in the TYPO3 backend. If the X-JSON header is set to false, the "onSuccess" callback will not be executed as well as the but an error message will be shown in the notification area. This behaviour is done automatically with every AJAX call to "ajax.php" made through Prototype's AJAX classes. This responder is also only active if "typo3/js/common.js" is added to the base script.

=== Server-side programming ===

If you look into "typo3/ajax.php", it is only a small dispatcher script. It checks for an ajaxID in the TYPO3_CONF_VARS['BE']['AJAX'] array and tries to execute the function pointer. The function has two parameters, where the first (an array) is not used yet. The second parameter is the TYPO3 AJAX Object (located in typo3/classes/typo3ajax.php) that is used to add the content that should be returned as the server-response to the Javascript part, or the error message that should be displayed. The X-JSON header will be set depending if "setError()" was called on this AJAX object. You can also specify if the object should return the result in a valid XML object tree, as text/html (default) or as a JSON object, see below.

The "ajaxID" is a unique identifier and can be used to override the existing ajax calls. Therefore you can extend existing AJAX calls that already exist in the backend by redirecting it to your function. But be aware of the side-effects of this feature: Other extensions could overwrite this function as well (similar problem as with XCLASSing or single inheritance in OOP).

Also, for every TYPO3 request, you will now have a TYPO3_REQUESTTYPE variable that can be used for bitwise comparison. You can now check if you're in Backend or Frontend or in an valid AJAX request with
if (TYPO3_REQUESTTYPE & TYPO3_REQUESTTYPE_AJAX)
to see if you're calling through the new AJAX interface.

=== Different Content Formats ===

As with every AJAX response you can send it in different response formats.

 * text/html - plain text
 * text/xml  - strict XML formatting
 * application/json - JSON notation

You can also specify the contentFormat in the AJAX object like this:
	$ajaxObj->setContentFormat('json');

For the keyword you can choose between "plain" (default), "xml" and "json", "jsonbody" and "jsonhead".
Here are the specifics for each format:

== Plain Text ==

The content array in the backend will be concatenated and returned uninterpreted.
The result will be available in the transport object as a string through "xhr.responseText".

== XML ==

The content needs to be valid XML and will be available in javascript as "xhr.responseXML".

== JSON ==

The content is put through the service in "typo3/contrib/json/json.php" and is then available in JSON notation through the second parameter in the onComplete / onSuccess methods, and additionally in the "responseText" part of the transport object ("xhr.responseText"). If it is set to "jsonbody", only the latter variable is filled, if "jsonhead" is set, it is only in the second parameter. This is useful to save traffic and you can use it with whatever format you like.


==== What to do when you're developing AJAX in the TYPO3 Backend ====

This should be a small guide for you to use this new feature in your AJAX scripts.

=== How to choose the right ajaxID ===

The ajaxID consists of two parts, the class name and the action name, delimited by "::" ("<class>::<action>").
Please note that the ajaxID is just an system-wide identifier to register your AJAX handler. Even if it looks like a static function call, it won't be executed and has no technical dependencies. But it is required for all developers to use a common naming scheme as described above, since it might prevent from using identical names in different extensions.

Some good examples for an ajaxID:
* SC_alt_db_navframe::expandCollapse
* t3lib_TCEforms_inline::processAjaxRequest
* tx_myext_module1::executeSomething

Some bad examples for an ajaxID:
* search::findRecordByTitle
* core::reloadReferences
* inline::processAjaxRequest
* updateRecordList

=== Server-Side ===

1) Register your unique ajaxID, at best prepended with your extID, in the TYPO3 backend by adding the following line to your "ext_localconf.php" (btw: This way you can also overwrite existing AJAX calls):

$TYPO3_CONF_VARS['BE']['AJAX']['tx_myext::ajaxID'] = 'filename:object->method';

A working example would be:
$TYPO3_CONF_VARS['BE']['AJAX']['SC_alt_db_navframe::expandCollapse'] = 'typo3/alt_db_navframe.php:SC_alt_db_navframe->ajaxExpandCollapse';

2) Create a target method to do the logic on the server-side: Similar to the existing hooking mechanism, as with every "callUserFunction", the target method (here: ajaxExpandCollapse) will have two function parameters. The first one is an array of params (not used right now), the second is the TYPO3 AJAX Object (see typo3/classes/class.typo3ajax.php for all available methods). You should use this to set the content you want to output or to write the error message if something went wrong. 

public function ajaxExpandCollapse($params, &$ajaxObj)  {
		$this->init();
		// do the logic...
		if (empty($this->tree))       {
				$ajaxObj->setError("An Error occured");
		} else  {
				// the content is an array that can be set through $key / $value pairs as parameter
				$ajaxObj->addContent('tree', "The tree works...");
		}
}


So, the server-side part is now complete. Let's move over to the client-side.

=== Client-part ===

3) In order for you to use Javascript you have to add this two lines of PHP code in your PHP script (available in template.php, your template document). So it is loaded

$this->doc->loadJavascriptLib('contrib/prototype/prototype.js');
$this->doc->loadJavascriptLib('js/common.js');

4) With prototype on the client side, it's quite simple to add a new AJAX request in Javascript:

new Ajax.Request('ajax.php', {
	method: 'get',
	parameters: 'ajaxID=SC_alt_db_navframe::expandCollapse',
	onComplete: function(xhr, json) {
		// display results, should be "The tree works"
	}.bind(this),
	onT3Error: function(xhr, json) {
		// display error message, will be "An Error occured" if an error occured
	}.bind(this)
});

You can see, that it's almost the same, except that we introduce a new callback function "onT3Error", which is optional. It is called if the method "setError" on the server-side was called. Otherwise "onComplete" will be called. If you do not define "onT3Error", then the error message will be shown in the TYPO3 notification area in the backend. Our AJAX responders also work with the "onSuccess" callback, but the onT3Error is only executed with "onComplete".

This should be all. Please note that our TYPO3 BE AJAX mechanism works best with the prototype JS library. If you want to create similar approaches for other JS frameworks, have a look at "typo3/js/common.js".

Added in "TYPO3 API overview" before chapter "Various examples" after discussion with Benni

Olly, 2008-02-03: 17500: TYPO3 Core - Localization of child records [Closed; assigned to Oliver Hader]

doc_core_api, $TCA array reference, TYPE: "inline"
-> new properties for ['columns'][fieldname]['config']['appearance']
	* showPossibleLocalizationRecords (boolean): Show unlocalized records which are in the original language, but not yet localized
	* showRemovedLocalizationRecords (boolean): Show records which were once localized but do not exist in the original language anymore
	* showAllLocalizationLink (boolean): Defines whether to show the "localize all records" to fetch untranslated records from the original language
	* showSynchronizationLink (boolean): Defines whether to show a "synchronize" link to update to an 1:1 translation with the original language

-> new property for ['columns'][fieldname]['config'], insert after property 'appearance'
	* Key: behaviour
	  Datatype: array
	  Description: Has information about the behaviour of child-records, namely:
		* localizationMode ('keep', 'select'): Defines in general whether children are really localizable (set to 'select') or just taken from the default language (set to 'keep'). If this property is not set, but the affected parent and child tables were localizable, the mode 'select' is used by default.
			+ Mode 'keep': This is not a real localization, since the children are taken from the parent of the original language. But the children can be moved, deleted, modified etc. on the localized parent which - of course - also affects the original language.
			+ Mode 'select': This mode provides the possibility to have an selective localization and to compare localized data to the pendants of the original language. Furthermore this mode is extended by a 'localize all' feature, which works similar to the localization of content on pages, and a 'synchronize' feature which offers the possibility to synchronize a localization with its original language.
		* localizeChildrenAtParentLocalization (boolean): Defines whether children should be localized when the localizion of the parent gets created
		
doc_core_api, $TCA array reference, TYPE: "select"
-> new property for ['columns'][fieldname]['config']
	* Key: localizeReferencesAtParentLocalization
	  Datatype: boolean
	  Description: Defines whether referenced records should be localized when the current record gets localized (mostly used in Inline Relational Record Editing)

Done. Olly confirmed property types for "behaviour" and "localizeReferencesAtParentLocalization".

Olly, 2008-02-04: 17125: TYPO3 Core - Storage page for child records [Closed; assigned to Oliver Hader]

doc_core_api, $TCA array reference, TYPE: "inline"
-> after the general description
	Note: TCAdefaults.<table>.pid = <page id> can be used to define the pid of new child records. Thus, it's possible to have special storage folders on a per-table-basis.
-> new properties for ['columns'][fieldname]['config']['behaviour']
	* disableMovingChildrenWithParent (boolean): Disables that child records get moved along with their parent records.

Done

doc_indexed_search

Stucki, 31.08.2007: Re: [TYPO3-core] RFC: Bug 4470: indexed search pagebrowser shows wrong numbers:

 New property: search.exactCount
 Type: boolean
 Description:
  Force permission check for every record while displaying search results. Otherwise, records are only checked
  up to the current result page, and this might cause that the result counter does not print the exact number
  of search hits.
  By enabling this setting, the loop is not stopped, which causes an exact result count at the cost of an
  (obvious) slowdown caused by this overhead.
  See property "show.forbiddenRecords" for more information.
 Default: 

Done

Baschny, 23.11.2007: Re: [TYPO3-core] RFC: indexed_search: join_pages configurable:

In chapter "1.5 Configuration" add:

New property: search.skipExtendToSubpagesChecking
Type: boolean
Description: 
 If set to false (default), on each search the complete page tree will be
 transversed to check which pages are accessible, so that the
 extendToSubpages can be considered. This will work with a limited number
 of page-ids (which means most sites), but will result in slow
 performance on huge page trees.

 If set to true, then the final result rows are joined with the pages
 table to select pages that are currently accessible. This will speed up
 searching in very huge page trees, but on the other hand
 extendToSubpages will NOT be taken into account!
Default: 0

Then in 1.6 the whole "Handling extendToSubpages - or not" part can be dropped.

Done