XF 2.3 PHP 8.5 Deprecated: Constant E_STRICT is deprecated in /web/public_html/src/XF/Template/Templater.php

Wildcat Media

Well-known member
Licensed customer
This was fixed as a bug for 2.3.4 (which I have), but this error is making my Apache error log grow way too large, too fast. I'm running PHP8.5-fpm. I obviously can't turn off error reporting but on the other hand, I don't need this same message appearing multiple times per minute in my Apache error log files either.

What can I do to stop all the "noise?"
 
I think I got it. The logs seem to have quieted down now.

In /etc/php/8.5/fpm/php.ini I edited this line to read:

Code:
error_reporting = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED

Adding ~E_USER_DEPRECATED seemed to do the trick. I just hope it's not masking errors I should be seeing.
 
~E_DEPRECATED should work.

I have a similar issue on my 2.4 forums with the older IPB > XF redirect script for old links. Adding ~E_WARNING & E_DEPRECIATED to the /php.ini file does not stop the server log from reporting a warning. I'm running Virtualmin and the domain also has a setting in Web Configuration > PHP-FPM Configuration > Error Logging that should write out the command to php.ini, but even making sure both are the same command doesn't seem to work.
 
I'm working direct from the CLI, and editing the correct php.ini file has no effect on this, even with both ~E_DEPRECATED and ~E_USER_DEPRECATED. And I can't find any configuration option in Apache to turn off reporting of deprecated items from PHP either.

Frustrating. It's filling up the error logs with so many notices that it makes them nearly useless. In 24 hours, on a forum that isn't so busy, the error log has nearly grown to 1GB in size.

I was hoping someone here might know, but apparently not. Back to digging the Internet for more incorrect answers...
 
This might have a clue.


I do have PHP pointing to its own error log files, but if I understand it correctly, it seems that when PHP can't find its own error log to write to, it passes along the log data to the process that requested it. Nothing applies directly to my situation though.

I've been restarting PHP8.5-FPM each time I make a change.

I'll keep looking here. As it stands now, I am writing the site's Apache error log to /dev/null so I don't wake up with a nearly 1GB error log file. (I can only imagine how big the file would grow on our busiest forum.) I can re-enable writing if I have an issue.
 
I ended up editing /src/XF.php to fix the bug. The forum I'm having the issue with is running XF 2.2, so that's where the error is happening. I thought my test forum was creating the error, but it is on 2.3.4 which was the version that fixed the error.

I made a backup of the file. This is untested, but should work.

For public static function standardizeEnvironment(), I went down to error_reporting and changed it to:

Code:
error_reporting(E_ALL & ~E_DEPRECATED);

A little further down, below public static function handlePhpError, find $isDevError. The new statement should be:

Code:
$isDevError = (
$errorType & E_DEPRECATED ||
$errorType & E_USER_DEPRECATED ||
(PHP_VERSION_ID < 70400 && $errorType & E_STRICT) // php 7.4+ does not use strict errors
);

This is copying the lines out of the /src/XF.php file in version 2.3.4. I have yet to test it (as I'm on the way out) but the forum is working. I'll reenable my logging once I get back to my desk later.

This 2.2 forum is being upgraded soon, so it won't be an issue past that.
 
Last edited:
The edit to /src/XF.php worked. The noise is gone from the logs. I never edit core files, but since this 2.2 version will be going away in a week or two, I'm not worried about it any longer.
 
Your fix won't apply directly to my issue, of course, but I'm glad you found a solution. It does point out something strange to me - it appears XF itself has a configuration for PHP error reporting. I think it should follow the server's configuration, or at least not override it. I'll have to take a look to see if there's a way to program an add on or something to over-ride XF.php's error handling, if that's what it's really doing.
 
My only thought is that it might be a means to control how the errors are processed internally, and/or displayed.

I guess it's not so unusual for an application to try and control how PHP messages and warnings are handled within the app. In my case it's the XF redirect script that is throwing the errors. I may put it into Claude and ask it to fix the code so it's compatible with PHP 8.3.36.
 
For any others finding this thread and wondering, I asked Claude AI to evaluate the XF redirect script, ips2xf.php and, after Claude requested it, my .htaccess code to determine what was causing the Server error log entries. Here is what it said:What’s happening
Your URL is index.php?/topic/7398-.../page__p__64307&forcePrint=1.... PHP treats everything up to the first & as a single query key, so none of the named parameters (p, showtopic, etc.) are set. The if / else if chain falls to the last branch, which reads:

php
else if (!preg_match('#(?P<content>p)(?P<id>\d+)#s', $_SERVER['REQUEST_URI'])) // posts

That branch only runs when the URL does not contain p<digits>. Your URL does contain __p__64307, so the branch is skipped, content_type is never set, and line 81 warns. The branch that should handle post URLs was never written, so these links have been 301ing to your forum index instead of the post. The same warning also fires for any URL that matches nothing at all.

I’m inferring the intent from the surrounding code, but the edit below makes it behave the way the rest of the script clearly expects.


Edit 1: replace the final else if block

Replace this block:

php
else if (!preg_match('#(?P<content>p)(?P<id>\d+)#s', $_SERVER['REQUEST_URI'])) // posts
{
preg_match('#/(?P<content_type>topic|forum|user|profile|gallery/image|gallery/album|gallery/category|gallery)/(?P<content_id>\d+)#s', $_SERVER['REQUEST_URI'], $match); // threads, forums, users, profile posts
$input += $match;
}

with:

php
else if (preg_match('#p(\d+)#', $_SERVER['REQUEST_URI'], $match)) // posts
{
$input['content_type'] = 'p';
$input['content_id'] = $match[1];
}
else if (preg_match('#/(?P<content_type>topic|forum|user|profile|gallery/image|gallery/album|gallery/category|gallery)/(?P<content_id>\d+)#s', $_SERVER['REQUEST_URI'], $match)) // threads, forums, users, profile posts
{
$input['content_type'] = $match['content_type'];
$input['content_id'] = $match['content_id'];
}

Edit 2: add a safety net right after that chain


Put this just before the $params = []; line:



php
$input += ['content_type' => '', 'content_id' => 0];

+= only fills in keys that are missing, so it never overrides a real match. Unmatched URLs now fall through to the existing if (!$target) fallback to the index with no warning.

Claude AI also complained about an unrelated typo with suggested corrections:
The line in your file is:

php
else if ($input['attach_id'] && $input['app'] == 'core' && $input['module'] == 'attach' && $input['section'] = 'attach')

Change it to:

php
else if ($input['attach_id'] && $input['app'] == 'core' && $input['module'] == 'attach' && $input['section'] == 'attach')

The only real change is = to == at the end. I also removed the extra space.

The .htaccess file had an unrelated error with a section I added to block ai crawlers (Meta-ExternalAgent, GPTBot, etc.) That section had to come before the catch-all rules. It would not cause the Server error log to notice, but the block would never take effect as the query would redirect before the block was read by the Ai crawlers.

It looks like this solved my problem with the ips2xf.php script running under PHP 8.3.36, but I'll watch it for a few days and report back if it doesn't work.
 
Back
Top Bottom