+
+ Zend Framework 1.10+ When upgrading from a previous release to Zend Framework 1.10 or higher you + should note the following migration notes. + + +Zend_Controller_Front+ A wrong behaviour was fixed, when there was no module route and no route + matched the given request. Previously, the router returned an unmodified + request object, so the front controller just displayed the default controller + and action. Since Zend Framework 1.10, the router will correctly as noted + in the router interface, throw an exception if no route matches. The error + plugin will then catch that exception and forward to the error controller. + You can then test for that specific error with the constant + Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE: + + +
Zend_Feed_Reader+ With the introduction of Zend Framework 1.10, Zend_Feed_Reader's + handling of retrieving Authors and Contributors was changed, introducing + a break in backwards compatibility. This change was an effort to harmonise + the treatment of such data across the RSS and Atom classes of the component + and enable the return of Author and Contributor data in more accessible, + usable and detailed form. It also rectifies an error in that it was assumed + any author element referred to a name. In RSS this is incorrect as an + author element is actually only required to provide an email address. + In addition, the original implementation applied its RSS limits to Atom + feeds significantly reducing the usefulness of the parser with that format. + + ++ The change means that methods like getAuthors() + and getContributors no longer return a simple array + of strings parsed from the relevant RSS and Atom elements. Instead, the return + value is an ArrayObject subclass called + Zend_Feed_Reader_Collection_Author which simulates + an iterable multidimensional array of Authors. Each member of this object + will be a simple array with three potential keys (as the source data permits). + These include: name, email and uri. + + ++ The original behaviour of such methods would have returned a simple + array of strings, each string attempting to present a single name, but + in reality this was unreliable since there is no rule governing the format + of RSS Author strings. + + ++ The simplest method of simulating the original behaviour of these + methods is to use the Zend_Feed_Reader_Collection_Author's + getValues() which also returns a simple array of strings + representing the "most relevant data", for authors presumed to be their name. + Each value in the resulting array is derived from the "name" value + attached to each Author (if present). In most cases this simple change is + easy to apply as demonstrated below. + + +
Zend_File_TransferSecurity change+ For security reasons Zend_File_Transfer does no longer store + the original mimetype and filesize which is given from the requesting client into + its internal storage. Instead the real values will be detected at initiation. + + ++ Additionally the original values within $_FILES will be + overridden within the real values at initiation. This makes also + $_FILES secure. + + ++ When you are in need of the original values you can either store them before + initiating Zend_File_Transfer or use the + disableInfos option at initiation. Note that this option is + useless when its given after initiation. + +Count validation+ Before release 1.10 the MimeType validator used a wrong + naming. For consistency the following constants have been changed: + + +
+ When you are translating these messages within your code then use the new constants. + As benefit you don't need to translate the original string anymore to get a correct + spelling. + +Zend_Filter_HtmlEntities+ In order to default to a more secure character encoding, + Zend_Filter_HtmlEntities now defaults to UTF-8 + instead of ISO-8859-1. + + ++ Additionally, because the actual mechanism is dealing with character encodings and not + character sets, two new methods have been added, setEncoding() + and getEncoding(). The previous methods + setCharSet() and setCharSet() are now + deprecated and proxy to the new methods. Finally, instead of using the protected members + directly within the filter() method, these members are + retrieved by their explicit accessors. If you were extending the filter in the past, + please check your code and unit tests to ensure everything still continues to work. + +Zend_Filter_StripTags+ Zend_Filter_StripTags contains a flag, + commentsAllowed, that, in previous versions, allowed you to + optionally whitelist HTML comments in HTML text + filtered by the class. However, this opens code enabling the flag to + XSS attacks, particularly in Internet Explorer (which allows + specifying conditional functionality via HTML comments). Starting + in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the + commentsAllowed flag no longer has any meaning, and all + HTML comments, including those containing other + HTML tags or nested commments, will be stripped from the final output + of the filter. + +Zend_TranslateXliff adapter+ In past the Xliff adapter used the source string as message Id. According to the + Xliff standard the trans-unit Id should be used. This behaviour was corrected with + Zend Framework 1.10. Now the trans-unit Id is used as message Id per default. + + ++ But you can still get the incorrect and old behaviour by setting the + useId option to FALSE. + + +
Zend_ValidateSelf written validators+ When setting returning a error from within a self written validator you have to + call the _error() method. Before Zend Framework 1.10 you + were able to call this method without giving a parameter. It used then the first + found message template. + + ++ This behaviour is problematic when you have validators with more than one different + message to be returned. Also when you extend an existing validator you can get + unexpected results. This could lead to the problem that your user get not the + message you expected. + + +
+ To prevent this problem the _error() method is no longer + allowed to be called without giving a parameter. + + +
Simplification in date validator+ Before Zend Framework 1.10 2 identical messages were thrown within the date + validator. These were NOT_YYYY_MM_DD and + FALSEFORMAT. As of Zend Framework 1.10 only the + FALSEFORMAT message will be returned when the given date + does not match the set format. + +Fixes in Alpha, Alnum and Barcode validator+ Before Zend Framework 1.10 the messages within the 2 barcode adapters, the Alpha + and the Alnum validator were identical. This introduced problems when using custom + messages, translations or multiple instances of these validators. + + ++ As with Zend Framework 1.10 the values of the constants were changed to + be unique. When you used the constants as proposed in the manual there is + no change for you. But when you used the content of the constants in your code + then you will have to change them. The following table shows you the changed values: + + +
+ +
|
+
+
|
+