Partial fix PHP 8.2: Collection of issues

PaulB

Well-known member
Affected version
2.2.11
This is a collection of patches for PHP 8.2 compatibility issues I've encountered. It's not intended to be used on a live site and just serves as a checklist of known issues.

Currently, this includes:
  1. HTML-ENTITIES encoding is deprecated:
    1. \Symfony\Component\VarDumper\Dumper\HtmlDumper::dumpLine
    2. \Symfony\Component\DomCrawler\Crawler::addHtmlContent
  2. utf8_decode and utf8_encode are deprecated:
    1. src/vendor/dokuwiki/utf8/utf8.php: utf8_decode replaced with mb_convert_encoding to preserve existing, buggy behavior (see note below for caveats)
  3. Missing properties:
    1. \XF\AddOn\DataType\AbstractDataType: $structure
    2. \XF\Http\Stream: $stream
    3. Various GuzzleHttp stream implementations: $stream
    4. \XF\Payment\CallbackState: unknown number of properties; added #[\AllowDynamicProperties]
    5. \GuzzleHttp\Handler\CurlMultiHandler: unknown number of properties; added #[\AllowDynamicProperties]
    6. \Less_Tree: $parensInOp, $allExtends
  4. Typos in property names that only started triggering errors in PHP 8.2; previous versions of PHP supported dynamic properties:
    1. \XF\BbCode\ProcessorAction\AnalyzeUsage::initialize: $smiliesCount vs $smilieCount
    2. \XFMG\Ffmpeg\Runner::setFileName: $filename vs $fileName
  5. Deprecated callable syntax:
    1. SwiftMailer: lots of occurrences
    2. \Symfony\Component\Console\Helper\QuestionHelper::formatChoiceQuestionChoices
Omitted:
  1. Any issues that exist outside XF, XFES, XFMG, XFRM, XFI, and their included libraries. Notably, XFAws is incompatible with PHP 8.2 as of writing.
  2. The fixes for utf8_encode and utf8_decode aren't ideal. Many usages of utf8_* make incorrect assumptions about languages and encoding. For example, although this patch allows wholeWordTrimAroundLength to run without erroring, it doesn't fix wholeWordTrimAroundLength's buggy behavior with certain languages. Most bugs stemming from utf8_* usage will be minor and don't require urgent fixes, but if you're an add-on developer, it's worth reassessing how you handle string comparisons and length calculations on UTF-8 text.
 

Attachments

Last edited:
Thanks for this.

We've applied the non-vendor parts of the patch and the changes to utf8.php.

For the others, what we'd probably like to do is fork the vendor packages, where appropriate, and apply those fixes directly to that fork which we then still pull in via composer.

We do this in the belief that it should make incorporating other upstream changes (if any) down the line, including cases where we may move to newer versions where PHP version constraints allow, should be easier.

We've not been consistent with this, and it does make seeking out those newer versions more of a manual task but we've done this a lot, particularly with PHP 8.1 compat, ironically. This is part of our internal composer.json file which overrides the repos used in the require section:

JSON:
"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/less.php"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/flysystem-eventable-filesystem"
    },
    {
        "type": "path",
        "url": "src/vendor/xenforo-ltd/polyfill-noop"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/braintree_php"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/jwt-key-mgmt"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/jwt-core"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/web-push-php"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/PHPASN1"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/guzzle"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/laminas-feed"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/laminas-loader"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/laminas-mail"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/laminas-stdlib"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/laminas-validator"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/stripe-php"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/console"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/debug"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/dom-crawler"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/process"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/var-dumper"
    },
    {
        "type": "vcs",
        "url": "https://github.com/xenforo-ltd/emoji-toolkit"
    }
]

This will get closed off when the core changes are pushed but I'll open a new report for further investigation with a new copy of the patch.
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.12).

Change log:
Include PHP 8.2 compatibility fixes in non-vendor classes and utf8.php
There may be a delay before changes are rolled out to the XenForo Community.
 
I tried to install php 8.2 on my server with latest XF version, with no results. Broke the forum. Had to revert back to php 8.1.13.

This is with Apache 2.4.54 and MySQL 8.0.31.
 
@gerryvz, XenForo 2.2.12 isn't compatible with PHP 8.2 yet, which is why this is marked as "partial fix." XenForo's first-party code has been updated for compatibility, but many of the third-party libraries used by XenForo are only compatible with PHP >= 7.0, <= 8.1.

A subset of my patch that applies to XenForo 2.2.12's libraries is included here, but it's just intended as a reference, and you shouldn't use it unless you're willing to manually debug and fix issues that may arise.
 
Last edited:
@gerryvz, XenForo 2.2.12 isn't compatible with PHP 8.2 yet, which is why this is marked as "partial fix." XenForo's first-party code has been updated for compatibility, but many of the third-party libraries used by XenForo are only compatible with PHP >= 7.0, <= 8.1.

A subset of my patch that applies to XenForo 2.2.12's libraries is included here, but it's just intended as a reference, and you shouldn't use it unless you're willing to manually debug and fix issues that may arise.
Thanks. Happy to wait until things are plug and play compatible. I had just noticed that the php repositories had released php 8.2 for ubuntu recently, and downloaded it via apt.
 
I just tried using PHP8.2 on my test forum XF2.2.15 and it broke the forum. Just a blank window. I saw in an earlier post that someone was using 8.2.* without issues so I contacted my host and they are stumped.
 
I just tried using PHP8.2 on my test forum XF2.2.15 and it broke the forum. Just a blank window. I saw in an earlier post that someone was using 8.2.* without issues so I contacted my host and they are stumped.
I ran into the same issue. What I did is use the "reset to defaults" in the php extensions if you're using Cpanel. Fixed it for me.
 
I just tried using PHP8.2 on my test forum XF2.2.15 and it broke the forum. Just a blank window. I saw in an earlier post that someone was using 8.2.* without issues so I contacted my host and they are stumped.
I've been using 8.2 on several forums, one updated to the last version, and two others running 2.2.13
Been using it for months with no issues. If you run into issues it's because some extension isn't activated on 8.2 where it would be on 8.1 or lower.
 
Thanks...
I don't understand what they did but they fixed it. Here's what they did
Hello,
For PHP 8.2 you currently have error logging enabled so within the execution path there is an error_log file which tells you why the page is blank:
Code:
[01-Feb-2024 16:39:26 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function mysqli_report() in /home/internt0/public_html/xftest/src/XF.php:114
Stack trace:
#0 /home/internt0/public_html/xftest/src/XF.php(75): XF::standardizeEnvironment()
#1 /home/internt0/public_html/xftest/index.php(12): XF::start('/home/internt0/...')
#2 {main}
  thrown in /home/internt0/public_html/xftest/src/XF.php on line 114
I've determined it's specifically a problem with ea-php82 which does not allow you control over extensions like the alt-php* extensions do ( https://my.hawkhost.com/knowledgeba...hange-your-PHP-version-modify-extensions.html ). I've switched that domain to using alt-php82 and I've opened a bug report on our end to determine why MySQL does not load when using ea-php even though we recommend against it since you use extension control.
 
The bug affecting ea-php82 has now also been fixed but as mentioned alt-php* give you a lot more control over extensions/configurations and we always recommend it. cPanel however distributes it's own versions which in order to maintain better compatibility with the whole cPanel ecosystem we also offer the ea-php* versions.
 
Top Bottom