Installing

Upgrading

To upgrade an existing installation of to 6.0, please follow these steps:

check your deprecation log if you are using deprecated stuff, which might be removed in 6.0

link the new sources from TYPO3

Visit the Install Tool:

Run through "Update wizards" which are new in 6.0 (you can now go through them using the "Next" button)

Use the "Database COMPARE" section and apply all database schema changes

Upgrading issues

List of known, incompatible Extensions

Below are links to pages listing extensions that are not compatible with version 6.x of TYPO3.
The list has been compiled during the Code Sprint in Stuttgart.
A total of 2234 extensions have been found to be incompatible as of Sept 1, 2012.

The reason why these extensions are not compatible is, that their code includes static function calls that have been removed from the TYPO3 API.

Note: While developing TYPO3 6.0 the strict deprecation policy (removal of deprecated methods 2 versions after they were marked as deprecated) of TYPO3 was followed to give extension developers enough time to adapt their extensions to upcomming changes on deprecated code.

Note: The list is not 100% accurate, since some extensions do check the TYPO3 version in use and then call the appropriate function.
There may be also extensions that are be incompatible and do not show up in the list.

Note: If you find extensions on the list that are compatible with version 6.0 (false positives), please add them here since any comments in the tables will be overwritten by future updates.

False positives:

nagios - extension checks TYPO3 version and only uses deprecated method t3lib_div::int_from_ver() in old TYPO3 versions. nagios 1.2.4 and newer versions have been tested and are compatible with TYPO3 6.0.

YAG TYPO3 Gallery - Is ready for TYPO3 6.0 since version 2.2.0

AJAX Social Network Components (toctoc_comments) - Is ready for TYPO3 6.0 since version 3.0.6, deprecated methods are checked against TYPO3-version and called according version.

Team developer helpers (abz_developer) - extension checks TYPO3 version, is working with 6.0

The table shows:

name of the extension

version of extension which has been tested

version of TYPO3 since which the extension will not work

function calls that are used by the extension, but no longer available in the TYPO3

