This document is a part of the TYPO3 project. TYPO3 is an open source web
content management system released under the GNU GPL. TYPO3 is copyright
(c) 1999-2012 by Kasper Skaarhoj.

This document contains information about TYPO3 version 6.0 has been released
on November 27th 2012.

An up-to-date version of this document also containing links to further in
depth information can be found here:

http://wiki.typo3.org/TYPO3_6.0

===============================================================================
Compatibility
===============================================================================

-------------------------------------------------------------------------------
System environment
-------------------------------------------------------------------------------

* PHP setting register_globals must be off

The bootstrap now verifies the PHP setting register_globals is disabled for
security reasons. The script dies otherwise.

-------------------------------------------------------------------------------
PHP namespaces & TYPO3 autoloader
-------------------------------------------------------------------------------

* Introducing PHP namespaces

Almost every PHP class file has been modified to support PHP namespaces and
was moved to a more meaningful location. Besides that old class names, e.g.
t3lib_div still can be used - however it is deprecated - this works by using a
class alias map pointing to the new namespaces class name.

	see the files in typo3/sysext/core/Migrations/Code/ for the mentioned maps

Basically the classes are now arranged in three basic components, which are
core, backend and frontend - each of them are located in typo3/sysext/. The
old class files (e.g. t3lib/class.t3lib_div.php) are still shipped with the
Core and point to the new class files - this prevents PHP fatal errors if
extension use hardcoded require_once() calls to old class names. This layer
is deprecated as well.

	see http://wiki.typo3.org/Namespaces for further details

* New XCLASS handling

The old way of registering XCLASSes in $TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS'] is
removed. XCLASSES must now be registered by adding a class implementation
configuration to the $TYPO3_CONF_VARS['SYS']['Objects'] array. The key of the
array is the class name for which you want to define an implementation class.

Example:
$TYPO3_CONF_VARS['SYS']['Objects']['TYPO3\\CMS\\Core\\Database\\DatabaseConnection'] =
	array('className' => 'TYPO3\\CMS\\Dbal\\Database\\DatabaseConnection');

As with Xclasses, the implementation resolving works recursively and you are free
to put the implementation class name into the namespace of your own extension.

This means that every XCLASS registration both for core and extension classes
will not work any more with TYPO3 6.0.
To keep compatibility for 6.0 and 4.x, extension authors should add their class
to both the XCLASS array and the object implementation array.

-------------------------------------------------------------------------------
PHP bootstrap and configuration
-------------------------------------------------------------------------------

* Refactored bootstrap

The bootstrap changes all basic initializations for frontend, backend, CLI and
install tool rendering. If a copied and customized version of the frontend's
index.php was used, it has to be updated to the current index.php file of the
TYPO3 Core sources (this applies to custom symbolic links as well).

* New handling of typo3conf/localconf.php

The localconf.php file is deprecated and not used in the core any longer. As
substitution the new file typo3conf/LocalConfiguration.php is introduced that
basically only returns the local configuration as array. The install tool and
other installation changing core code like the extension manager now writes
the whole file if configuration is changed. As a result, no more local
code is allowed in this file.
To overload the local configuration with special instance specific code that
might still be needed, it is possible to add the php code to the optional
additional file typo3conf/AdditionalConfiguration.php that is executed during
bootstrap of TYPO3 after LocalConfiguration.php.
An ugrade wizard takes care of migrating contents of the previous localconf.php
file to the new scheme.

* List of loaded extensions stored as array

The list of loaded extensions in typo3conf/LocalConfiguration (key EXT/extList)
was transferred to an array for better readability and maintenance. It is
available with the new key EXT/extListArray. The old, comma separated value is
still kept, but not used in the core anymore. It will be removed with a later
version from the core.

* Moved default TYPO3_CONF_VARS

The default TYPO3_CONF_VARS definitions where moved from t3lib/config_default.php
to an own file in t3lib/stddb/DefaultSettings.php.

* Removed TYPO3_tables_script constant

It was possible to define a different base TCA definition file by defining the
variable typo_db_tables_script in localconf.php. This functionality is removed
without substitution.

* Restricted access of global variables in ext_tables.php and ext_localconf.php

With the bootstrap refactoring the visibility of ext_tables.php and
ext_localconf.php was reduced. The files do not run in global context anymore,
so variables like $TCA should be accessed through $GLOBALS['TCA']. There is a
compatibility layer, but the core can not guarantee that extensions with
strange setup does not break.

