Users brought to our attention the fact that Zend_Controller_Action_Helper_ViewRenderer were using a method of the dispatcher abstract class that was not in the dispatcher interface. We have now added the following method to ensure that custom dispatchers will continue to work with the shipped implementations:

As noted by users, the validators from Zend_File_Transfer do not work in conjunction with Zend_Config due to the fact that they have not used named arrays.

Therefor, all filters and validators for Zend_File_Transfer have been reworked. While the old signatures continue to work, they have been marked as deprecated, and will emit a PHP notice asking you to fix them.

The following list shows you the changes you will have to do for proper usage of the parameters.

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter('Rename',
                   array('/path/to/oldfile', '/path/to/newfile', true));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter('Rename',
                   array('source' => '/path/to/oldfile',
                         'target' => '/path/to/newfile',
                         'overwrite' => true));

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Count',
                      array(2, 3));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Count',
                      false,
                      array('min' => 2,
                            'max' => 3));

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Extension',
                      array('jpg,gif,bmp', true));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Extension',
                      false,
                      array('extension1' => 'jpg,gif,bmp',
                            'case' => true));

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('FilesSize',
                   array(100, 10000, true));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('FilesSize',
                      false,
                      array('min' => 100,
                            'max' => 10000,
                            'bytestring' => true));

// Example for 1.6
$upload->useByteString(true); // set flag

// Same example for 1.7
$upload->setUseByteSting(true); // set flag

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Hash',
                   array('12345', 'md5'));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Hash',
                      false,
                      array('hash1' => '12345',
                            'algorithm' => 'md5'));

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('ImageSize',
                      array(10, 10, 100, 100));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('ImageSize',
                      false,
                      array('minwidth' => 10,
                            'minheight' => 10,
                            'maxwidth' => 100,
                            'maxheight' => 100));

// Example for 1.6
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Size',
                      array(100, 10000, true));

// Same example for 1.7
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addValidator('Size',
                      false,
                      array('min' => 100,
                            'max' => 10000,
                            'bytestring' => true));

According to the coding standards isLocale() had to be changed to return a boolean. In previous releases a string was returned on success. For release 1.7 a compatibility mode has been added which allows to use the old behaviour of a returned string, but it triggers a user warning to mention you to change to the new behaviour. The rerouting which the old behaviour of isLocale() could have done is no longer neccessary as all I18n will now process a rerouting themself.

To migrate your scripts to the new API, simply use the method as shown below.

// Example for 1.6
if ($locale = Zend_Locale::isLocale($locale)) {
    // do something
}

// Same example for 1.7

// You should change the compatiblity mode to prevent user warnings
// But you can do this in your bootstrap
Zend_Locale::$compatibilityMode = false;

if (Zend_Locale::isLocale($locale)) {
}

// Example for 1.6
if ($locale = Zend_Locale::isLocale($locale, false)) {
    // do something
}

// Same example for 1.7

// You should change the compatiblity mode to prevent user warnings
// But you can do this in your bootstrap
Zend_Locale::$compatibilityMode = false;

if (Zend_Locale::isLocale($locale, false)) {
    if (Zend_Locale::isLocale($locale, true)) {
        // no locale at all
    }

    // original string is no locale but can be rerouted
}

The meaning of the getDefault() method has been change due to the fact that we integrated a framework locale which can be set with setDefault(). It does no longer return the locale chain but only the set framework locale.

To migrate your scripts to the new API, simply use the method as shown below.

// Example for 1.6
$locales = $locale->getDefault(Zend_Locale::BROWSER);

// Same example for 1.7

// You should change the compatiblity mode to prevent user warnings
// But you can do this in your bootstrap
Zend_Locale::$compatibilityMode = false;

$locale = Zend_Locale::getOrder(Zend_Locale::BROWSER);

When using automatic detection of languages, or setting languages manually to Zend_Translate you may have mentioned that from time to time a notice is thrown about not added or empty translations. In some previous release also an exception was raised in some cases.

The reason is, that when a user requests a non existing language, you have no simple way to detect what's going wrong. So we added those notices which show up in your log and tell you that the user requested a language which you do not support. Note that the code, even when we trigger such an notice, keeps working without problems.

But when you use a own error or exception handler, like xdebug, you will get all notices returned, even if this was not your intention. This is due to the fact that these handlers override all settings from within PHP.

To get rid of these notices you can simply set the new option 'disableNotices' to TRUE. It defaults to FALSE.

$language = new Zend_Translate('gettext',
                               '/path/to/translations',
                               'auto');

$language = new Zend_Translate('gettext',
                               '/path/to/translations',
                               'auto',
                               array('disableNotices' => true));

Since a number of developers reported that they were using such notation within their applications that was not the result of user input, a special flag was created to allow disabling the default protection. You have two methods for doing so: by passing the 'lfiProtectionOn' key to the constructor options, or by explicitly calling the setLfiProtection() method.

// Disabling via constructor
$view = new Zend_View(array('lfiProtectionOn' => false));

// Disabling via exlicit method call:
$view = new Zend_View();
$view->setLfiProtection(false);