status (extension authors may want to edit this field, i.e. "fixed in version *.*.*)

New installations

Changes and improvements

This will list all changes and improvements between TYPO3 4.7 and 6.0. For technical details see ChangeLog included in the typo3_src package or the end of the page.

Compatibility

Refactored bootstrap

With a bootstrap refactoring the index.php file located in the document root of
the installation was changed. If you are running a typo3 core source with a
symlink, make sure that this file is also a symlink to the cores index.php,
otherwise the frontend will be broken. If index.php is a copy of the source
file, make sure to install a fresh version from 6.0 sources.

Making use of namespaces

Since the beta1 version of TYPO3, the core makes use of namespaces. To keep compatibility with extensions, a compatibility layer is in place.
Calls for Core classes like t3lib_div will still work exactly the same as before, as the compatibility layer makes sure that old class names are aliased to the new namespaced ones.
Extension developers targeting releases that are compatible for TYPO3 version 6.0 and above are highly encouraged to use the namespaced classes from now on. If extensions are targeted for 6.x and below, it is totally fine to use old class names.
In 6.0 an additional compatibility layer was introduced for extensions that do a "require" on core class files. In this case the new class file at the new location will be required.
Extension developers are advised to make use of the class autoloading mechanism that has been introduced in TYPO3 version 4.3 and removing all "requires" (for core classes) in their code. Even if using "require" for own extension class files will of course still work, it is highly recommended to also use the autoloading for extension classes.
The additional compatibility layer for using require on old TYPO3 core class locations will be removed in TYPO3 version 6.2.

This extensive change in the TYPO3 infrastructure aims to further sync TYPO3 with Flow and Neos, make it easier to transit between the systems. Additionally, the switch had been used to streamline the class naming scheme, get rid of old naming clashes and make the classnames more meaningful. This will lower the entry barrier for new developers, too.

Deprecated methods

Deprecated methods that were initially targeted to be removed in TYPO3 4.8/6.0
have finally been removed. The deprecation log shows which functions were
declared to be deprecated and will be removed in the next TYPO3 versions.

Removed classes prior to scheduled deprecation removal

t3lib_BEDisplayLog: This class was used only by the old belog module, its
functionality is now encapsulated in EXT:belog itself. Since it is very
unlikely that the class was used by other external extensions, the file was
removed instead of deprecating it.

New XCLASS handling

The old way of registering XCLASSes in $TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS'] is
deprecated. Since TYPO3 CMS 6.0, XCLASS'es are registered in a TYPO3_CONF_VARS
sub-array, similar to the dependency injection mechanism in FLOW3. This should be
done in ext_localconf.php files of extensions.
Extension authors are advised to remove the three line XCLASS statement at the
bottom of class files now for any extension with a compatibility for 6.0 and above.
More information can be found at
XCLASS#XCLASS_registration_since_TYPO3_CMS_6.0 and Autoload

Removed Functionality

Removed doNotLoadInFE flag

With TYPO3 4.3 the flag doNotLoadInFE flag was introduced in ext_emconf.php
extension files to hint the core that an extension has no frontend
functionality. The performance gain of this change in the frontend was minimal.
The flag is now removed and the according extList_FE setting in localconf.php
has no effect anymore.

Removed system extension simulatestatic

The system extension to simulate static documents was removed from the core.
@TODO: Issue #36025 must be solved and this note here adapted, otherwise the
removal will be reverted.

Removed TypoScript option noBlur

The ancient noBlur TypoScript setting for old Browsers (Internet Explorer <= 5.5)
was removed without alternative. The setting has no effect anymore and can be
removed from custom TypoScript objects, especially MENU.

General

Extbase and fluid always loaded

The core extensions 'extbase' and 'fluid' are used in core classes like t3lib
and in several important core extensions. Extbase and fluid are now required
extensions and always loaded.

Backend / Backend UI

Extension developers please use the following template structure to conform with the doc heder structure. The previous html css structure with -row1 and -row2 is deprecated and will be removed.

The DocHeader html structure and layout has changed, the more general function menu is above in the first row and the action buttons below in the second row.

htmlArea Rich-Text-Editor

Security

TypoScript / Frontend

Development

Category

To address the need of categorization, an API has been introduced in TYPO3 CMS 6.0 enabling categorization of any kind of records. One of the main advantage is the ability to use the same category tree throughout the CMS. Technically, a table ``sys_category`` has been added to store category records next to table ``sys_category_record_mm`` for making the relations in a classical "mm" approach. Whenever a record type (e.g tt_content, pages, ...) has been configured as categorizable a new tab will be automatically displayed in the Backend enabling an Editor to select categories within the tree.

As a developer, to make sure a custom table can be categorized, one need to add a line in file ``ext_localconf.php`` or ``ext_tables.php`` of any extension (Needs TYPO3 > 6.1, as the https://review.typo3.org/#/c/12812/ didnt make it into 6.0)

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable(
$extensionKey,
$tableName,
// optional: in case the field would need a different name as "categories".
// The field is mandatory for TCEmain to work internally.
$fieldName = 'categories',
// optional: add TCA options which controls how the field is displayed. e.g position and name of the category tree.
$options = array()
);

Under the hood, the ``makeCategorizable`` method will add a new entry into the Category Registry. As a result, it will implicitly add a new field to the table and add the necessary TCA displaying a tree of categories.

Tip: whenever ``makeCategorizable`` is added, make sure to go to the Extension Manager and open the extension containing the instruction. The database needs to be updated by adding the field ``categories`` - if not configured differently - to the table.

As part of the Category API, a Collection API has been added which enables to programmatically query and update categorization of a record. Consider the snippet below:

Notice: the API has not been intensively tested. Expect some rough edges for TYPO3 6.0.

Adding categories to own models using Extension Builder

Create the model you want to be categorized using the Extension Builder.

Add a 1:n relation named "categories" to your model having the field "Relation to external class" been set to "\TYPO3\CMS\Extbase\Domain\Model\Category".

Modify ext_tables.php and add \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable() (see above) to make the field "categories" categorizable (In detail you don't have to explicitly create the field "categories" (in TCA and ext_tables.sql) as the method "makeCategorizable()" does this job).

Modify the TCA of your model and delete the configuration which was automatically created by Extension Builder for the field "categories", because Extension Builder creates 1:n relations as IRRE (we don't want this in the backend) which replaces the effect of makeCategorizable().

Now you are able to access the model's assigned category objects from within your model

Adding categories to own models without using Extension Builder

Making your model categorizable manually without modelling it using Extension Builder you have to take care about the following things:

You are free to add a property "categories" to your model (if you don't, makeCategorizable() will do this job including creating the TCA and neccesarry database field)

Make your models field you whish to hold the categories categorizable using makeCategorizable

Correctly define the "categories" property and its getters and setters in your model, as follows:

Performance

Cleanup

As the community always aims to clean up the old code base step by step many improvements have been introduced in version 6.0. As always deprecated code has been removed. In addition old references to extensions were removed and unused classes and files were deleted.