-------------------------------------------------------------------------------
Deprecated and removed components
-------------------------------------------------------------------------------

* 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.

* 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 up to
version 5.5) was removed without any alternatives. The setting has no effect
anymore and can be removed from custom TypoScript objects, especially MENU.

* Removed internal history cleanup feature

TYPO3 will not clean the history (table "sys_history") on its own anymore.
This can lead to a large amount of data in this table. Please consider using
the garbage collection scheduler task to remove old entries.

* Removed TypoScript resources

The ancient feature to add images and other resources directly to TypoScript
records is dropped and the handling removed. This old feature - accessible
from the 'Info/modify' tab in the Template module - was hardly ever used
and was partly broken.
If this feature was still in use, it is recommended to not drop the
resource field from table sys_template during upgrading, fix the using
TypoScript to refer to resources located in fileadmin or similar directly,
and afterwards to finally delete the resource field in the install tool.

* Removed page hit logging functionality

Writing log entries to some logfile during frontend page hit was removed.
There are tons of solutions on the net and on server basis that can do a
better job than the core implementation ever did. Therefor the complete
code was dropped and all TypoScript config.stat* options are obsolete.

* Removed compression of javascript files with jsmin

The default compression of certain javascript files in frontend and backend
with the jsmin library was removed from the core due to license issues. The
code segment was substituted with a hook, so extensions can now deliver
compression solutions if needed. In general, it is a good idea to configure
a webserver to compress javascript and css files on the webserver with gzip.


===============================================================================
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.

-------------------------------------------------------------------------------
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.

-------------------------------------------------------------------------------
PHP namespaces & TYPO3 autoloader
-------------------------------------------------------------------------------

* PHP namespaces in the TYPO3 autoloader

The autoloader can now handle fully qualified namespaced class names.
If you use the fully qualified namespaced class name like
'\Tx\ExtName\Foo\Bar', the autoloader will find the containing class following
the extbase naming scheme. The mentioned class will be found if it is located
in file 'exttensionkey'/Classes/Foo/Bar.php.
It is also possible to use class names not following the extbase naming scheme
by providing the "name spaced class name -> file" mapping in ext_autoloader.php.

-------------------------------------------------------------------------------
Backend
-------------------------------------------------------------------------------

* New backend user administration module

The backend user administration module was created from scratch again. The
interface changed a lot, it is now possible to filter large groups of users
with certain criteria and to compare specific user information. The code was
made more flexible to easily cope with different use cases and to be more
open for future enhancements.

* New extension manager

The extension manager was rewritten to be based on Extbase and thus to have a
discrete controller and action API. The view utilized jQuery in the client's
user interface and has been reduced to only contain required functionality
for (un-)installing or configuring extensions. Uploading extensions to TER
and directly modifying files of extensions is not supported in the Core
anymore, but will be available as separate extension tools package in the TER.

* Introducing global categorization

A new global categorization has been introduced, thus any core component and
extension can utilize this in the backend. An API call can be used to set
accordant TCA and to create required SQL definition changes during runtime.

See the following example to create a new field categories in a table:

	\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable(
		'myextension',
		'tx_myextension_table',
		'categories'
	);

* Support for NULL values in backend forms

In some situations it might become handy to have an "undefined" value, e.g.
for timestamp fields where "0" has the meaning of the unix timestamp origin
back in 1970. Therefore a new TCA "eval" subtype has been introduced to support
that - which will be visualized in the backend with a new "enable field"
checkbox. Besides that the SQL definition must not have the "NOT NULL"
statement for that field.

Example to add the "undefined" (NULL value) to the field "myfield":

	$TCA['tx_myextension_table']['columns']['myfield']['config'] = array(
		'type' => 'input',
		'eval' => 'null',
	);

-------------------------------------------------------------------------------
Administration / Customization
-------------------------------------------------------------------------------

* Introducing the File Abstraction Layer

The File Abstraction Layer ("FAL") is used to create accordant database records
for each file. This was the same file can be used (referenced) in multiple
elements without having to clone and clutter the file-system anymore. The TYPO3
Core already makes use of the new File Abstraction Layer, but elderly extensions
still can use the old way. Besides that, the Install Tool provides several
upgrade wizards to migrate files to the new structure.

	see http://docs.typo3.org/typo3cms/FileAbstractionLayerReference/

