PHP Error Log error filtered out partly recurs days later

Could you check how those traces appear in the actual log file? In rare cases, I’ve seen error details get logged out of order, which could cause the plugin to parse them incorrectly.

The ‘echo’ of part of the original error does not appear in the actual log file. The errors appear correctly in the actual log file.

What do you mean by “echo”? Could you post the full entry from Aug 30?

Sorry if I’m not explaining properly Janis. The error on Aug 30 that repeated part of the original error message on Aug 26 was:
#0 /home/onenameg/public_html/wp/wp-includes/class-wp-hook.php(310): wp_get_footnotes_from_revision(”, ‘footnotes’)

So, in the log file, the “new” error is also just that single line from the earlier stack trace, nothing else? That’s very strange, but it’s probably not directly related to this plugin. ELM doesn’t write error details to the log file (at least not in the free version), PHP itself does that.

As for why it happens, my best guess would still be that multiple different errors are being logged in a way where their details appear out of order or overwrite each other. It seems plausible that this could be caused by concurrency problems if PHP doesn’t lock the log file when writing to it, and I don’t know if it does.

Finally, the entry shows up in the plugin because the “ignore” filter only looks at the main error message, not at the stack trace. It will not filter out entries where the error message or a stack trace item matches part of the stack trace of an earlier filtered error.

Hi again Janis
I don’t think I explained properly what the problem is. The single line from the earlier stack trace is appearing in the ELM in the Dashboard not in the php error log file. It’s still happening even though I’ve filtered out the full error so that it no longer appears in the ELM on the Dashboard. But the single line from the now filtered error is still appearing on the Dashboard.

All right, so where does that line come from? Whether it’s part of a new copy of the full error, or somehow logged on its own, it must still be in the log file in some form or the plugin wouldn’t be able to display it. (That may not necessarily apply to the Pro version of the plugin when using the “Summary” view, but I’m assuming that you’re using the free version since you’re posting in this forum.)

If it’s part of another copy of the full error, it might be that it was logged in a different format than expected (e.g. different spacing or incorrect item numbers) and the plugin doesn’t parse it correctly, which is why I would like to see the full entry.

It’s part of another copy of the full error that is in the log file Janis. The full error is:

[04-Sep-2023 05:06:50 UTC] PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function wp_get_footnotes_from_revision(), 2 passed in /home/onenameg/public_html/wp/wp-includes/class-wp-hook.php on line 310 and exactly 3 expected in /home/onenameg/public_html/wp/wp-includes/blocks/footnotes.php:210

Stack trace:

#0 /home/onenameg/public_html/wp/wp-includes/class-wp-hook.php(310): wp_get_footnotes_from_revision(”, ‘footnotes’)

#1 /home/onenameg/public_html/wp/wp-includes/plugin.php(205): WP_Hook->apply_filters(”, Array)

#2 /home/onenameg/public_html/wp/wp-content/plugins/wiki/wiki.php(1561): apply_filters(‘_wp_post_revisi…’, ”, ‘footnotes’)

#3 /home/onenameg/public_html/wp/wp-content/plugins/wiki/wiki.php(1207): Wiki->decider(‘<div class=”mem…’, ‘history’, 0, 0, 0)

#4 /home/onenameg/public_html/wp/wp-includes/class-wp-hook.php(310): Wiki->theme(‘<div class=”mem…’)

#5 /home/onenameg/public_html/wp/wp-includes/plugin.php(205): WP_Hook->apply_filters(‘<div class=”mem…’, Array)

#6 /home/onenameg/public_html/wp/wp-includes/post-templa in /home/onenameg/public_html/wp/wp-includes/blocks/footnotes.php on line 210

But only this part displays in ELM on the Dashboard:

#6 /home/onenameg/public_html/wp/wp-includes/post-templa in /home/onenameg/public_html/wp/wp-includes/blocks/footnotes.php on line 210

Hope that’s clearer.

Cheers

Robert

Thank you for posting the full error. I didn’t spot anything unusual about it at first, but after running the original error and this one through a diff tool, it turns out that the second one is slightly different: the line number in the main error message (and the last stack trace item) is 210 instead of 211.

The plugin treats the file name and line number as part of the main error message, so this difference would explain why this error isn’t being filtered out. However, even in this case, it’s supposed to show the full error, not just one line from the stack trace.

I tried putting both errors in a log file and testing how the plugin actually parses them, but it displayed both examples correctly. At the moment, I unfortunately have no idea how it could end up with just one stack trace item instead of full error + stack trace in this situation.

• This reply was modified 1 year, 2 months ago by Janis Elsts.

Hi Janis
ELM is filtering the main error regardless of line numbers because I entered:

Uncaught ArgumentCountError: Too few arguments to function wp_get_footnotes_from_revision()

in ‘Ignored regular expressions’

That’s why they’re not appearing. Simply Ignoring the error didn’t work because the line numbers kept changing.

Does this help at all?

I see, I initially assumed you were using the “Ignore” option. Yes, using the custom filter settings should work. I tried your example on a local test site and it did successfully filter out both errors and their stack traces.

I still can’t think of a plausible way both errors could be filtered out except for one specific item from the stack trace.

Maybe if that line happens to be right at the edge of the “window” that the plugin looks at? For performance, the plugin doesn’t read the whole file, just the last X lines, so a long multi-line entry can occasionally end up with its top cut off. In this case, the orphaned line(s) would always appear either at the bottom or the top of the widget (depending on whether reverse line order is enabled).

Thanks very much Janis for explaining. That certainly sounds like what is happening here. At the moment it appears that I may have finally filtered out all of the error. I assume I could also filter out each trace that is appearing individually without the line number? I’ll try that if the problem recurs. It is an unusually long error and it occurs about 5 times a day in the php error log. Thanks again for all your help. Cheers Robert

I assume I could also filter out each trace that is appearing individually without the line number?

Yes, though I think that will only work in this edge case where a trace item shows up as a separate entry.