Since "types"-configuration does not apply for FlexForms and since a feature available as special configuration is sometimes needed regardless of type value you can also configure the default value of the special configuration. This is done with a key in the ['columns'][fieldname] array. Thus, the alternative configuration for the example above could be:

        'TEST01' => Array (

            'label' => 'TEST01: Text field',

            'config' => Array (

                'type' => 'text',

            ),

            'defaultExtras' => 'nowrap'

        ),

        ....

    ),

    'types' => Array (

        '0' => Array('showitem' => 'hidden;;1, type, title, test_template, TEST01'),

This works equally well.

This table lists the options for keywords in special configuration. Each keyword is followed by a value wrapped in [] (square brackets).

The class “t3lib_softrefproc” contains generic parsers for the most well-known types which are default for most TYPO3 installations. This is the list of the possible keys:

These are by default set up in the config_default.php file:

'SC_OPTIONS' => Array(

'GLOBAL' => array(

'softRefParser' => array(

'substitute' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'notify' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'images' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'typolink' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'typolink_tag' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'TSconfig' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'TStemplate' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'ext_fileref' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'email' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

'url' => 't3lib/class.t3lib_softrefproc.php:&t3lib_softrefproc',

)

)

),

Soft References can also be user defined. It is easy to set them up by simply adding new keys in $TYPO3_CONF_VARS['SC_OPTIONS']['GLOBAL']['softRefParser']. Use keynames based on the extension you put it in, eg. “tx_myextensionkey”.

The class containing the soft reference parser must have a function named “findRef”. Please refer to the class “t3lib_softrefproc” from t3lib/ for the API to use and return.

The value of the “wizards” key in the field config-array is an array. Each key is yet an array which configures the individual wizards for a field. The order of the keys determines the order the wizards are displayed. The key-values themselves play no important role (except from a few reserved words listetd in a table below).

The configuration for the new / edit / list links above looks like this:

   1: 'usergroup' => Array (

   2:     'label' => 'Group:',

   3:     'config' => Array (

   4:         'type' => 'select',

   5:         'foreign_table' => 'be_groups',

   6:         'foreign_table_where' => 'ORDER BY be_groups.title',

   7:         'size' => '5',

   8:         'maxitems' => '20',

   9:         'wizards' => Array(

  10:             '_PADDING' => 1,

  11:             '_VERTICAL' => 1,

  12:             'edit' => Array(

  13:                 'type' => 'popup',

  14:                 'title' => 'Edit usergroup',

  15:                 'script' => 'wizard_edit.php',

  16:                 'popup_onlyOpenIfSelected' => 1,

  17:                 'icon' => 'edit2.gif',

  18:                 'JSopenParams' => 'height=350,width=580,status=0,menubar=0,scrollbars=1',

  19:             ),

  20:             'add' => Array(

  21:                 'type' => 'script',

  22:                 'title' => 'Create new group',

  23:                 'icon' => 'add.gif',

  24:                 'params' => Array(

  25:                     'table'=>'be_groups',

  26:                     'pid' => '0',

  27:                     'setValue' => 'prepend'

  28:                 ),

  29:                 'script' => 'wizard_add.php',

  30:             ),

  31:             'list' => Array(

  32:                 'type' => 'script',

  33:                 'title' => 'List groups',

  34:                 'icon' => 'list.gif',

  35:                 'params' => Array(

  36:                     'table'=>'be_groups',

  37:                     'pid' => '0',

  38:                 ),

  39:                 'script' => 'wizard_list.php',

  40:             )

  41:         )

  42:     )

  43: ),

The wizard configuration takes place in line 9 and throughout. Two reserved keywords are used in line 10 and 11 to set arrangement settings for the display of icons.

Then a new wizard is configured in lines 12 (edit), 20 (add) and 31 (list).

Each wizard is identified by a key string. However some strings are reserved for general configuration. These are listed in this table and as a rule of thumb they are prefixed with an underscore ("_"):

This table lists the general configuration options for (almost) all wizard types. In particular the value of the "type" key is important because it denotes what additional options are available.

In the next section all the default core wizard scripts are demonstrated with examples. Before that, here is a few examples of wizards that does not require an external script.

Example - Selector box of preset values

You can add a selector box containing preset values next to a field:

When an option from the selector box is selected it will be transferred to the input field of the element. The mode of transfer can be either substitution (default) or prepending or appending the value to the existing value.

The example above is achieved by this configuration:

   1: 'TEST01' => Array (

   2:     'label' => 'TEST01: Preset values',

   3:     'config' => Array (

   4:         'type' => 'input',

   5:         'size' => '10',

   6:         'wizards' => array(

   7:             'select' => array(

   8:                 'type' => 'select',

   9:                 'mode' => '',

  10:                 'items' => array(

  11:                     array('Label 1', 'Value 1'),

  12:                     array('Label 2', 'Value 2'),

  13:                     array('Label 3', 'Value 3'),

  14:                 )

  15:             ),

Example - User defined wizard (processing with PHP function)

The "userFunc" type of wizard allows you to render all the wizard code yourself. Theoretically, you could produce all of the other wizard kinds ("script", "popup", "colorbox" etc) with your own user function rendering the similar HTML.

In this example I will do two things with the wizard:

1. show how you can manipulate the HTML code of the form field the wizard is attached to

2. Add two links which access the content of the form field.

The result looks like this:

The configuration needed is this:

   1: 'wizards' => array(

   2:     'uproc' => array(

   3:         'type' => 'userFunc',

   4:         'userFunc' => 'user_class->user_TCAform_procWizard',

   5:         'params' => array(

   6:             'wrapTag' => 'u'

   7:         )

   8:     ),

And obviously, you need the code listing of the class, "user_class", as well:

   1: class user_class {

   2:     function user_TCAform_procWizard($PA, $fobj)    {

   3:             // Wrapping the field item in a <div> with border.

   4:             // Notice that $PA['item'] is passed by reference, so any manipulation

   5:             // is automatically affecting the field without explicitly returning a value!

   6:         $PA['item'] = '<div style="border: maroon 4px dashed;">'.$PA['item'].'</div>';

   7:

   8:             // Adding wizard HTML code: Showing value in JavaScript ALERT box:

   9:         $onclick = "alert('This is the field value: ' + ".

  10:                     "document.".$PA['formName']."['".$PA['itemName']."'].value);".

  11:                     "return false;";

  12:         $output = '<a href="#" onclick="'.htmlspecialchars($onclick).'">[Show field value]</a><br/>';

  13:

  14:             // Adding wizard HTML code: Showing value in JavaScript ALERT box:

  15:         $wTagBegin = '<'.$PA['params']['wrapTag'].'>';

  16:         $wTagEnd = '</'.$PA['params']['wrapTag'].'>';

  17:         $onclick = "document.".$PA['formName']."['".$PA['itemName']."'].value=".

  18:                     "'".$wTagBegin."' + document.".$PA['formName']."['".$PA['itemName']."'].value + '".$wTagEnd."';".

  19:                     implode('',$PA['fieldChangeFunc']).    // Necessary to tell TCEforms that the value is updated.

  20:                     "return false;";

  21:         $output.= '<a href="#" onclick="'.htmlspecialchars($onclick).'">'.

  22:                     htmlspecialchars('[Wrap in '.$wTagBegin.'...'.$wTagEnd.']').

  23:                     '</a>';

  24:

  25:             // Return Wizard HTML:

  26:         return $output;

  27:     }

  28: }

In line 6 you see how the form field is wrapped in a <div> tag. Notice how all you need to do is to change the value of $PA['item'] since that value is passed by reference to the function and therefore doesn't need a return value - only to be changed.

In line 9-12 you see the first link created. It just reads the current value of the <input> field and shows in an alert box.

In line 15-23 you see how the value of the key "wrapTag" from the "params" array (reserved space for user defined parameters) is used to create a link which will wrap whatever content of the input field in an HTML tag, in this case a <u> tag.

Finally the wizard HTML created is returned.

Obviously you will have to find out what kind of information is hidden in the $PA variable. A TYPO3 specific way of doing this is to use "debug($PA);" which will output the content of the array in a nicely formatted table. In PHP there are native functions like "print_r" or "vardump".

This script links to a form which allows you to create a new record in a given table which may optionally be set as the value on return to the real form.

In this example I have added the wizard script "wizard_add.php" to the well known Frontend User Group selector:

When the wizard icon is clicked the user is directed to a form where a new frontend user group can be created:

When the new group is saved and the user clicks the close button of the form the new group is automatically inserted as the current value.

The configuration looks like this:

   1: 'fe_group' => Array (

   2:     'exclude' => 1,

   3:     'label' => 'LLL:EXT:lang/locallang_general.php:LGL.fe_group',

   4:     'config' => Array (

   5:         'type' => 'select',

   6:         'items' => Array (

   7:             Array('', 0),

   8:             Array('LLL:EXT:lang/locallang_general.php:LGL.hide_at_login', -1),

   9:             Array('LLL:EXT:lang/locallang_general.php:LGL.any_login', -2),

  10:             Array('LLL:EXT:lang/locallang_general.php:LGL.usergroups', '--div--')

  11:         ),

  12:         'foreign_table' => 'fe_groups',

  13:         'wizards' => array(

  14:             'add' => Array(

  15:                 'type' => 'script',

  16:                 'title' => 'Add Frontend Group',

  17:                 'icon' => 'add.gif',

  18:                 'params' => Array(

  19:                     'table' => 'fe_groups',

  20:                     'pid' => '###STORAGE_PID###',

  21:                     'setValue' => 'set'

  22:                 ),

  23:                 'script' => 'wizard_add.php'

  24:             ),

  25:         )

  26:     )

  27: ),

Line 15 defines the type to be "script" which is set to "wizard_add.php" in line 23. The parameters that instructs the Add-wizard how to handle the creation is done in line 19-21; The table is of course fe_groups and the pid where the user is created is the Storage Folder set for the website. Of course this requires a storage folder to exist. Finally, "setValue" tells the wizard script that the uid of the new record should substitute any current value.

The Edit wizard gives you a shortcut to edit references in "select" or "group" type form elements.

The configuration below is what sets up this wizard.

   1: 'wizards' => array(

   2:     'edit' => Array(

   3:         'type' => 'popup',

   4:         'title' => 'Edit usergroup',

   5:         'script' => 'wizard_edit.php',

   6:         'icon' => 'edit2.gif',

   7:         'JSopenParams' => 'height=350,width=580,status=0,menubar=0,scrollbars=1',

   8:     ),

This time the type fitting the wizard script best is the "popup" type. It could have been the "script" type as well, but it just works slightly better in this case if it is a pop-up so we don't leave the original form.

There are no parameters to pass along like there were for the Add wizard.

This links to the Web>List module for only one table and allows the user to manipulate stuff there.

By clicking the icon you will get to the Web>List module. Notice how the "Back" link is found in the upper right corner, taking you back to the edit form.

This wizard has a few parameters to configuration in the "params" array:

The configuration look like this:

   1: 'wizards' => array(

   2:     'list' => Array(

   3:         'type' => 'script',

   4:         'title' => 'List groups',

   5:         'icon' => 'list.gif',

   6:         'params' => Array(

   7:             'table'=>'fe_groups',

   8:             'pid' => '###STORAGE_PID###',

   9:         ),

  10:         'script' => 'wizard_list.php',

  11:     ),

The type is also the "script" type. In the "params" array the table and pid passed to the script is set.

The colorpicker wizard allows you to select a HTML color value from a user friendly pop-up box. The wizard type is "colorbox" which will first of all add a colored box next to an input field:

The color of the box is set to the value of the text field. Clicking the box will open a popup window with the color picker wizard script showing itself:

Here you can select from the web-color matrix, pick a color from the sample image or select a HTML-color name from a selector box.

The configuration needed looks like this:

   1: 'TEST01' => Array (

   2:     'label' => 'TEST01: Color picker wizard',

   3:     'config' => Array (

   4:         'type' => 'input',

   5:         'size' => '30',

   6:         'wizards' => array(

   7:             'colorpick' => array(

   8:                 'type' => 'colorbox',

   9:                 'title' => 'Color picker',

  10:                 'script' => 'wizard_colorpicker.php',

  11:                 'dim' => '20x20',

  12:                 'tableStyle' => 'border: solid 1px black; margin-left: 20px;',

  13:                 'JSopenParams' => 'height=550,width=365,status=0,menubar=0,scrollbars=1',

  14:                 'exampleImg' => 'gfx/wizard_colorpickerex.jpg',

  15:             )

  16:         )

  17:     )

  18: ),

Notice the wizard type is "colorbox".

The forms wizard is used typically with the Content Elements, type "Mailform". It allows to edit the code-like configuration of the mail form with a nice editor. This is shown in the introduction to Wizards above.

This is the available parameters:

The configuration used for the editor in Content Elements looks like this:

'forms' => Array(

    'notNewRecords' => 1,

    'enableByTypeConfig' => 1,

    'type' => 'script',

    'title' => 'Forms wizard',

    'icon' => 'wizard_forms.gif',

    'script' => 'wizard_forms.php?special=formtype_mail',

    'params' => array('xmlOutput' => 0)

)

The tables wizard is used typically with the Content Elements, type "Table". It allows to edit the code-like configuration of the tables with a nice editor.

This is the available parameters:

This is the configuration code used for the table wizard in the Content Elements:

'table' => Array(

    'notNewRecords' => 1,

    'enableByTypeConfig' => 1,

    'type' => 'script',

    'title' => 'Table wizard',

    'icon' => 'wizard_table.gif',

    'script' => 'wizard_table.php',

    'params' => array('xmlOutput' => 0)

),

This wizard is used to show a "full-screen" Rich Text Editor field. The configuration below shows an example taken from the Text field in  Content Elements:

'RTE' => Array(

    'notNewRecords' => 1,

    'RTEonly' => 1,

    'type' => 'script',

    'title' => 'LLL:EXT:cms/locallang_ttc.php:bodytext.W.RTE',

    'icon' => 'wizard_rte2.gif',

    'script' => 'wizard_rte.php',

),

This wizard is used for the TSconfig fields and TypoScript Template "Setup" fields. It is specialized for that particular situations and it is not likely you will need it for anything on your own.

The "Links" wizard is used many places where you want to insert link references. Not only in the Rich Text Editor but also in "typolink" fields:

Clicking the wizard icons opens the Element Browser window:

Such a wizard can be configured like this:

'link' => Array(

    'type' => 'popup',

    'title' => 'Link',

    'icon' => 'link_popup.gif',

    'script' => 'browse_links.php?mode=wizard',

    'JSopenParams' => 'height=300,width=500,status=0,menubar=0,scrollbars=1'

)

Notice how the "browse_links.php" script requires an extra parameter since it has to return content back to the input field (and not the RTE for instance which it also supports).

With $ICON_TYPES you can assign alternative icons to pages records based on the field 'module' in pages table. Each key is a value from the "module" field of page records and the value is an array with a key/value pair, eg. "icon" => "modules_shop.gif". The file reference is on the same format "iconfile" in [ctrl] section of TCA

This is the configuration found in "cms" extension and setting icons for some legacy extensions:

    // Setting ICON_TYPES

    $ICON_TYPES = Array(

        'shop' => Array('icon' => 'modules_shop.gif'),

        'board' => Array('icon' => 'modules_board.gif'),

        'news' => Array('icon' => 'modules_news.gif'),

        'dmail' => Array('icon' => 'modules_dmail.gif'),

        'fe_users' => Array('icon' => 'modules_fe_users.gif'),

        'approve' => Array('icon' => 'modules_approvals.gif')

    );

Usage of $ICON_TYPES is deprecated.

Commonly used language labels which can be used in the $TCA array and elsewhere. Has become obsolete - just use the values of each entry directly.

For backwards compatibility $LANG_GENERAL_LABELS are still available but deprecated. This is the default values:

$LANG_GENERAL_LABELS = array(

    'endtime' => 'LLL:EXT:lang/locallang_general.php:LGL.endtime',

    'hidden' => 'LLL:EXT:lang/locallang_general.php:LGL.hidden',

    'starttime' => 'LLL:EXT:lang/locallang_general.php:LGL.starttime',

    'fe_group' => 'LLL:EXT:lang/locallang_general.php:LGL.fe_group',

    'hide_at_login' => 'LLL:EXT:lang/locallang_general.php:LGL.hide_at_login',

    'any_login' => 'LLL:EXT:lang/locallang_general.php:LGL.any_login',

    'usergroups' => 'LLL:EXT:lang/locallang_general.php:LGL.usergroups',

);

To find places in your backend code where this should probably be implemented search for:

"each($TCA)" - This is potentially dangerous in a construction like this:

while(list($table,$config)=each($TCA))

where $config would obtain non-complete content. Instead it should look like:

while(list($table)=each($TCA)){

t3lib_div::loadTCA($table);

$config=$TCA[$table]

...

}

\[“?(palettes|types|columns|interface)”?\] (regex) - to find places where the palettes, types, columns and interfaces keys are used - which would require the whole array to be loaded!

It's recommended to always call the function t3lib_div::loadTCA() before using the non-[ctrl] sections of the $TCA array. The function returns immediately if the table is already loaded, so the overhead should be small and the importance is great.

What we see is, when showing a page in Web>List where all tables are loaded, the dynamic loading of tables includes a little overhead (177-173=4 ms) regardless of script-caching. This seems fair, probably due to file operations. It's also evident that the script-caching boosts the parsing considerably in both cases, saving approximately 150 ms in parsetime!

The Web>Info module does not load any tables (at least not in the mode, this was tested). This is the whole point of all this - that the full table definitions are loaded only if needed (as they were by the Web>List module). Again the point of caching is clear. But the main thing to look at is, that the Web>Info module is loaded in 66/136 seconds (cache/non-cache) with dynamic loading (was later tested to 60/118 ms when tt_content was not loaded by default) which is LOWER than if the whole tables.php was included (72/174 ms).

At this point the performance gain is not significant but welcomed. However the mechanism of dynamic loading of tables provides the basis for much greater number of tables in TYPO3. Testing 31 duplicates of the tt_content table added to the default number of configured tables (total of 62 tables configured) gave this benchmark:

This shows once again the work of the caching (1090-580 ms gained by PHPA) but clearly demonstrates the main objective of dynamic loading; The Web>Info module is not at all affected by the fact that 31 big tables has been added.

The serialized size of the $TCA in this case was measured to approx 2MB. The total number of KB in table-definition PHP-files was approx. 1.7 MB.

Extreme tests of this configuration has also been done.

A duplicate of tt_content was added x number of times and yielded these results:

The configuration of tt_content is approx. 52 kb PHP code. The testing was done just loading the content into $TCA - no further processing. However serializing the $TCA array (when that was tested) gave a double up on the amount of memory the httpd process allocated. This was to expect of course.

From this table we learn, that PHP does not crash testing this. However it makes not much sense to use 500 tables of this size. 250 tables might be alright and 100 tables is a more realistic roof over the number of tables in TYPO3 of the size of tt_content!

Conducting the same experiment with a table configuration of only 8 kb with 9 fields configured (a reduced configuration for the tt_content duplicate - which represents a more typical table) yielded these results: