可將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 的環境，太低了很多安全特性根本就不支持。