Documentation changes in 4.2
This page contains all changes that were introduced in TYPO3 4.2.
Contents |
doc_inst_upgr
Trunk version of the manual can be found at: http://forge.typo3.org/repositories/browse/team-docteam/doc_inst_upgr
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 11474: Store separate extlist for the frontend [closed]
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." http://typo3.org/documentation/document-library/references/doc_core_tsref/4.2.0/view/1/5/#id4149585 http://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 1585: Logging with class.tslib_fe.php + awstats + realurl [closed]
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-217922: stdWrap for doNotLinkIt & doNotShowLink [closed]
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-217921: recursive pidInList for select in cObj CONTENT [closed]
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-167396: hardcoded fieldset and legend around radio buttons [closed]
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 7849: ATagParams of GMENU got stdWrap! [closed]
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 3491: Linking between domains in the pagetree ignores simulate static documents [closed]: 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 6991: Enable stdWrap for wrapItemAndSub [closed]: Enable stdWrap for wrapItemAndSub
Change in TSref [tsref:config/->TMENUITEM->wrapItemAndSub]: Datatype: wrap/stdWrap
Done
Andreas Otto, 2007-08-21 5748: class.indexer: Indexing of meta description and keywords [closed]: 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: 5992: config.disableImgBorderAttr is not documented in TSRef [closed]
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: 2830: imgResource doesn't support stdWrap on minW and minH [closed]
'''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: 6464: Incorrect link handler configuration in TSref [closed]
Done
6258: Change config.uniqueLinkVars to 1 [closed] (rev. @2620 for 4.2): Set the default to 1 http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/7/3/
Done with one typo corrected in the description ("cosmetical" => "cosmetic")
Ralf Hettinger, 2007-11-09 4280: stdWrap for params in function cImage, class.tslib_content.php [closed]: 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 6833: Possibility to add inline JS to page [closed] 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 7337: stdWrap for menu > range & entrylevel [closed] TsRef, section HMENU
property: entryLevel Daty type: stdWrap (Description: no change)
Done. Data type is actually int /stdWrap
Uschi Renziehausen, 2008-02-11 7337: stdWrap for menu > range & entrylevel [closed] 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 3787: Patch: new option TSFE.jumpUrl_prefer301 = 1 [closed] 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:
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'
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 http://typo3.org/documentation/document-library/references/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) http://typo3.org/documentation/document-library/references/doc_core_tsconfig/4.1.0/view/1/2/#id3515957
Removed
Christian, 06.11.2007, 6641: Rename TSconfig Options dontSeparateNotinmenuPages and dontAlphasortNotinmenuPages [closed], (rev @2662 for 4.2) New user TSConfig options http://typo3.org/documentation/document-library/references/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, 9109: Enable feature in element browser in rte like in normal one [closed]
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 9320: Bugfix for temporary Filemounts [closed]
Olly, 2007-11-19: 6346: Enable overriding/renaming field labels by Page TSconfig [closed] (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: 5068: Integrate mod.web_list.deniedNewTables as opposite of allowedNewTables [closed]
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: 6888: Disabling some or all controls in "group" field [closed]
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. 6256: Newline for Tabs with divs2tabs [closed]
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: http://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: http://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.
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: 6087: Localization of child records [closed]
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: 5242: Storage page for child records [closed]
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
