<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="migration.19">
    <title>Zend Framework 1.9</title>

    <para>
        When upgrading from a release of Zend Framework earlier than 1.9.0 to any 1.9 release, you
        should note the following migration notes.
    </para>

    <sect2 id="migration.19.zend.file.transfer">
        <title>Zend_File_Transfer</title>

        <sect3 id="migration.19.zend.file.transfer.mimetype">
            <title>MimeType validation</title>

            <para>
                For security reasons we had to turn off the default fallback mechanism of the
                <classname>MimeType</classname>, <classname>ExcludeMimeType</classname>,
                <classname>IsCompressed</classname> and <classname>IsImage</classname> validators.
                This means, that if the <emphasis>fileInfo</emphasis> or
                <emphasis>magicMime</emphasis> extensions can not be found, the validation will
                always fail.
            </para>

            <para>
                If you are in need of validation by using the <acronym>HTTP</acronym> fields which
                are provided by the user then you can turn on this feature by using the
                <methodname>enableHeaderCheck()</methodname> method.
            </para>

            <note>
                <title>Security hint</title>

                <para>
                    You should note that relying on the <acronym>HTTP</acronym> 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.
                </para>
            </note>

            <example id="migration.19.zend.file.transfer.example">
                <title>Allow the usage of the HTTP fields</title>

                <programlisting language="php"><![CDATA[
// at initiation
$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);

// or afterwards
$valid->enableHeaderCheck();
]]></programlisting>
            </example>
        </sect3>
    </sect2>

    <sect2 id="migration.19.zend.filter">
        <title>Zend_Filter</title>

        <para>
            Prior to the 1.9 release, <classname>Zend_Filter</classname> allowed
            the usage of the static <methodname>get()</methodname> method. As with
            release 1.9 this method has been renamed to
            <methodname>filterStatic()</methodname> to be more descriptive. The
            old <methodname>get()</methodname> method is marked as deprecated.
        </para>
    </sect2>

    <sect2 id="migration.19.zend.http.client">
        <title>Zend_Http_Client</title>

        <sect3 id="migration.19.zend.http.client.fileuploadsarray">
            <title>Changes to internal uploaded file information storage</title>

            <para>
                In version 1.9 of Zend Framework, there has been a change in the way
                <classname>Zend_Http_Client</classname> internally stores information about
                files to be uploaded, set using the
                <methodname>Zend_Http_Client::setFileUpload()</methodname> method.
            </para>

            <para>
                This change was introduced in order to allow multiple files to be uploaded
                with the same form name, as an array of files. More information about this issue
                can be found in <ulink
                    url="http://framework.zend.com/issues/browse/ZF-5744">this bug report</ulink>.
            </para>

            <example id="migration.19.zend.http.client.fileuploadsarray.example">
                <title>Internal storage of uploaded file information</title>

                <programlisting language="php"><![CDATA[
// Upload two files with the same form element name, as an array
$client = new Zend_Http_Client();
$client->setFileUpload('file1.txt',
                       'userfile[]',
                       'some raw data',
                       'text/plain');
$client->setFileUpload('file2.txt',
                       'userfile[]',
                       'some other data',
                       'application/octet-stream');

// In Zend Framework 1.8 or older, the value of
// the protected member $client->files is:
// $client->files = array(
//     'userfile[]' => array('file2.txt',
                             'application/octet-stream',
                             'some other data')
// );

// In Zend Framework 1.9 or newer, the value of $client->files is:
// $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'
//     )
// );
]]></programlisting>
            </example>

            <para>
                As you can see, this change permits the usage of the same form element name with
                more than one file - however, it introduces a subtle backwards-compatibility change
                and as such should be noted.
            </para>
        </sect3>

        <sect3 id="migration.19.zend.http.client.getparamsrecursize">
            <title>Deprecation of Zend_Http_Client::_getParametersRecursive()</title>

            <para>
                Starting from version 1.9, the protected method
                <methodname>_getParametersRecursive()</methodname> is no longer used by
                <classname>Zend_Http_Client</classname> and is deprecated. Using it will cause an
                <constant>E_NOTICE</constant> message to be emitted by <acronym>PHP</acronym>.
            </para>

            <para>
                If you subclass <classname>Zend_Http_Client</classname> and call this method, you
                should look into using the
                <methodname>Zend_Http_Client::_flattenParametersArray()</methodname> static method
                instead.
            </para>

            <para>
                Again, since this <methodname>_getParametersRecursive()</methodname> is a protected
                method, this change will only affect users who subclass
                <classname>Zend_Http_Client</classname>.
            </para>
        </sect3>
    </sect2>

    <sect2 id="migration.19.zend.locale">
        <title>Zend_Locale</title>

        <sect3 id="migration.19.zend.locale.deprecated">
            <title>Deprecated methods</title>

            <para>
                Some specialized translation methods have been deprecated because they duplicate
                existing behaviour. Note that the old methods will still work, but a user notice is
                triggered which describes the new call. The methods will be erased with 2.0.
                See the following list for old and new method call.
            </para>

            <table id="migration.19.zend.locale.deprecated.table-1">
                <title>List of measurement types</title>

                <tgroup cols="2">
                    <thead>
                        <row>
                            <entry>Old call</entry>
                            <entry>New call</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry>
                                <methodname>getLanguageTranslationList($locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslationList('language', $locale)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getScriptTranslationList($locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslationList('script', $locale)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getCountryTranslationList($locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslationList('territory', $locale, 2)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getTerritoryTranslationList($locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslationList('territory', $locale, 1)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getLanguageTranslation($value, $locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslation($value, 'language', $locale)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getScriptTranslation($value, $locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslation($value, 'script', $locale)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getCountryTranslation($value, $locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslation($value, 'country', $locale)</methodname>
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <methodname>getTerritoryTranslation($value, $locale)</methodname>
                            </entry>

                            <entry>
                                <methodname>getTranslation($value, 'territory',
                                    $locale)</methodname>
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>
        </sect3>
    </sect2>

    <sect2 id="migration.19.zend.view.helper.navigation">
        <title>Zend_View_Helper_Navigation</title>

        <para>
            Prior to the 1.9 release, the menu helper
            (<classname>Zend_View_Helper_Navigation_Menu</classname>) did not
            render sub menus correctly. When <property>onlyActiveBranch</property>
            was <constant>TRUE</constant> and the option <property>renderParents</property>
            <constant>FALSE</constant>, nothing would be rendered if the deepest active
            page was at a depth lower than the <property>minDepth</property> option.
        </para>

        <para>
            In simpler words; if <property>minDepth</property> 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.
        </para>

        <para>
            Consider the following container setup:
        </para>

        <programlisting language="php"><![CDATA[
<?php
$container = new Zend_Navigation(array(
    array(
        'label' => 'Home',
        'uri'   => '#'
    ),
    array(
        'label'  => 'Products',
        'uri'    => '#',
        'active' => true,
        'pages'  => array(
            array(
                'label' => 'Server',
                'uri'   => '#'
            ),
            array(
                'label' => 'Studio',
                'uri'   => '#'
            )
        )
    ),
    array(
        'label' => 'Solutions',
        'uri'   => '#'
    )
));
]]></programlisting>

        <para>
            The following code is used in a view script:
        </para>

        <programlisting language="php"><![CDATA[
<?php echo $this->navigation()->menu()->renderMenu($container, array(
    'minDepth'         => 1,
    'onlyActiveBranch' => true,
    'renderParents'    => false
)); ?>
]]></programlisting>

        <para>
            Before release 1.9, the code snippet above would output nothing.
        </para>

        <para>
            Since release 1.9, the <methodname>_renderDeepestMenu()</methodname> method in
            <classname>Zend_View_Helper_Navigation_Menu</classname> will accept
            active pages at one level below <property>minDepth</property>, as long as
            the page has children.
        </para>

        <para>
            The same code snippet will now output the following:
        </para>

        <programlisting language="html"><![CDATA[
<ul class="navigation">
    <li>
        <a href="#">Server</a>
    </li>
    <li>
        <a href="#">Studio</a>
    </li>
</ul>
]]></programlisting>
    </sect2>

    <sect2 id="migration.19.security">
        <title>Security fixes as with 1.9.7</title>

        <para>
            Additionally, users of the 1.9 series may be affected by other changes starting in
            version 1.9.7. These are all security fixes that also have potential backwards
            compatibility implications.
        </para>

        <sect3 id="migration.19.security.zend.dojo.editor">
            <title>Zend_Dojo_View_Helper_Editor</title>

            <para>
                A slight change was made in the 1.9 series to modify the default usage of the Editor
                dijit to use <acronym>div</acronym> tags instead of a <acronym>textarea</acronym>
                tag; the latter usage has <ulink
                    url="http://api.dojotoolkit.org/jsdoc/HEAD/dijit._editor.RichText">security
                implications</ulink>, and usage of <acronym>div</acronym> tags is recommended by the
                Dojo project.
            </para>

            <para>
                In order to still allow graceful degradation, a new <varname>degrade</varname>
                option was added to the view helper; this would allow developers to optionally use a
                <acronym>textarea</acronym> instead. However, this opens applications developed with
                that usage to <acronym>XSS</acronym> vectors. In 1.9.7, we have removed this option.
                Graceful degradation is still supported, however, via a <acronym>noscript</acronym>
                tag that embeds a <acronym>textarea</acronym>. This solution addressess all security
                concerns.
            </para>

            <para>
                The takeaway is that if you were using the <varname>degrade</varname> flag, it will
                simply be ignored at this time.
            </para>
        </sect3>

        <sect3 id="migration.19.security.zend.filter.html-entities">
            <title>Zend_Filter_HtmlEntities</title>

            <para>
                In order to default to a more secure character encoding,
                <classname>Zend_Filter_HtmlEntities</classname> now defaults to
                <acronym>UTF-8</acronym> instead of <acronym>ISO-8859-1</acronym>.
            </para>

            <para>
                Additionally, because the actual mechanism is dealing with character encodings and
                not character sets, two new methods have been added,
                <methodname>setEncoding()</methodname> and <methodname>getEncoding()</methodname>.
                The previous methods <methodname>setCharSet()</methodname> and
                <methodname>setCharSet()</methodname> are now deprecated and proxy to the new
                methods. Finally, instead of using the protected members directly within the
                <methodname>filter()</methodname> 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.
            </para>
        </sect3>

        <sect3 id="migration.19.security.zend.filter.strip-tags">
            <title>Zend_Filter_StripTags</title>

            <para>
                <classname>Zend_Filter_StripTags</classname> contains a flag,
                <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
                optionally whitelist <acronym>HTML</acronym> comments in <acronym>HTML</acronym>
                text filtered by the class. However, this opens code enabling the flag to
                <acronym>XSS</acronym> attacks, particularly in Internet Explorer (which allows
                specifying conditional functionality via <acronym>HTML</acronym> comments). Starting
                in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
                <varname>commentsAllowed</varname> flag no longer has any meaning, and all
                <acronym>HTML</acronym> comments, including those containing other
                <acronym>HTML</acronym> tags or nested commments, will be stripped from the final
                output of the filter.
            </para>
        </sect3>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->