PHP error: GuzzleHttp does not recognize cURL features

Hi @mezzomedia,

May I ask which version you updated from? Version 5.11.0 should have a different Guzzle setup.
The PHP stream handler should only be used when cURL is not installed, so I don’t think allow_url_fopen is mandatory here.
To use the cURL handler, you must have a recent version of cURL >= 7.19.4 compiled with OpenSSL and Zlib.
Maybe this is a conflict with a different plugin, preventing Guzzle from seeing cURL.
Does the issue persist when you disable all other plugins except for WooCommerce and Mollie? We are also interested to see a list of all installed plugins. Thanks!
We are still working on a scoping solution, but it is a very involved task and requires more time. I will check back with our developers about your suggestion.

Kind regards,
Niklas

Hi Niklas,

Thanks for the quick reply.

I have tried the following:
– disabling other plugins, except WooCommerce and Mollie: exact same error when visiting the WooCommerce > Settings page in the admin.
– deactivating plugin version 6.0, installing version 5.11.0: same problem.
– installing version 5.10.0: same problem.

Note: the curl_exec and curl_multi_exec functions are disabled.

This happens when I have allow_furl_open set to Off. As mentioned earlier, turning this setting On solves the error, but has negative effects for server/website security.

The PHP 7.4 info page mentions a cURL version higher than 7.19.4, with NSS and ZLib.

Let me know if you want me to share the exact version numbers and list of plugins in a private message.

Hi @mezzomedia,

Thanks for testing. We released our new update 6.1 today, please give it a try.
In any case we would like to learn a little bit more context about your site. Can you please open a support ticket with us directly as described here.
Please include a copy of your WooCommerce status report and a link to this thread.
Thanks!

Kind regards,
Niklas

Hi Niklas,

After some extra testing, also with 6.1 (same issue), I think the error is because of the following:

1. I have the cURL extension for PHP set to enabled,
2. the curl_exec() and curl_multi_exec() functions are both disabled in the PHP configuration,
3. the Guzzle dependency used in the Mollie Payments plugin does not strictly check if these specific cURL functions are enabled or disabled. It only checks if the cURL extension for PHP is enabled.
4. then, when the Guzzle remote connection attempt fails, it recommends to enable cURL, even though the cURL extension is already enabled. While it should in fact check the availability of those cURL PHP functions.

When I enable the curl_exec() and curl_multi_exec() functions for this specific virtual host, even with allow_url_fopen disabled, the issue seems solved.

Does this means that the Mollie plugin depends on either these cURL functions or allow_url_fopen to be enabled?

Or would there be another option to make this work without sacrificing server security?

Cheers

Hi @mezzomedia,

Thanks for testing some more.
The plugin itself does not need Guzzle, but it is required by the Mollie SDK, which we do require. I will have to check back with the SDK developers about how exactly this is used and what the specifications are.
There are many potential issues related to Guzzle and we are investigating our alternative options to maybe get rid of it altogether.
I will get back to you after I had the chance to talk to the relevant developers about it.

Kind regards,
Niklas

Hi @mezzomedia,

Guzzle requires either allow_url_fopen, or cURL with the mentioned functions.

if (ini_get('allow_url_fopen')) {
    $handler = $handler
        ? Proxy::wrapStreaming($handler, new StreamHandler())
        : new StreamHandler();
} elseif (!$handler) {
    throw new \RuntimeException('GuzzleHttp requires cURL, the '
        . 'allow_url_fopen ini setting, or a custom HTTP handler.');
}

We cannot influence this behavior and your request would be better directed at the Guzzle developers directly.
We are keeping a close eye on all Guzzle related issues and hope to be able to resolve all of them at some point.
But for now, there is not much we can do about this in particular, so I will go ahead and close the thread.

Kind regards,
Niklas