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