Zend Framework 1.9
Lors de la migration d'un version précédente vers Zend Framework 1.9 ou plus récent
vous devriez prendre note de ce qui suit.
Zend_File_Transfer
MimeType validation
For security reasons we had to turn off the default fallback mechanism of the
MimeType, ExcludeMimeType,
IsCompressed and IsImage validators.
This means, that if the fileInfo or
magicMime extensions can not be found, the validation will
always fail.
If you are in need of validation by using the HTTP fields which
are provided by the user then you can turn on this feature by using the
enableHeaderCheck() method.
Security hint
You should note that relying on the HTTP fields, which are
provided by your user, is a security risk. They can easily be changed and could
allow your user to provide a malcious file.
Allow the usage of the HTTP fields
true);
// or afterwards
$valid->enableHeaderCheck();
]]>
Zend_Filter
Avant la version 1.9, Zend_Filter permettait l'utilisation
de la méthode statique get(). Avec la version 1.9 cette
méthode a été renommée en filterStatic() afin d'être plus
descriptive. L'ancienne méthode get() est marquée comme
dépréciée.
Zend_Http_Client
Changement dans le stockage interne des fichiers d'upload
Dans la version 1.9 de Zend Framework, il y a eu un changement dans la manière dont
Zend_Http_Client stocke en interne les informations concernant les
fichiers ayant été uploadés, affectés grâce à Zend_Http_Client::setFileUpload()
Ce changement a été mis en place de manière à permettre l'envoi de plusieurs fichiers
avec le même nom dans le formulaire, en tant que tableau de fichiers. Plus d'informations à
ce sujet peuvent être trouvées dans ce
rapport de bug.
Stockage interne des informations sur les fichiers uploadés
setFileUpload('file1.txt', 'userfile[]', 'some raw data', 'text/plain');
$client->setFileUpload('file2.txt', 'userfile[]', 'some other data', 'application/octet-stream');
// Dans Zend Framework <=1.8, la valeur de l'attribut protégé $client->files est:
// $client->files = array(
// 'userfile[]' => array('file2.txt', 'application/octet-stream', 'some other data')
// );
// Dans Zend Framework >=1.9, la valeur de $client->files est:
// $client->files = array(
// array(
// 'formname' => 'userfile[]',
// 'filename' => 'file1.txt,
// 'ctype' => 'text/plain',
// 'data' => 'some raw data'
// ),
// array(
// 'formname' => 'userfile[]',
// 'filename' => 'file2.txt',
// 'formname' => 'application/octet-stream',
// 'formname' => 'some other data'
// )
// );
]]>
Comme vous le voyez, ce changement permet l'utilisation du même élément de formulaire avec plusieurs
fichiers. Cependant ceci introduit un changement subtile dans l'API interne, il est donc signalé ici.
Deprecation of Zend_Http_Client::_getParametersRecursive()
Starting from version 1.9, the protected method _getParametersRecursive()
is no longer used by Zend_Http_Client and is deprecated.
Using it will cause an E_NOTICE message to be emitted by PHP.
If you subclass Zend_Http_Client and call this method, you
should look into using the Zend_Http_Client::_flattenParametersArray()
static method instead.
Again, since this _getParametersRecursive is a protected method,
this change will only affect users who subclass Zend_Http_Client.
Zend_Locale
Méthodes dépréciées
Quelques méthodes de traductions spéciales ont été dépréciées car elles dupliquaient
un comportement existant. Notez cependant que les anciens appels vont toujours
fonctionner, mais une notice utilisateur, qui décrira le nouvel appel, sera émise.
Ces méthodes seront effacées en 2.0. Ci-dessous la liste des anciens et nouveaux
appels :
Liste des types de mesures
Ancien appel
Nouvel appel
getLanguageTranslationList($locale)
getTranslationList('language', $locale)
getScriptTranslationList($locale)
getTranslationList('script', $locale)
getCountryTranslationList($locale)
getTranslationList('territory', $locale, 2)
getTerritoryTranslationList($locale)
getTranslationList('territory', $locale, 1)
getLanguageTranslation($value, $locale)
getTranslation($value, 'language', $locale)
getScriptTranslation($value, $locale)
getTranslation($value, 'script', $locale)
getCountryTranslation($value, $locale)
getTranslation($value, 'country', $locale)
getTerritoryTranslation($value, $locale)
getTranslation($value, 'territory', $locale)
Zend_View_Helper_Navigation
Prior to the 1.9 release, the menu helper
(Zend_View_Helper_Navigation_Menu) did not
render sub menus correctly. When the onlyActiveBranch
was TRUE and the option renderParents
FALSE, nothing would be rendered if the deepest active
page was at a depth lower than the minDepth option.
In simpler words; if minDepth was set to 1
and the active page was at one of the first level pages, nothing
would be rendered, as the following example shows.
Consider the following container setup:
'Home',
'uri' => '#'
),
array(
'label' => 'Products',
'uri' => '#',
'active' => true,
'pages' => array(
array(
'label' => 'Server',
'uri' => '#'
),
array(
'label' => 'Studio',
'uri' => '#'
)
)
),
array(
'label' => 'Solutions',
'uri' => '#'
)
));
]]>
The following code is used in a view script:
navigation()->menu()->renderMenu($container, array(
'minDepth' => 1,
'onlyActiveBranch' => true,
'renderParents' => false
));
]]>
Before release 1.9, the code snippet above would output nothing.
Since release 1.9, the _renderDeepestMenu() method in
Zend_View_Helper_Navigation_Menu will accept
active pages at one level below minDepth, as long as
the page has children.
The same code snippet will now output the following:
Server
Studio
]]>