可将3.5的PHP版本的最低要PHP7.0作为硬条件:

jiangchuankyo

PHP版本小于7.0时有一个无法被修复的硬BUG, 就是所有需要处理数字的函数无法识别那个大于21亿的数,


intval大于2147483648会返回负数,  time()函数会返回1910年,  filesize大于2G也会返回负数 等等....

总之所有需要处理数字的函数, 都无法处理大于2147483648的数字(只有纯+-法可以),

网上的教程都说要系统64位, 其实是全是错的,

必须: 系统64位, PHP64位, PHP版本大于大于7.0

这三者缺一不可, 才可以处理大于2147483648的数字

测试系统: windows server 2022  x64


可将dz3.5的PHP版本的最低要PHP7.0作为硬条件在安装时检测

1 贡献

最佳答案

补充一句，X3.5 的 PHP 要求 2020 年多方拉锯模式谈过很多次，PHP 5.6 是各方面平衡的最终决定。
这个最低限制不影响站点使用和应用开发，各方面可以选择适合自己的版本。站点使用可以直接装 PHP 7 甚至 8 ，应用开发可以选择不兼容 PHP 5.6 。

PHP 5.6 是最终决定主要原因是 PHP 5.6 能支持很多基础安全特性且最大程度的保留了对历史组件、用户环境的支持，太高了存量应用适配不了（每次 Discuz! 适配 PHP 大版本都是大工程）而且用户也很可能没有 PHP 7 的环境，太低了很多安全特性根本就不支持。

• 老周部落
• 发表于2023-1-13 15:55:13
• 详细答案 >

jiangchuankyo

还有所有htm模板里面的数组字符串键应该全部加上单引号,

2. Discuz拦截了PHP的错误处理函数, 拦截可以,  但是应该给php返回false, 这样别人php自带的错误日志才会有记录在,
现在是discuz拦截错误处理函数, 但是discuz自己不会记录错误(那种访问请求当中含有非法字符，已经被系统拒绝的安全错误才会记录,语法错误代码错误discuz默认不会记录只会显示给浏览器)


3. 不应该去动别人php的error_reporting设置, 这个error_reporting设置修改了别人php的错误处理级别全就失效了,
   如果只是不想让错误显示给访问者的浏览器上,  只需要设置display_errors = Off即可

专家

32位软件的int就是这样的啊，这怎么能是bug呢？多少年来一直都是这样的，而且Discuz本身也没有处理大数的实质性需求的。
这就不是bug，你选择了32位系统，就不能处理这么大的数。数据库里安排的一般也都是int而不是bigint之类的东西。
有一些特殊场景是必须要处理大数的（如ipv6相关）但是程序里已经做了兼容层，可以确保在32位系统上正常运行。

php 8数组不加单引号是会直接报错的，但是你发现模板里面对应没加引号的地方报错了么？这是因为模板解析引擎里已经做了兼容层了。

关于错误处理这块原来是有优化计划的，但这块还真不能轻易的改，因为有很多奇奇怪怪的php环境的存在，很多东西不能像理论上那样去做，做了容易出问题，最怕的是安全问题。
后续应该会有一些相关的处理的，但大概率默认也没法启用。
外加Discuz现有版本根本不是按正常运行无错的方式设计的，虽然之前已经花了很大气力改掉了为数不少的日常报错，但残留的量依然非常可观。你敢把这部分内容直接开进日志，你正常运行1天你的日志就得灌满。

老周部落

补充一句，X3.5 的 PHP 要求 2020 年多方拉锯模式谈过很多次，PHP 5.6 是各方面平衡的最终决定。
这个最低限制不影响站点使用和应用开发，各方面可以选择适合自己的版本。站点使用可以直接装 PHP 7 甚至 8 ，应用开发可以选择不兼容 PHP 5.6 。

PHP 5.6 是最终决定主要原因是 PHP 5.6 能支持很多基础安全特性且最大程度的保留了对历史组件、用户环境的支持，太高了存量应用适配不了（每次 Discuz! 适配 PHP 大版本都是大工程）而且用户也很可能没有 PHP 7 的环境，太低了很多安全特性根本就不支持。