Updated migration4 - thank you Simion Onea.

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@239467 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Richard Quadling 2007-07-11 08:38:48 +00:00
parent 5223de0f67
commit 64b0d7edba

View file

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.40 $ -->
<!-- $Revision: 1.41 $ -->
<appendix xml:id="migration4" xmlns="http://docbook.org/ns/docbook">
<title>Migrating from PHP 3 to PHP 4</title>
@ -132,8 +132,8 @@ php_admin_flag [PHP directive name] [On|Off]
type lines! You have to convert these yourself.
</simpara>
<para>
To convert your Apache configuration files, run the apconf-conv.sh
script (available in the scripts/apache/ directory). For example:
To convert your Apache configuration files, run the <filename>apconf-conv.sh</filename>
script (available in the <filename>scripts/apache/</filename> directory). For example:
<informalexample>
<programlisting role="shell">
<![CDATA[
@ -159,10 +159,10 @@ php_admin_flag [PHP directive name] [On|Off]
</para>
<simpara>
Likewise, your old &htaccess; files will be saved with
an .orig prefix.
an .orig suffix.
</simpara>
<simpara>
The conversion scripts require awk to be installed.
The conversion scripts require 'awk' to be installed.
</simpara>
</section>
@ -187,7 +187,7 @@ php_admin_flag [PHP directive name] [On|Off]
a different file.
</para>
<para>
It still perfectly legal to include additional code within loops
It is still perfectly legal to include additional code within loops
or other control structures, only the controlling keywords and
corresponding curly braces <literal>{...}</literal> have to be
within the same compile unit (file or <function>eval</function>ed
@ -241,7 +241,7 @@ php_admin_flag [PHP directive name] [On|Off]
When upgrading code or servers from PHP 3 to PHP 4 you should
check these settings and calls to
<function>error_reporting</function> or you might disable
reporting the new error types, especially E_COMPILE_ERROR. This
reporting the new error types, especially <literal>E_COMPILE_ERROR</literal>. This
may lead to empty documents without any feedback of what happened
or where to look for the problem.
</para>
@ -257,7 +257,7 @@ php_admin_flag [PHP directive name] [On|Off]
<para>
This has lead to a lot of unreproducible bug reports in the
past where people reported script engine problems they were not
capable to track down while the &true; case was usually some
capable to track down while the true case was usually some
missing '}' in a required file that the parser was not able to
report due to a misconfigured error reporting system.
</para>
@ -278,8 +278,8 @@ php_admin_flag [PHP directive name] [On|Off]
the intended thing now, could easily be broken by changes in
other places. PHP 4 will output a lot of notice messages in
such situations where PHP 3 didn't. The easy fix is to just
turn off E_NOTICE messages, but it is usually a good idea to fix
the code instead.
turn off <literal>E_NOTICE</literal> messages, but it is usually
a good idea to fix the code instead.
</para>
<para>
The most common case that will now produce notice messages is the
@ -324,8 +324,8 @@ php_admin_flag [PHP directive name] [On|Off]
<section xml:id='migration4.empty'>
<title><literal>empty("0")</literal></title>
<para>
The perhaps most controversial change in behavior has happened to the
behavior of the <function>empty</function>. A String containing
Perhaps the most controversial change in behavior has happened to
<function>empty</function>. A String containing
only the character '0' (zero) is now considered empty while it
wasn't in PHP 3.
</para>
@ -361,7 +361,7 @@ php_admin_flag [PHP directive name] [On|Off]
possible to change the behavior of the parser (now embedded in
the Zend engine) at runtime as parsing already happened by
then. So the function <function>short_tags</function> no longer
exists. You can still change the parsers behavior by setting
exists. You can still change the parser's behavior by setting
appropriate values in the &php.ini; file.
</para>
<para>