The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.See #2687809: Use version 3.x of Stripe php libraries
The module checks to ensure that the Stripe library version is one that the module supports. If it isn't, it reports it on the site's admin status page.
At the time of writing, the supported versions are 2.2.0 and 3.13.0.
If an unsupported version on the Stripe library 2.x branch is installed, this is correctly reported in the status page.
If an unsupported version on the Stripe library 3.x branch is installed, any attempt to load the Status page causes a PHP error and the page does not load:
PHP Fatal error: Class 'Stripe\StripeObject' not found in path-to-site/sites/all/libraries/stripe/lib/ApiResource.php on line 5
The same error, and the same WSOD, occurs if someone attempts to place an order using this module when an unsupported 3.x version is installed.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | uc_stripe.unsupported_versions_2760139_06.patch | 4.27 KB | rfay |
| #3 | Status_report___Site-Install.png | 22.06 KB | rfay |
| #2 | uc_stripe-correctly-report-wrong-library-version-2760139-2.patch | 2.36 KB | jamesoakley |
Comments
Comment #2
jamesoakleyOK: I'm not happy with the attached patch, but it does fix the issue. (Hence Needs Work rather than Needs Review). You need to apply the patch at #16 in #2687809: Use version 3.x of Stripe php libraries first
The problem arises because the module allows multiple versions of the Stripe library.
hook_libraries_info() will assume that, where there is a versions key in the returned array, each sub-key gives the lowest version number for which the specified files will match.
As it stands, uc_stripe_libraries_info() only contains two versions, 2.2.0 and 3.13.0. 2.2.0 gives the files to load for Stripe's 2.x library, and 3.13.0 gives the files for Stripe's 3.x library. If a site has any 2.x library, this will handle correctly. If a site has a 3.x library >= 3.13.0, it will handle correctly. If a site has a 3.x library below 3.13.0, it will load the files that you'd get with the 2.2.0 library, but being on the 3.x branch those files won't match.
So we have to force hook_libraries_info to load the Stripe 3.x library files for any 3.x library, not just for 3.13.0 upwards.
Attempt 1: Define 3.0.0 as a version. That's no good, because 3.0.0 will then become an acceptable Stripe library version, which it isn't.
Attempt 2: Define 2.999.0 as a version, specifying the files you'd get with Stripe's 3.x branch. That means that any Stripe library from 3.0.0 upwards will load the correct files, and report an error if it's not exactly 3.13.0. However, the error message at installation or in the site's status page will say that you need to use either 2.2.0 or 3.13.0 or 2.999.0 - which is confusing.
So, attempt 3, and a hideous hack: In implementing hook_requirements, remove that 2.999.0 string from the list of allowed versions, so it doesn't appear in the error message. Ugh. Hence, "needs work".
But it works, so hopefully this is a start towards a more elegant solution.
Comment #3
rfayI am unable to recreate this - I tried using a couple of different 3.x libraries and got the right thing on admin/reports/status. I even checked out and made a payment with the wrong 3.x version.
This is PHP 5.6.23, with #2687809: Use version 3.x of Stripe php libraries committed. Drupal 7 dev between 7.43 and 7.44.
Let me know what we're doing differently. Could it be the different PHP version?
Comment #4
rfayWow, then I clicked around a while, (after successfully processing an order payment), installed a module, was working on something entirely different, and got your crash visiting admin/config
Comment #5
rfayIMO we should allow all 2.x and 3.x versions of the Stripe library. None of them has ever not worked for me. I'm not sure why the "tradition" started of requiring a specific version
Comment #6
rfayI think the basic problem was that versions of 3.x BEFORE 3.13 were using the rules for 2.2.0 in hook_libraries_info(). That made libraries_load() attempt to load the files listed, and they don't work the same in 3.x.
I think this patch probably resolves this set of issues, and allows compatibility with upcoming versions.
Comment #8
rfayI went ahead and pushed #6. Would appreciate people testing the dev version, which will be updated shortly.