Handle file objects like file_upload

[ob-stripe]

r? @brandur-stripe
cc @stripe/api-libraries

Like stripe/stripe-ruby#689, but for PHP.

[brandur-stripe]

Very fast work! :)

LGTM.

[ob-stripe]

I pushed another commit to only use files.stripe.com for file creation requests. I had to change a few things to make it possible to override the API base per request, by making it possible to pass an api_base option.

I also had to split the file creation tests into separate test classes, because they need their own setup/teardown methods.

[ob-stripe]

ptal @brandur-stripe

[brandur-stripe]

Sorry for the nit, but given that the separate test file breaks convention elsewhere, could we add a short comment here that just explains that these tests have been moved to a separate suite because the methods they invoke use a separate API hostname?

[brandur-stripe]

(And same on this one.)

[ob-stripe]

Released as 6.18.0.

[ruudk]

Next time, please release this as a new major as it's a breaking change.

[ob-stripe]

@ruudk \Stripe\File is aliased to \Stripe\FileUpload, so it shouldn't be a breaking change. Can you share an example where existing code would cease to work after upgrading to 6.18.0?

[ruudk]

First, PHPStan failed for it:

 ------ ------------------------------------------------------------------------- 

  Line   src/Platform/StripeBundle/Service/Stripe.php                             

 ------ ------------------------------------------------------------------------- 

  812    Return typehint of method                                                

         xxx\Platform\StripeBundle\Service\Stripe::uploadFil  

         e() has invalid type Stripe\FileUpload.                                  

  823    Call to static method create() on an unknown class Stripe\FileUpload.    

 ------ ------------------------------------------------------------------------- 

We fixed that, and then on production this happened:

[ob-stripe]

Weird, it looks like for some reason the class aliasing isn't working in your environment, but I have no idea what could cause that -- if you can use \Stripe\File, that means that the File.php file was loaded and the class_alias statement should definitely have been executed.

[ruudk]

I think the issue is that File.php is never loaded. The autoloader is searching for FileUpload and cannot find it. I see that you include the File.php inside init.php. But we never run include that file.

[ruudk]

The standard is to use Composer autoloader, so no init.php file will be loaded. That means that the only way to solve this class alias is to create the file FileUpload.php and there include the class_alias function?

[ob-stripe]

Ah yes, that's likely the issue. Our test suite didn't catch this even when using autoload because we have tests for both File and FileUpload, so File.php would get loaded.

I'll push a fix with what you suggested. Thanks very much for your help, and sorry for the trouble!

[ob-stripe]

@ruudk I've just released 6.19.4 to fix the autoloading issue. I guess you've already updated your integration to use File instead of FileUpload so you don't need to upgrade, but it will prevent other users from running into the same issue.

Thanks again for your help in investigating and fixing this issue! Much appreciated :)