Is the latest XenForo 227 patch 1 compatible with PHP 8.1.0?

FTL

Well-known member
PHP 8.1.0 was released yesterday. As far as I know, this is somewhat different to the 8.0.x versions, so is XenForo 227 patch 1 fully compatible with it? Should I hold off upgrading from PHP 8.0.13 which works fine?

 
Hold off:
XF 2.2.8 adds initial support for PHP 8.1.

I strongly suspect there will be some underlying things we have missed, but I'm currently running it in development with no obvious issues thus far.

We wouldn't recommend switching to PHP 8.1 in production but we do call on as many people as humanly possible to test this in staging/testing servers so we can cover off any lingering incompatibilities.
 
Thanks, I see that Chris wrote that yesterday, so I'll hold off for now. Likely wait for XF 228 at least.
 
Just came to ask about upgrading but you already did. Good to know.

It says it is about 23% faster than 8.0. Is that something that would be noticeable to users on the frontend?
 
  • Like
Reactions: FTL
Hold off:
Hold off for a LONG time, honestly.

Not only are we unable to guarantee there won’t be any compatibility issues, add-on code is likely going to be much more significant this time, initial PHP releases are often broken, and sometimes these things can take months to resolve.

At some point we’ll change our minimum requirements to say we’re “recommending” PHP 8.1. At that point you can be fairly sure we have a degree of confidence that issues reported to us as bugs and apparent add-on issues have died down. That’s a good indicator.

In the meantime it would be great if you could test PHP 8.1 in a test environment from version 2.2.8 ONLY.

XF 2.2.7 is very broken with PHP 8.1 as it stands.
 
In the meantime it would be great if you could test PHP 8.1 in a test environment from version 2.2.8 ONLY.
+1

PHP 8.1 also changed how it detects libargon2 https://www.php.net/manual/en/migra...migration81.other-changes.extensions.standard so some folks in order to get PHP 8.1 released decide to disable libargon2 support in their PHP 8.1 releases.

Chris, Xenforo added support for argon2 password hashing in PHP 7.2+ for Xenforo 2.1 https://xenforo.com/community/threa...-1-assorted-improvements.155901/#post-1294633

PHP:
$config['auth'] = [
   'algo' => PASSWORD_ARGON2I
];

Although we'd highly recommend using the latest PHP version we support, and also recommend using Argon2i/id hashing where available, you do have to plan carefully should you ever need to downgrade PHP or move to a different server. If Argon2 suddenly becomes unavailable for any reason, then you will likely encounter errors and be unable to verify any passwords without doing a password reset first.
so yeah if you went from PHP 7.2+ with argon2i/argon2id password hashing algorithm to PHP 8.1 with argon2 disabled

But seems latest Xenforo 2 config docs has no mention of this config option???

Centmin Mod PHP 8.1.0 with libargon2 ready :)
Code:
php -v
PHP 8.1.0 (cli) (built: Nov 26 2021 11:33:44) PGO (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.0, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
Code:
php -r 'print_r(get_defined_constants());' | grep -i argon
    [PASSWORD_ARGON2I] => argon2i
    [PASSWORD_ARGON2ID] => argon2id
    [PASSWORD_ARGON2_DEFAULT_MEMORY_COST] => 65536
    [PASSWORD_ARGON2_DEFAULT_TIME_COST] => 4
    [PASSWORD_ARGON2_DEFAULT_THREADS] => 1
    [PASSWORD_ARGON2_PROVIDER] => standard
    [SODIUM_CRYPTO_PWHASH_ALG_ARGON2I13] => 1
    [SODIUM_CRYPTO_PWHASH_ALG_ARGON2ID13] => 2
    [SODIUM_CRYPTO_PWHASH_STRPREFIX] => $argon2id$
 
Thanks for the advice Chris. I'll duly break my dev install with it when 228 is out and give you some feedback and hold off on the production system. 🙂
 
How does your server error log look? Or how do things look if you're running in debug mode? :)
 
No errors so far but didn't test a lot.

Will do in the near future though and will let you know.
As you're on Centmin Mod LEMP stack, check the PHP error logs for clues too at /var/log/php-fpm/www-php.error.log. I updated my test server to PHP 8.1.0 and with some Wordpress sites on there, I see a lot of PHP Deprecated errors for Wordpress at least in /var/log/php-fpm/www-php.error.log

You can use a command line below to check last 100 lines of the PHP error log and print out a unique list of errors from the 4th field onwards (removing date/timestamp from 1st to 3rd fields)
Bash:
tail -100 /var/log/php-fpm/www-php.error.log | awk '{print substr($0, index($0, $4))}' | sort -u
 
Thanks @eva2000

So far, only one error:
Code:
PHP Deprecated:  Return type of XF\App::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /bla/bla/domain.com/public/src/XF/App.php on line 2398
 
So far, only one error:
Might have just caught PHP-FPM error logs being rotated out with a fresh PHP-FPM error log so only has 1 error.

If so you can try the below extended inspection commands to take into account www-php.error.log logrotation which rotates out the logs and empties out the www-php.error.log and saves previous with date timestamp and may use gzip or zstd compression.

For gzip compression based logrotation, you can view all PHP errors with date and timestamp. Remember this will include all errors even previous fixed instead of just current log at /var/log/php-fpm/www-php.error.log. If you have more than 1 CPU thread on server, Centmin Mod will also setup multi-threaded zcat for faster processing - so replace zcat command with pzcat.
Bash:
zcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -exec ls -1rt "{}" +;)
For gzip compression based logroation, you can view all unique PHP errors without date and timestamp. Remember this will include all errors even previous fixed instead of just current log at /var/log/php-fpm/www-php.error.log. If you have more than 1 CPU thread on server, Centmin Mod will also setup multi-threaded zcat for faster processing - so replace zcat command with pzcat.
Bash:
zcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -exec ls -1rt "{}" +;) | awk '{print substr($0, index($0, $4))}' | sort -u
You can also narrow down to last 168hrs of logs with find option = -newermt "-168 hours" - just be aware the command will hang if you have no logs newer than 168hrs or whatever hours you set as awk and sort won't have anything to process. So just hit CTRL+C to abort.
Bash:
zcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -newermt "-168 hours" -exec ls -1rt "{}" +;) | awk '{print substr($0, index($0, $4))}' | sort -u

For zstd compression based logrotation, you can view all PHP errors with date and timestamp. Remember this will include all errors even previous fixed instead of just current log at /var/log/php-fpm/www-php.error.log
Bash:
zstdcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -exec ls -1rt "{}" +;)
For zstd compression based logroation, you can view all unique PHP errors without date and timestamp. Remember this will include all errors even previous fixed instead of just current log at /var/log/php-fpm/www-php.error.log
Bash:
zstdcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -exec ls -1rt "{}" +;) | awk '{print substr($0, index($0, $4))}'| sort -u
You can also narrow down to last 168hrs of logs with find option = -newermt "-168 hours" - just be aware the command will hang if you have no logs newer than 168hrs or whatever hours you set as awk and sort won't have anything to process. So just hit CTRL+C to abort.
Bash:
zstdcat -f $(find /var/log/php-fpm/ -type f -name "www-php.error.log*" -newermt "-168 hours" -exec ls -1rt "{}" +;) | awk '{print substr($0, index($0, $4))}'| sort -u
 
Last edited:
Top Bottom