您的经验:从 PHP 4 迁移到 PHP 5

14

我们需要将50多个应用程序(小型/大型)从PHP 4.1迁移到PHP 5.3。有人有这样的经验吗?

  • 所需时间
  • 工具
  • 最佳环境设置(服务器/测试?)

首先将其迁移到PHP 5.2是否有意义?是否有任何方法可以自动检测使用“PHP 4功能”的应用程序在PHP 5中无法正常工作?

我不知道如何处理这样的项目。谢谢!

6个回答

11
最重要的阅读内容应该是PHP 4迁移到PHP 5部分,自从PHP 5首次发布以来,他们一直在朝着更严格的语言方向发展(在版本6中,PHP将默认处于严格模式),因此您应该预计会看到很多警告或错误信息。
自PHP 5.0发布以来,还进行了更多破坏向后兼容性的更改,为了全面起见,您还应该阅读以下内容:
- PHP 5.0.x迁移到PHP 5.1.x - PHP 5.1.x迁移到PHP 5.2.x - PHP 5.2.x迁移到PHP 5.3.x 我知道这是很多阅读材料,但这应该是涵盖可能出现问题的所有内容的综合清单。

6

PHP_CompatInfo可以帮助检查依赖关系。 PHP_CodeSniffer可以帮助找到过时的语法。

然而,不同版本的PHP之间的差异经常被夸大。我从来没有遇到过依赖于边缘情况的代码问题。当然,除非这段代码仍然依赖于长超全局变量$HTTP_POST_VARS,那么可能会有一些其他的问题。

例如,替换magic_quotes依赖关系的有用习惯是:

$_POST = array_map("mysql_real_escape_string", $_POST);

实际上,大多数应用程序从未被重写以使用更现代的数据库API。


6
  1. PHP4和PHP5之间的类语法有所改变 - 例如,在PHP4中,构造方法与类名相同,而在PHP5中,构造函数的名称为__construct()

    PHP5仍然可以处理PHP4风格的类定义,因此您的代码可能仍然有效,但建议您将它们更改为新样式,因为否则您将无法使用许多功能。此外,当然,旧语法最终将被删除; 您的PHP4类将在未来出现问题,因此最好现在更改它们,而不是等到紧急情况。

  2. 全局变量。在PHP4中,您应该已经使用了$_REQUEST$_POST$_GET$_COOKIES,但许多旧代码仍然可能使用标准的PHP3自动全局变量。这是一个巨大的安全风险,因此,如果您仍在使用register_globals,则应立即开始修改代码,至少对于每个使用自动全局变量的地方都要使用$_REQUEST。实际上,这可能是一项非常困难的任务 - 当没有任何代码指示某种方式时,很难遍历大型应用程序以确定哪些变量旨在成为全局变量,哪些不是。从一个曾经必须这样做的人那里了解到,这可能是一个真正的噩梦。但这不是特定于转移到PHP5的问题 - 正如我所说的,即使您坚持使用PHP4,您确实需要处理此问题。 PHP5没有改变任何内容,除了将register_globals标志默认为关闭状态,这可能会给您更多的动力来实际完成这项工作。

  3. 如果您使用任何ereg_正则表达式函数,则已弃用这些函数。您应该将它们替换为等效的preg_函数。这不是一项大任务,实际上这些函数仍然可用,因此可以等待,只要您愿意忽略告诉您该函数已弃用的警告。但是,与类语法一样,现在考虑更改它们可能是明智的。

  4. 另一个已弃用旧语法的功能是按引用传递。在PHP4中,我们被鼓励在函数调用中使用&字符通过引用传递变量。在PHP5中,正确的方法是在函数声明中放置&字符而不是在调用它的地方。同样,旧语法仍然有效,但只有在您可以忍受PHP在各个地方抛出警告时才能使用。


这是__construct,而不是__constructor。值得一提的是,在PHP 4中,非常古老的superglobals($HTTP_POST_VARS等)已被弃用(使用$_POST等),我认为它们在PHP 5中甚至不存在了。 - Daniel Lo Nigro
@Daniel15 - __construct() 函数出了点问题,感谢你发现并指出,我已经编辑了答案。关于旧的超全局变量 - 它们仍然存在;虽然已被弃用,但目前仍在使用。但是它们不是超全局变量,因此它们的功能不如 $_POST 等。而且它们将来会被移除,所以现在使用它们不是一个好主意。 - Spudley

5
首先,您应该检查php.ini设置,特别是register_globals、magic_quotes_gpc等设置 - 它们可能会破坏您的应用程序逻辑。

3
如果您打开 error_reporting 并将其设置为 E_ALL,那么您应该能够看到弃用错误等。我不建议针对 PHP5.2 然后转向 5.3。
这取决于您只是想让应用程序工作还是想利用新的 PHP 功能和性能改进。如果它们只需要工作,则仅修复错误并忽略 E_DEPRECATEDE_NOTICE 警告。
如果项目一开始就以合理的方式编写,那么升级它们不应该太难。
这并不意味着这不会是一项极其无聊和艰苦的工作。特别是对于 50 个应用程序来说,它也将比您预期的时间长得多!

3

关闭display_errors,打开log_errors,将error_reporting设置为-1,并注意E_STRICTE_DEPRECATED警告。

这个迁移脚本(无耻的广告)可以帮助您处理一些已弃用的内容。它说是从5.2到5.3,但也可能适用于从4迁移。您还可以扩展它(欢迎提交补丁 :)),以处理您发现的经常遇到的问题。

PHPStorm IDE有相当不错的代码分析器,可以指出代码中的一些潜在问题。运行您的应用程序并查看它是否有有趣的提示。此外,它可能会帮助您快速找到由于使用新关键字作为函数名称等导致的错误。

对于您的最后一个问题:依我之见,您应该选择5.3,重复工作没有多大意义。


理想情况下,在生产环境中应该关闭 display_errors - Spudley
@Spudley 理论上是这样,但你会惊讶地发现我听过多少像“E_STRICT破坏了我的生产服务器”这样的抱怨。人们忽略这个建议就像明天没有了一样。 - StasM

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接