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