Make WordPress Core

Opened 5 weeks ago

Last modified 3 weeks ago

#62347 new defect (bug)

wp_get_image_mime does not check that the file exists

Reported by: iulia-cazan's profile Iulia Cazan Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords: reporter-feedback has-patch close
Focuses: Cc:

Description

The wp_get_image_mime function does not check the file exists before calling file_get_contents, which produces warnings that fill the error log.

Change History (8)

#1 @swissspidy
5 weeks ago

From what I can see at first glance, all the places in core using wp_get_image_mime do a file existence check beforehand. Maybe a plugin of yours doesn't do it, so that would need to be fixed there. Do you have a backtrace or so?

#2 @tusharaddweb
5 weeks ago

I have tested wp_get_image_mime function in the latest WordPress version and it's working fine.

#3 @desrosj
4 weeks ago

  • Component changed from General to Media
  • Keywords reporter-feedback added

This ticket was mentioned in PR #7761 on WordPress/wordpress-develop by @abcd95.


4 weeks ago
#4

  • Keywords has-patch added

Trac ticket: Core-62347

## Description
The wp_get_image_mime() function currently attempts to read file contents without first verifying if the file exists or is readable. This can result in PHP warnings being written to error logs, especially in environments where WP_DEBUG is enabled.

This PR adds appropriate checks at the beginning of the function to prevent these warnings while maintaining the existing behavior of returning false for invalid images.

## Changes proposed in this Pull Request:

  • Add file_exists() check at the start of wp_get_image_mime()
  • Add is_readable() check to ensure file permissions allow reading

## Benefits:

  • Reduced Error Logs: Prevents unnecessary PHP warnings from filling up error logs, making actual errors easier to identify
  • Improved Debugging: Makes debugging easier by eliminating noise from non-critical file access warnings
  • Better Error Handling: Provides more predictable behavior by explicitly checking file accessibility before attempting operations
  • Best Practices: Follows PHP best practices by validating resources before attempting to use them

#5 follow-up: @abcd95
4 weeks ago

Hey Iulia, Thanks for raising this.

I tested it using the 6.8 alpha version. I was able to reproduce the same issue ( image attached below ).

Please let me know if there is anything else we can do.

https://postimg.cc/w7CnK5BZ

Thanks.

#6 in reply to: ↑ 5 @Iulia Cazan
4 weeks ago

Replying to abcd95:

Hey Iulia, Thanks for raising this.

I tested it using the 6.8 alpha version. I was able to reproduce the same issue ( image attached below ).

Please let me know if there is anything else we can do.

https://postimg.cc/w7CnK5BZ

Thanks.

Hi! I checked the patch and it seems to fix the issue. Thanks!

#7 @desrosj
3 weeks ago

  • Keywords close added

I'm going to add a close suggestion for this.

I went and checked all instances where wp_get_image_mime() is called in Core and confirmed what @swissspidy said above. The file is always verified before calling that function.

I don't think that the attached pull request is one that we should make. The function is responsible for determining the mime type of an image file and returns false if one cannot be determined. If it's changed to return false when the file does not exist, it would be misleading when the file is missing or invalid. It also silences scenarios like this where a plugin or theme is likely not properly verifying a file.

@iulia-cazan could you provide a backtrace of the error you are seeing? Could you try to disable your plugins one at a time to see if the problem is solved? Or, if you can reproduce the error with a fresh install of WordPress, can you please provide steps someone else can take to replicate the error?

#8 @Iulia Cazan
3 weeks ago

@desrosj, just close it, if this should not be fixed at least for best practice purposes.

Note: See TracTickets for help on using tickets.