GeezerVison is showing github.com — Passing E_USER_ERROR to trigger_error() is deprecated since 8.4 · Issue #2000 · textpattern/textpattern
Passing E_USER_ERROR to trigger_error() is deprecated since 8.4 #2000DescriptionI tried installing wet_quickopen 1.7 but forgot to first install wet_peex which is required for it to function.
In PHP 8.4, Textpattern then throws an error, but it is not specific to the plugin:
8192 "Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, throw an exception or call exit with a string message instead"
in /path/to/site/textpattern/lib/txplib_misc.php at line 1252.
This is indeed noted on php.net and wiki.php.net.
We have a whole load of such situations in the core: see this GitHub repo search.
Additional information
Textpattern version: 4.9-dev
Web server vendor and version: Laravel valet = nginx + php + mysql
PHP version: 8.4.10
Operating system: mac linux ActivityBloke commented on Jul 7, 2025 Ugh, good catch. That's a pain though, because it means we need to throw an exception and then catch it higher up in our error handler.
To be fair, we should probably be doing that anyway because our exception handling is a little.... shonky, for want of a better word.
But, exception handling for business logic and "for the sake of it" isn't really helpful. Debates rage on whether programmers should adopt the Result pattern or other such error methodologies. Bloke commented on Sep 17, 2025 @bloatware Any thoughts on how to deal with venders/autoload.php (and vendors/composer/platform_check.php)? They both have an E_USER_ERROR call from trigger_error() in it but it says the files are generated from Composer. Should we upgrade Composer somehow and regenerate the autoloader to fix that? Or can we manually alter the files? Composer is voodoo to me. bloatware commented on Sep 17, 2025 Those only concern php < 5.0.6, so no real issue for us. Leave it with Composer, maybe? Bloke commented on Sep 17, 2025
Those only concern php < 5.0.6, so no real issue for us. Leave it with Composer, maybe?
Sounds like a plan.
Presumably at some point, our Composer will be updated by dependabot. Or does one of us need to composer self-update and then commit? Hmm. Anybody any clues? bloatware commented on Sep 17, 2025 Hmm, no, actually it's php 5.6.0. What are our min 4.9 requirements, already?
Ah, got it : define('REQUIRED_PHP_VERSION', '5.6.0'). No clue how Composer gets updated, but we should be covered. jools-r commented on Dec 15, 2025 SponsorMemberAuthor More actions
Any thoughts on how to deal with venders/autoload.php (and vendors/composer/platform_check.php)? They both have an E_USER_ERROR call from trigger_error() in it but it says the files are generated from Composer. Should we upgrade Composer somehow and regenerate the autoloader to fix that? Or can we manually alter the files? Composer is voodoo to me.
I'm not sure how composer and npm are integrated into Textpattern's final build process. Probably @philwareham (?) knows more, but what I can say is from running composer update in the directory is that phpmailer is brought up to date (though Pete has done this already manually) and that composer automatically updates autoload.php, installed.json, installed.php and installedVersions.php in the process, correcting the potential problem with E_USER_ERROR – it's no longer present in the updated files.
It brings in a few too many files into PHPmailer as well as a rogue bin directory, so there is some housekeeping to do after running it.
Similarly, running npm copy:dompurify updates dompurify, which is also not currently up-to-date. It seems the dependabot updates just update package.json but don't actually run the update command. philwareham commented on Dec 15, 2025 I've just run Composer to bring in the latest autoloader and the latest v6.x version of PHPMailer - let us know if there are any issues.
FYI PHPMailer currently is available at v7.x but I presume we are sticking with the older version for 4.9? jools-r commented on Dec 15, 2025 SponsorMemberAuthor More actions Thanks @philwareham. Up to now, it seems we have trimmed the various readme and similar .md files in the phpmailer directory from the Textpattern source, but it's not a must. Composer will always want to repopulate them with the next update.
What do you think about the dompurify/ package.json question? Our repo is a couple of versions behind what dependabot added to package.json a short while ago. Bloke commented on Dec 15, 2025
it seems we have trimmed the various readme and similar .md files in the phpmailer directory from the Textpattern source,
I'd be keen to do this if we can automate it inside Composer somehow. We don't need all the fluff. I presume Composer has the capability to choose what gets synced? jools-r commented on Dec 16, 2025 SponsorMemberAuthor More actions
it seems we have trimmed the various readme and similar .md files in the phpmailer directory from the Textpattern source,
I'd be keen to do this if we can automate it inside Composer somehow. We don't need all the fluff. I presume Composer has the capability to choose what gets synced?
I've only passing knowledge of composer but my understanding is that the package providers determine what goes in a package. However this exclude-files composer plugin may allow us to do that (see also composer/composer#5029). philwareham commented on Dec 16, 2025 @jools-r @Bloke happy for you to remove any of the cruft from the recent commit that is not needed. We can look at Composer tweaks at a future time. jools-r commented on Dec 16, 2025 SponsorMemberAuthor More actions
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|