[Uploadable] Remove deprecation warning when calling is_file with a null value

[JoolsMcFly]

Hi!

We've been getting lots of deprecation warning (Deprecated: is_file(): Passing null to parameter #1 ($filename) of type string is deprecated) coming from src/Uploadable/UploadableListener::removeFile:

public function removeFile($filePath)
{
    if (is_file($filePath)) {
        return @unlink($filePath);
    }

     return false;
}

This PR simply adds a check for null:

if (!is_null($filePath) && is_file($filePath)) {

Thanks for reviewing!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.66%. Comparing base (7622db1) to head (25f3bfe).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2901   +/-   ##
=======================================
  Coverage   78.66%   78.66%           
=======================================
  Files         167      167           
  Lines        8746     8746           
=======================================
  Hits         6880     6880           
  Misses       1866     1866           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mbabker]

Do you have a stack trace showing how this method is being called with null? The doc block says that only strings should be passed in, so something else is already _doing_it_wrong() by calling this method with a null value (and if it's something in this package, that should be updated as well).

[JoolsMcFly]

Hi @mbabker .

Here's what we get in Sentry:

I guess we could add a check in postFlush as well?

[mbabker]

That's helpful as it leads me to two other minor issues:

• The protected getFilePathFieldValue() method isn't guaranteed to return a string if it's reading direct from a class property (so that return should be at least string|null)
• The protected addFileRemoval() method should probably make sure getFilePathFieldValue() returns a non-empty value before writing to the $this->pendingFileRemovals list

Making changes around those two methods in theory should ensure that the listener isn't calling removeFile() with a totally bad parameter.

[JoolsMcFly]

Hey, thanks for your comment. Do you want me to make changes you listed in my PR?

[mbabker]

Yes, that'd be the more correct fix to make here.