Any change to the TYPO3 CMS Core that requires documentation or has an impact on existing documentation must be accompanied by the relevant changes to the proper manual. This is especially true for new or modified features, in particular APIs, TypoScript or TSconfig properties.
When you push such a change to Gerrit, you are requested to take the following steps:
- Open an issue in the manual(s) that is(are) impacted (if unsure which, look at the list below for help).
- In this issue set a relation to the Core issue using the Related issues field
- Set the Target Version to the one corresponding to the TYPO3 CMS Core (if it's missing, please content the Documentation Team, we will add it).
- Document the change in the Description of the issue. If it's lengthy, feel free to set up a wiki page and point to it. If you don't feel at ease writing about the change, don't worry, go ahead and the Documentation Team will improve on it. On the contrary, if you're fine writing, you're welcome to go the whole way and push a patch to the corresponding Git repository (see the section about contributing to the documentation).
Should the Core patch be dropped after all, please also mention this in the issue. This saves the Documentation Team quite a bit of looking things up.
Choosing a bug tracker
There exists one bug tracker per core manual. Use the chart below to help you choose which bug tracker to use in case you are unsure:
|Type of change||Bug tracker|
|TypoScript property or condition||TSRef: http://forge.typo3.org/projects/typo3v4-doc_core_tsref/issues|
|TSconfig property or condition||TSconfig: http://forge.typo3.org/projects/typo3v4-doc_core_tsconfig/issues|
|TCA property||TCA reference: http://forge.typo3.org/projects/typo3v4-doc_core_tca/issues|
|API or other way of interacting with TYPO3, information for extension developers (but see below for more specific topics)||Core APIs: http://forge.typo3.org/projects/typo3v4-doc_core_api/issues|
|Changes relating specifically to TYPO3 services||TYPO3 Services: http://forge.typo3.org/projects/typo3v4-doc_core_services/issues|
|Changes or improvements related to security||Security Guide: http://forge.typo3.org/projects/typo3v4-doc_guide_security/issues|
|Skinning API||Skinning Guidelines: http://forge.typo3.org/projects/typo3v4-doc_core_skinning/issues|
|General information about the inner working of TYPO3||Inside TYPO3: http://forge.typo3.org/projects/typo3v4-doc_core_inside/issues|
|Introduction Package: any change to the IP has an impact on the Getting Started tutorial||Getting Started: http://forge.typo3.org/projects/typo3v4-doc_tut_quickstart/issues|
Pending documentation (4.5)
CSH for FlexForms
CSH for FlexForms is handled more cleanly but requires adjustments. This has an impact in particular for FE plugins. To continue displaying
the CSH for their FlexForm, the CSH file must be declared as for other elements, i.e.
The key is defined as follows:
[table name].[field name].[DS pointer field 1](.[DS pointer field 2])
The table and the field are those where the FlexForm is used. In most cases this will be "tt_content.pi_flexform". The next elements of the key (still separated with dots) are the values of the field or fields (there may be only one) defined in the "ds_pointerField" property for the TCA of the FlexForm field. In the case of plugin options, the "ds_pointerField" property is set to "list_type,CType", so the key would be of the form:
tt_content.pi_flexform.[value of list_type field].list
"list" being the value of the CType field for a FE plugin. To give a complete example, let's assume that the plugin used is from the "comments" extension, the full key will be:
because "comments_pi1" is the value found in the field "list_type" when using the plugin provided by the "comments" extension. So the "comments" extension would use the following call to register its FlexForm CSH:
With this new method, it is not necessary anymore to point to the CSH file from within the FlexForm's DS, though the "cshFile" tag should be left for compatibility with older versions of TYPO3.
On top of the above, it is advised (but not required) to use the "alttitle" in the CSH structure intensively, as it will improve the information displayed in the help pop-up window. In particular, don't forget to define the "general alttitle" which is used at the top of the window. Example:
<label index=".alttitle">My plugin's cool configuration options</label>
Pending documentation (4.4)
2010-02-19 by Benjamin Mack (on behalf of Steffen Gebert) (I think this can be removed again, as this functionality was changed, haven't checked though) to be placed in the table of chapt. 6 in doc_core_api
stylesheetDirectories Add all *.css files of a directory. Example: $TBE_STYLES['stylesheetDirectories'][$_EXTKEY] = 'EXT:myskin/stylesheets/custom/'; It is encouraged to separate the styles in two parts, once for the "structure" and the second for the "visual": $TBE_STYLES['stylesheetDirectories'][$_EXTKEY]['structure'] = 'EXT:myskin/stylesheets/structure/'; $TBE_STYLES['stylesheetDirectories'][$_EXTKEY]['visual'] = 'EXT:myskin/stylesheets/visual/';
SPRITE ICON API. Added on 2010-05-02 by Benjamin Mack - Should be a new section right after the skinning API part. Edited on 2010-05-25 by Steffen Ritter
Pending documentation (4.3)
Manual for the new media CE (should become part of the manual of CSS Styled Content) http://forge.typo3.org/attachments/11257/doc_core_mediace_v2.sxw
The manual has been written for TYPO3 4.3 (not 4.2 as the cover says) by SteffenK and proofread by Jeff; see 20284: Core - [Feature] New Multimedia CE [Closed to Steffen Kamper].
Jeff wrote in #20284: "Still needs another pass, restructuring, and more content before its officially released but its a step the in the right direction :)"
November 2011: As far as the document above describes the TypoScript properties of the cObjects MEDIA, SWFOBJECT and QTOBJECT, it is now integrated in TSref. -Christopher.
Changes committed to CoreDocs
When a pending documentation change is committed to the Core Documentation, it is removed from this page and moved to: