#58778 closed defect (bug) (invalid)
global _SERVER accessed in load.php without a global statement
Reported by: | xswarren | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 6.2.2 |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
wp-includes/load.php function wp_fix_server_vars() reads and writes global variable $_SERVER but does not contain statement "global $_SERVER;". This seems wrong since PHP requires global variables to be explicitly declared as such IIUC.
This morning, my web server error log started to contain the error line shown below, and the HTML sent by the server started using http:// URLs instead of https:// URLs for some assets (Elementor CSS & JS files), which prevented my site from working:
[10-Jul-2023 17:12:38 UTC] PHP Warning: array_merge(): Expected parameter 2 to be an array, null given in /home/customer/www/fortcollinscreatorhub.org/public_html/wp-includes/load.php on line 40
Editing that function to add "global $_SERVER;" solved both the URLs and the error messages... That said, this code has been this way for ages, so I have no idea why I suddenty needed to edit that file when allegedly my hosting provider has not changes anything according to their help ticket...
Change History (4)
#2
@
17 months ago
- Resolution set to invalid
- Status changed from new to closed
Hello @xswarren, and welcome to Trac.
Thank you for opening this ticket.
This would be a bug for any other global variable, but the (array) variable $_SERVER
in PHP belongs to a family of "superglobals" https://www.php.net/manual/en/language.variables.superglobals.php that is available and initialized in all scopes, without being declared global
.
So I close this as "invalid", our ugly term for things that cannot cause any action from the team.
#3
@
17 months ago
Ah, thanks for the docs pointer; that makes sense.
Let me know if this extended discussion should be moved somewhere else since it's no longer a bug in the code.
Below is the change made to php.ini, which caused the issue. I'm curious why the change caused the issue. As far as I can tell, the change simply altered the representation of some boolean values, but didn't change the logical value of those variables. Can you comment on this? Maybe this is due the PHP JIT thing our hosting provider (SiteGround) seems to have enabled; maybe it has some bug in php.ini handling?
Thanks for any hints.
root@severn:/mnt/severn_backup/severn.wwwdotorg.org/sequence# diff -B -u bkp.[21]/home/swarren/backup_fcch_webhost/data/www/fortcollinscreatorhub.org/public_html/php.ini root@severn:/mnt/severn_backup/severn.wwwdotorg.org/sequence# diff -B -u bkp.[10]/home/swarren/backup_fcch_webhost/data/www/staging5.fortcollinscreatorhub.org/public_html/php.ini --- bkp.0/home/swarren/backup_fcch_webhost/data/www/staging5.fortcollinscreatorhub.org/public_html/php.ini 2023-07-10 15:18:29.538858974 -0600 +++ bkp.1/home/swarren/backup_fcch_webhost/data/www/staging5.fortcollinscreatorhub.org/public_html/php.ini 2021-08-18 06:00:37.873260027 -0600 @@ -1158,17 +1397,21 @@ ; where MODE is the octal representation of the mode. Note that this ; does not overwrite the process's umask. ; http://php.net/session.save-path + ; Whether to use cookies. ; http://php.net/session.use-cookies -session.use_cookies = On +session.use_cookies = 1 + ; http://php.net/session.cookie-secure ;session.cookie_secure = + ; This option forces PHP to fetch and use a cookie for storing and maintaining ; the session id. We encourage this operation as it's very helpful in combating ; session hijacking when not specifying and managing your own session id. It is ; not the end all be all of session hijacking defense, but it's a good start. ; http://php.net/session.use-only-cookies -session.use_only_cookies = On +session.use_only_cookies = 1 + ; Name of the session (used as cookie name). ; http://php.net/session.name session.name = PHPSESSID @@ -1172,9 +1415,11 @@ ; Name of the session (used as cookie name). ; http://php.net/session.name session.name = PHPSESSID + ; Initialize session on request startup. ; http://php.net/session.auto-start -session.auto_start = Off +session.auto_start = 0 + ; Lifetime in seconds of cookie or, if 0, until browser is restarted. ; http://php.net/session.cookie-lifetime session.cookie_lifetime = 0 @@ -1281,7 +1542,8 @@ ; - User may access your site with the same session ID ; always using URL stored in browser's history or bookmarks. ; http://php.net/session.use-trans-sid -session.use_trans_sid = Off +session.use_trans_sid = 0 + ; Select a hash function for use in generating session ids. ; Possible Values ; 0 (MD5 128 bits)
Note: I found that our hosting provider had edited php.ini which triggered the original problem. Restoring the old php.ini solved the problem.
However, I still believe that WordPress should explicitly execute "global $_SERVER", shouldn't it? Hence, I believe this bug is still valid.