I have an install of 2.8.4 using AWS S3 Media Source to connect to an S3 server managed by the Univ of Wyoming. I am able to view the files using the files tab but not using the Media browser.
This has worked in the past and I have not updated either MODX or the AWS S3 Media Source recently to cause the issue.
Here is the error message in the error log:
[2023-01-04 15:27:11] (ERROR @ /www/core/components/awss3mediasource/model/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php : 67) PHP warning: count(): Parameter must be an array or an object that implements Countable
Any body have suggestions for a fix or work around?
Background on why I am using the AWS S3 Media Source extra. The default built in S3 functionality did not work with the S3 server.
Do you have any other extras that use Guzzle? That could cause conflicts between incompatible Guzzle versions.
I do not know which extras use Guzzle. I have to check.
Would the Guzzle7 extra by @markh resolve this issue?
@bobray- I had upgrademodx (uses guzzle) installed, but since the site was moved to MODXCloud it is not needed. I removed the extra. Still getting the error in the log but the files are displaying in media browser.
I created a cloud where I will test using Guzzle7 and see if that removes the error from the log.
Thanks so much
It seems to me that Guzzle has not been great about maintaining backward compatibility. Using Guzzle was supposed to make things easier and more reliable, but I’m beginning to think sticking with cURL might have been a better choice.
Guzzle is pretty great at BC, actually. They have different versions with different PHP versions they support, and even some of the really old (5/6) versions are pretty solid today. The differences between the more recent versions are minor, and only affect more advanced use cases.
The problem is we have different extras including different versions of Guzzle. And MODX 3 now includes Guzzle 7 as well.
One may be built for Guzzle 6 while the other requires Guzzle 7. They both get added to the autoloader. There may be other libraries (like the AWS SDK or payment gateways in Commerce) trying to detect which version of guzzle is available to account for the minor changes in how those should be called for advanced use cases.
And then, different versions get loaded into memory randomly (because PHP has no sense of priority in autoloading), and things break.
The guzzle7 package helps avoid those by
- providing the latest guzzle 7.x version, but only if guzzle is not already available (i.e. MODX3)
- pre-loading the classes that are most commonly used to avoid those version check errors in SDKs
I’d recommend adopting that in UpgradeMODX as well to avoid future conflicts. More information on why and how can be found in the guzzle7 readme
Alternatively for packages that only support MODX3 and make their own requests, use the http services. Those are version-agnostic and allow the MODX core to provide different implementations as long as they follow the PSR standards.
@markh I bow to your superior knowledge about Guzzle.
That said, I keep running into situations where I wish I had stuck to cURL. If I had, I wouldn’t be thinking about rewriting the UpgradeMODX code right now.