[FEATURE] Introduce xcache cache backend
[Packages/TYPO3.CMS.git] / NEWS.txt
1 This document is a part of the TYPO3 project. TYPO3 is an open source web
2 content management system released under the GNU GPL. TYPO3 is copyright
3 (c) 1999-2012 by Kasper Skaarhoj.
5 This document contains information about TYPO3 version 6.1 has been released
6 on April 30th 2013.
8 An up-to-date version of this document also containing links to further in
9 depth information can be found here:
11 http://wiki.typo3.org/TYPO3_6.1
13 ===============================================================================
14 Compatibility
15 ===============================================================================
17 -------------------------------------------------------------------------------
18 System environment
19 -------------------------------------------------------------------------------
21 * Switch from mysql to mysqli PHP database extension
23 The main database connection class (formerly known as TYPO3_DB) now uses
24 "mysqli" instead of the old "mysql" extension. mysqli was introduced with
25 PHP 5.0 and ships with all supported PHP versions by default. The original
26 extension "mysql" is deprecated with the upcoming PHP 5.5 version, is only
27 optimized for MySQL 4.1.3 or earlier, and lacks support for some newer
28 features of MySQL Server.
30 As TYPO3 CMS requires MySQL 5+ for some versions now, it is only natural to
31 exchange the mysql library as well. As the mysql calls are encapsulated
32 entirely in the main database connection class, there are only slight API
33 changes -- all extension code using the API should run as before.
35 "mysqli" is now a hard requirement in the PHP environment and must be loaded
36 for TYPO3 to run.
38 -------------------------------------------------------------------------------
39 Deprecated and removed components
40 -------------------------------------------------------------------------------
42 * Removed extension statictemplates
44 Static templates is an extension that delivers ready to use frontend templates
45 like the "Green" template. The extension is outdated for years and currently
46 unmaintained. It is removed from the core in the hope that it finds an
47 interested new maintainer who can develop it further. If it still was in use
48 for the given instance, an ugrade wizard is in place to fetch it from the
49 online extension repository.
50 Some frontend HMENU types are removed together with this extension as they use
51 javascript files included in statictemplates. Namely GMENU_LAYERS, TMENU_LAYERS
52 and GMENU_FOLDOUT are not delivered with the core anymore. If those TypoScript
53 HMENU types are still used, the extension statictemplates should be fetched
54 and installed from the TYPO3 extension repository as they are delivered
55 together with the extension.
57 ===============================================================================
58 Changes and Improvements
59 ===============================================================================
61 -------------------------------------------------------------------------------
62 General
63 -------------------------------------------------------------------------------
65 * Improved TCA load mechanism
67 The initialization of the central $GLOBAL['TCA'] array was refactored,
68 accelerated and simplified. Frontend code can now rely on a fully loaded array
69 including columns and the requirement to call loadTca() in ext_tables.php if
70 manipulating TCA is gone.
71 Extension authors should catch up with this evolvment: Definition of new TCA
72 tables should be moved to the extensions Configuration/TCA/ directory, every
73 table must be declared in an own file "tablename.php". The file must return the
74 full TCA definition of the specific table, with ctrl and columns sections
75 merged together, without the former dynamicConfigFile definition. The
76 declaration of TCA for new tables can be dropped from ext_tables.php, the
77 bootstrap will find and execute any new table definitions in Configuration/TCA
78 automatically if the extension author sticks to the convention. Examples of
79 correct registration can be found in sys_note and extensionmanager and other
80 system extensions.
82 -------------------------------------------------------------------------------
83 Backend
84 -------------------------------------------------------------------------------
86 -------------------------------------------------------------------------------
87 Administration / Customization
88 -------------------------------------------------------------------------------
90 -------------------------------------------------------------------------------
91 Extbase
92 -------------------------------------------------------------------------------
94 * Enabled rewritten property mapper as default mapper
96 Property mapping is the process to create method parameters or objects from
97 incoming form or ajax data. With TYPO3 CMS version 4.6 a new property mapper
98 was included as a backport from FLOW. It is much better configurable
99 and can for example handle complex mapping tasks like creating a DateTime
100 object from different given string formats. The FLOW documentation at
101 http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/ section
102 PropertyMapping can be used as basic feature reference.
103 This mapper is now enabled by default deprecating the old mapper one. extbase
104 extensions might have minor issues with the new default if not coded in a clean
105 way. While it is better to fix those issues, a quick fix is to swich back
106 to the old mapper with a TypoScript setting:
107 plugin.tx_extname.features.rewrittenPropertyMapper = 0
109 * Removed forced single table inheritance of frontend users and groups
111 Single table inheritance in extbase is used to stuff similar objects into a
112 table, but still create different objects from it, depending on the value of
113 column record_type of a specific row.
114 With versions prior to 6.1, this was done for fe_users and fe_groups table. As
115 a result, a frontend user object was only created from a row in persistence, if
116 the record type was set to TYPO3\CMS\Extbase\Domain\Model\FrontendUser.
117 Single table inheritance for fe_users and fe_groups was meant as a show case
118 of the functionality in early extbase days, but didn't fit the current use
119 cases anymore and was removed with 6.1.
120 This change might affect backwards compatibility for your extensions, if they
121 rely on single table inheritance of frontend users or groups. In seldom cases,
122 this could lead to more objects being constituted from persistence in your
123 repository calls than before. So keep a look at your frontend user object and
124 groups and verify there is now not a bigger number ob objects fetched from
125 persistence. To rebuild the previous behavior, revert the TypoScript change of
126 https://review.typo3.org/#/c/17879 in your extension.
128 -------------------------------------------------------------------------------
129 Fluid
130 -------------------------------------------------------------------------------
132 * Removed inline styling of f:form viewhelper hidden div
134 The f:form view helper renders several hidden input fields. Those are
135 encapsulated in a <div>. In versions prior to 6.1, this div had an inline style
136 attribute 'sytle="display: none"'. This was removed in 6.1 for accessibility
137 reasons. While this change won't have any effects on most systems, this is a
138 potentially breaking change if javascript DOM manipulation is done. The new
139 optional viewhelper parameter "hiddenFieldClassName" was introduced and can be
140 used to match this div.
142 * Allow Fluid arrays only in ViewHelper arguments
144 Fluid arrays are a subset of the JavaScript object syntax, making it hard to
145 work with them in mixed HTML/JavaScript documents. For example the following
146 JavaScript Object was parsed by Fluid:
147 var uris = {
148 endPoint1: '{f:uri.action(.)}',
149 endPoint2: '{f:uri.action(.)}',
150 };
151 With 6.1, Fluid now only parses arrays which are used inside ViewHelper
152 arguments, such that an array inside normal text is not converted anymore.
153 This change is only breaking in very rare cases where one relied on the inner
154 contents of the ViewHelper being an array, eg. if one used the debug
155 ViewHelper as follows:
156 <f:debug>{key1: 'value1', key2: 'value2'}</f:debug>
157 ViewHelpers which were written like this should be re-written to take the array
158 as ViewHelper argument:
159 <f:debug value="{key1: 'value1', key2: 'value2'}" />