XenForo white-paged on PHP 8.1

Z

zeeb0t

New member
Hello,

As of approx 2 hours ago, WHM/cPanel rolled out an update and I found XenForo will no longer run (it sends a complete white page, with zero error output - even with errors turned on) on any version of PHP 8.

I switched to version 7.4 using MultiPHP and now XenForo works again. However should I switch back to 8 - it fails again.

I checked every single error log available and there is nothing.

I would like to get back to using 8.1, is there anyone else who experienced this issue?

Thanks
 
Even as of right now, if I switch to any version of PHP8 since this latest update, it fails. I have to sit on PHP7.4 now.
 
p.s., I don't think it is a PHP compilation issue. Something as simple as a hello world script, or PHP info, loads up just fine on PHP8.*
 
vixzr said:
Doesn't appear to be anything specific to PHP 8.1 in the 102 Change log (that's not to say it is not the cause, of course):

102 Change Log | cPanel & WHM Documentation

This document lists the cases and bugs worked on during the version 102 release cycle.
docs.cpanel.net docs.cpanel.net
Click to expand...

Yeah I checked it over and didn't find anything relevant. Yet with 102, PHP8 and XenForo is no bueno for me. It had been working a very long time without any changes whatsoever until this update. Yet I find other simple scripts work, and since XenForo is saying nothing in logs or anywhere else I can find, it is a mystery for me.
 
I had the same problem this morning. Try turning zlib.output_compression off with your PHP 8.x versions. In cPanel, go into the MultiPHP Ini Editor then from the dropdown list select your version of PHP 8.x that you're using. At the bottom of the list of options turn off the "zlib.output_compression" option.

If you're running into the same issue we did, then in Chrome users are seeing a blank page while FireFox for desktop is showing a Content Encoding Error. Turn off zlib.output_compression with PHP 8.x and the sites load fine. Viewing the page Headers in Chrome shows that the page is still being gzip encoded.

I don't have an explanation for how/why, just what I was able to eventually track it down to.
 
Kevin said:
I had the same problem this morning. Try turning zlib.output_compression off with your PHP 8.x versions. In cPanel, go into the MultiPHP Ini Editor then from the dropdown list select your version of PHP 8.x that you're using. At the bottom of the list of options turn off the "zlib.output_compression" option.

If you're running into the same issue we did, then in Chrome users are seeing a blank page while FireFox for desktop is showing a Content Encoding Error. Turn off zlib.output_compression with PHP 8.x and the sites load fine. Viewing the page Headers in Chrome shows that the page is still being gzip encoded.

I don't have an explanation for how/why, just what I was able to eventually track it down to.
Click to expand...

Ah! That sounds exactly like the scenario. I will test this later tonight once traffic cools down to confirm. But I can already confirm basic PHP scripts on v8 works - likewise zlib compression, XenForo, and PHP7.4 are all working together.

So it makes me think zlib for PHP8 is different now or XenForo is somehow now incompatible with it, assuming what you've done works for me too.

I will report back this evening with the findings.
 
On the plus side, it was relieving to see that XF gracefully handled going back to PHP 7.4.x temporarily.

For anybody out there following, I was running PHP 8.0.x with zlib.output_compression turned on for quite some time now. I've done no server updates recently nor XF patches. Up till about 10:00AM Eastern this morning everything was working fine before the XF sites started giving me a blank page in Chrome and FF users saw the Content Encoding Error. Simple non-XF PHP scripts still worked but none of the XF sites would. I tried the usual of disabling listeners and stripping XF down to it's very basic stock options in config.php but still had no luck. Using MultiPHP to switch the sites back to PHP 7.4.x, which still has zlib.output_compression enabled, had the sites responding again as normal. Thankfully somebody gave me a heads-up that FF was displaying an error instead of a blank page like Chrome was. Going by the Content Encoding Error as a start that led me to looking into the PHP 8.x settings which eventually got me to the point of trying to disable zlib.output_compression from the MultiPHP INI Editor and bam!, XF with PHP 8.x was able to load again (fortunately I had a test install on the server to play with). Using Chrome's Dev' Tools shows that the page content-encoding is still being served with gzip.
 
Kevin said:
On the plus side, it was relieving to see that XF gracefully handled going back to PHP 7.4.x temporarily.

