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:

/**
 * 1.10 より前
 */
    public function errorAction()
    {
        $errors = $this->_getParam('error_handler');

        switch ($errors->type) {
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
    // ...

/**
 * 1.10 では
 */
    public function errorAction()
    {
        $errors = $this->_getParam('error_handler');

        switch ($errors->type) {
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
    // ...

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.

/**
 * 1.10 より前
 */
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors();

/**
 * 1.10 では
 */
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors()->getValues();

よりセキュアな文字エンコードを既定値にするために、 Zend_Filter_HtmlEntities は、 ISO-8859-1 の代わりに UTF-8 を既定値にしました。

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