Make WordPress Core

Opened 6 months ago

Last modified 3 months ago

#60003 assigned defect (bug)

PHP error in wp_match_mime_types()

Reported by: argaliano15's profile argaliano15 Owned by: pbearne's profile 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 sabernhardt)

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 @sabernhardt
6 months ago

  • Description modified (diff)
  • Keywords reporter-feedback added
  • Summary changed from php error to PHP error in wp_match_mime_types()

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?

#2 in reply to: ↑ description @argaliano15
6 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.

I expect to get banned from this forum now, which is good, it will keep me from wasting my time in the future.

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 )
     ^^^^^^^^^
Last edited 6 months ago by argaliano15 (previous) (diff)

#3 @sabernhardt
6 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.

Last edited 5 months ago by sabernhardt (previous) (diff)

#4 @pbearne
5 months ago

  • Owner set to pbearne
  • Status changed from new to assigned

#5 @pbearne
5 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.


5 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.


5 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.

#8 @pbearne
5 months ago

I added PHPUnit test at the same time.

@argaliano15 can you test the patch?

#9 follow-up: @argaliano15
5 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 @pbearne
5 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

Note: See TracTickets for help on using tickets.