For anybody out there following, I was running PHP 8.0.x with zlib.output_compression turned on for quite some time now. I've done no server updates recently nor XF patches. Up till about 10:00AM Eastern this morning everything was working fine before the XF sites started giving me a blank page in Chrome and FF users saw the Content Encoding Error. Simple non-XF PHP scripts still worked but none of the XF sites would. I tried the usual of disabling listeners and stripping XF down to it's very basic stock options in config.php but still had no luck. Using MultiPHP to switch the sites back to PHP 7.4.x, which still has zlib.output_compression enabled, had the sites responding again as normal. Thankfully somebody gave me a heads-up that FF was displaying an error instead of a blank page like Chrome was. Going by the Content Encoding Error as a start that led me to looking into the PHP 8.x settings which eventually got me to the point of trying to disable zlib.output_compression from the MultiPHP INI Editor and bam!, XF with PHP 8.x was able to load again (fortunately I had a test install on the server to play with). Using Chrome's Dev' Tools shows that the page content-encoding is still being served with gzip.
Click to expand...

Exactly what I experienced. I noticed the mod moved this thread to server config forum rather than bug. I am not so sure this is a server config issue just yet. As yet I have seen no update to the package although I need to go and inspect further, I guess.
 
I moved it because it's not a generic XF/PHP 8.1 bug, as others are running that version of PHP without issue.

As is this site (although I appreciate the XF version here is newer).
 
Brogan said:
I moved it because it's not a generic XF/PHP 8.1 bug, as others are running that version of PHP without issue.

As is this site.
Click to expand...

Can I ask, are you running this site with zlib also enabled as an extension?

Perhaps a new update for zlib is on the way to ruin many php8 XenForo sites.
 
Brogan said:
zlib.output_compression is off here.
View attachment 266394
Click to expand...

Thanks.. Happy to report that switching zlib compression off did now resolve the issue so that XenForo works with 8.1.

It would appear to me as though XenForo and zlib on PHP8 are now no longer compatible. Perhaps something I could suggest is, a future version of XenForo recommends turning it off (apologies if it had and I missed that?)
 
Kevin said:
On the plus side, it was relieving to see that XF gracefully handled going back to PHP 7.4.x temporarily.

For anybody out there following, I was running PHP 8.0.x with zlib.output_compression turned on for quite some time now. I've done no server updates recently nor XF patches. Up till about 10:00AM Eastern this morning everything was working fine before the XF sites started giving me a blank page in Chrome and FF users saw the Content Encoding Error. Simple non-XF PHP scripts still worked but none of the XF sites would. I tried the usual of disabling listeners and stripping XF down to it's very basic stock options in config.php but still had no luck. Using MultiPHP to switch the sites back to PHP 7.4.x, which still has zlib.output_compression enabled, had the sites responding again as normal. Thankfully somebody gave me a heads-up that FF was displaying an error instead of a blank page like Chrome was. Going by the Content Encoding Error as a start that led me to looking into the PHP 8.x settings which eventually got me to the point of trying to disable zlib.output_compression from the MultiPHP INI Editor and bam!, XF with PHP 8.x was able to load again (fortunately I had a test install on the server to play with). Using Chrome's Dev' Tools shows that the page content-encoding is still being served with gzip.
Click to expand...

Thanks again for your finding. I'm now back on php8.1 :)
 
Feel free to report that particular module as a bug if you wish and the developers will respond as to whether there are any changes they wish to make, or whether it would be a suggestion.
 
You must log in or register to reply here.

Similar threads

Sumanta0018
  • Solved
XF 2.3 XF 2.3 not working on PHP 8.3 - Blank White Screen
Replies
3
Views
114
arnold
A
DarkGizmo
Xenforo loads slower on PHP 8.3 after PHP upgrade?
Replies
4
Views
139
HappyWorld
H
bzcomputers
  • Question Question
XF 2.2 Imagick still not installable on PHP 8.3, does XenForo recommend a fully compatible alternative(s)?
Replies
2
Views
246
Kirby
K
B
  • Locked
XF 2.2 php 8.1 [E_WARNING] Undefined property: SV\StandardLib\XF\Template\Templater::$options
Replies
1
Views
612
duderuud
duderuud
M
Fixed PHP 8.0 and 8.1 [E_WARNING] Trying to access array offset on value of type bool
Replies
8
Views
2K
masmo
M
Back
Top Bottom