Opened 13 months ago
Last modified 10 months ago
#60003 assigned defect (bug)
PHP error in wp_match_mime_types()
Reported by: | argaliano15 | Owned by: | pbearne |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 6.4 |
Component: | General | Keywords: | reporter-feedback has-patch has-unit-tests |
Focuses: | Cc: |
Description (last modified by )
PHP ERROR:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /.../wp-includes/post.php on line 3308
FIX:
change LINE 3308 to:
if ( $real && preg_match( "#$pattern#", $real ) ^^^^^^^^^
Change History (10)
#1
@
13 months ago
- Description modified (diff)
- Keywords reporter-feedback added
- Summary changed from php error to PHP error in wp_match_mime_types()
#2
in reply to:
↑ description
@
13 months ago
When the status of this very bad change to the php engine goes from 'deprecated' to 'in effect', the result is going to be disastrous. This is going to needlessly break code everywhere, it is basically sabotage.
It does not matter where the null comes from, it only matters that it snuck through. You can either try to stop an unknown number of shooters over which you have no control, or protect the target. This is simple logic. Every instance of preg_match now needs to be checked against a null input, every one in the entire WP codebase! This will be a very serious problem.
PROFESSIONAL programmers would call this 'code hardening', and also 'proactive', 'responsible' and 'doing their job'. And the official WordPress response to my warning - nitpick, and blame the messenger. This is why I rarely bother reporting bugs in WordPress, I just hack them myself. I guess I'll just add this one to my list.
Replying to argaliano15:
PHP ERROR:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /.../wp-includes/post.php on line 3308
FIX:
change LINE 3308 to:
if ( $real && preg_match( "#$pattern#", $real ) ^^^^^^^^^
#3
@
13 months ago
The cause of an error or warning is always important. Without an example of how the code fails, how can developers know that the hardening fix is good enough? It might need to check precisely whether the type is either a string or an array of strings (as block_core_gallery_render()
does). I also do not know what the wp_match_mime_types()
function should return if the second parameter is not an acceptable type.
I did not close this ticket (or even suggest closing it). If the problematic code is in a plugin, it likely needs to be reported and fixed there so the plugin operates as intended. If something in Core causes the error, the Core team needs to know where to find it.
#5
@
12 months ago
Hi All,
Looking at this code we can fix this by returning early if either the parms are empty
this saves compute so I will fix it with this
Paul
This ticket was mentioned in PR #5763 on WordPress/wordpress-develop by @pbearne.
12 months ago
#6
- Keywords has-patch has-unit-tests added
A PHPUnit test for the wp_match_mime_types
function has been added to ensure that it behaves as expected in different scenarios. The function has also been refactored to better handle empty input, improving its robustness and reliability. Moreover, the usage of preg_quote
has been tweaked to avoid potential issues with MIME type matching.
This ticket was mentioned in PR #5763 on WordPress/wordpress-develop by @pbearne.
12 months ago
#7
A PHPUnit test for the wp_match_mime_types
function has been added to ensure that it behaves as expected in different scenarios. The function has also been refactored to better handle empty input, improving its robustness and reliability. Moreover, the usage of preg_quote
has been tweaked to avoid potential issues with MIME type matching.
#9
follow-up:
↓ 10
@
12 months ago
Another one:
error generated from wp_get_attachment_metadata:
"PHP Deprecated: Automatic conversion of false to array is deprecated in ..."
Apparently, ALL implicit type conversions are now deprecated. At this point, it is hard to guess what is coming. This is much worse than just the string conversion bug I reported earlier. Millions of lines of code will have to be checked and re-written. There aren't enough programmers on the planet. This is either breathtaking academic stupidity or a deliberate plan to take down the internet.
And once again, I will say that moving all these checks and conversions from compiled code to interpreted code is not going to make anything faster or safer. The people in charge of php are idiots, and this is getting scary.
Am I the only person who monitors error logs?
#10
in reply to:
↑ 9
@
12 months ago
Replying to argaliano15:
Another one:
error generated from wp_get_attachment_metadata:
"PHP Deprecated: Automatic conversion of false to array is deprecated in ..."
Apparently, ALL implicit type conversions are now deprecated. At this point, it is hard to guess what is coming. This is much worse than just the string conversion bug I reported earlier. Millions of lines of code will have to be checked and re-written. There aren't enough programmers on the planet. This is either breathtaking academic stupidity or a deliberate plan to take down the internet.
And once again, I will say that moving all these checks and conversions from compiled code to interpreted code is not going to make anything faster or safer. The people in charge of php are idiots, and this is getting scary.
Am I the only person who monitors error logs?
Was this error with the patch installed?
If so do you know what the parms passed were?
Paul
Hi and welcome to WordPress Core Trac!
The
wp_match_mime_types()
function has always required a string or an array of strings for both parameters (r6910).Could you check for a stack trace and/or deactivate plugins individually to determine where the function was used?