[wp-trac] [WordPress Trac] #59195: deprecation notice triggered in post.php by passing null to parameter #2 in preg_match()
WordPress Trac
noreply at wordpress.org
Thu Feb 15 17:32:17 UTC 2024
#59195: deprecation notice triggered in post.php by passing null to parameter #2 in
preg_match()
-------------------------------------------------+-------------------------
Reporter: nosilver4u | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting
| Review
Component: Media | Version: 6.3
Severity: normal | Resolution:
Keywords: has-patch needs-testing php81 | Focuses: php-
changes-requested | compatibility
-------------------------------------------------+-------------------------
Comment (by nosilver4u):
I finally figured out where this was coming from. I didn't do a regular
"trace", but here's the code path:
wp_match_mime_types() in wp-admin/includes/post.php - 3376
called by WP_Media_List_Table->get_views()
which uses the global $avail_post_mime_types, populated by
wp_edit_attachments_query() called in
WP_Media_List_Table->prepare_items().
wp_edit_attachments_query() is in wp-admin/includes/posts.php and runs
this:
$avail_post_mime_types = get_available_post_mime_types( 'attachment' );
The query in get_available_post_mime_types() returns all the distinct
post_mime_type values from $wpdb->posts. And in my case, there were a pile
of PDF files with no post_mime_type defined.
I don't know how that happened, but a bunch of them were from 2018/2016 (I
already "fixed" them, but could probably dig up a backup if needed).
So, any attachments with an empty post_mime_type column will trigger this
bug, as you'll end up with an empty item in the global
$avail_post_mime_types. Theoretically, it could be fixed by altering the
SQL, but I'm not sure what the best approach is here.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59195#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list