Actually, WHMCS is using the library Guzzle 5.3.1. Some new library requires to use Guzzle 6, so it may be useful to upgrade to version 6.
Thanks for your suggestion.
We monitor for updates to our dependencies and include them when security or new funcitonality we wish to leverage requres it. Due to the major version bump in Guzzle indicating backwards incompatible changes, we would likely also need to reserve such a change to a major version change of our own (eg. v6, v7, v8).
Better is the change to HTTPlug...
we have massive problems too, with that. Regarding many Modules....
Which problems are you experiencing and with which modules? We are not currently aware of any Guzzle-related issues in any of the stock modules distributed in WHMCS.
Modules with Guzzle 6 breaks the WHMCS Updates Task from the daily cron job. For example, a module with the cloudflare-sdk composer package.
Thanks for that information. It's the responsibility of the module developer to ensure that their code is compatible with the WHMCS software and its dependencies, not the other way round. The vendor would need to adjust their code to work within our current framework.
Although I partly agree with the responsibility of the module developer, I wonder what feature requires third party modules to be included during the update process. We're having similar issues but unfortunately we can't rewrite our code because Guzzle is a dependency of on of our own dependencies.
If you ask me WHMCS should make an effort to either keep its dependencies up-to-date or allow for better separation between composer packages in WHMCS and modules. I understand that Guzzle 5 is still in maintenance but version 6 was released in 2015 already, it was released before the version you're currently using.
Either way a big +1 from me.
1 year later... Nothing changed...
Guzzle 5 is now EOL: https://github.com/guzzle/guzzle#version-guidance
No more bug and security fixes... it's most definitely time to update to Guzzle 6.x. It's not even close to a discussion anymore: it's an imperative.
Now it happened, in WHMCS an outdated HTTP client without security updates is used. It is not that this request is already over a year old.
I still remember the excuse. They wanted to ensure the greatest possible compatibility with the modules. My modules based on Guzzle 6 fell by the wayside, because my modules blocked the cronjob of WHMCS, because there was a conflict with Guzzle 5 during the WHMCS update check...
Thanks WHMCS for the support ...
WHMCS 7.10 is live, now not only is the auto updater not working, but whole admin area crashes due to one of the modules is using Guzzle 6.
TypeError: Argument 3 passed to GuzzleHttp\Client::request() must be of the type array, string given, called in .../whmcs/modules/addons/.../vendor/guzzlehttp/guzzle/src/Client.php on line 87 and defined in .../whmcs/modules/addons/.../vendor/guzzlehttp/guzzle/src/Client.php:126
#0 .../whmcs/modules/addons/.../vendor/guzzlehttp/guzzle/src/Client.php(87): GuzzleHttp\Client->request('createRequest', 'GET', 'https://www....')
#1 .../whmcs/vendor/whmcs/whmcs-foundation/lib/View/Admin/HealthCheck/HealthCheckRepository.php(0): GuzzleHttp\Client->__call('createRequest', Array)
#2 .../whmcs/vendor/whmcs/whmcs-foundation/lib/View/Admin/HealthCheck/HealthCheckRepository.php(0): WHMCS\View\Admin\HealthCheck\HealthCheckRepository->checkForSensitiveDirectoryRemoteAccess()
Honestly, I don't care about having an automatic updater as manual update does the job as well. I don't know why does the health checker keep failing now (maybe it's trying to see if there's a new version available), but why not simply implement error handling that says "Couldn't not determine the latest version. <Possible reason>" instead of crashing the page? From what I've noticed, WHMCS Updater is the only part that's having an issue with guzzle.
This issue is affecting us as well, we'd be grateful for your consideration to upgrade Guzzle to version 6.
Comments have been locked on this page!