For example, if installing the plugin from source and not having done a build, while also the curl extension is not installed, the user is shown the following admin notice:

That paragraph is a bit long. Took me a second to realize these are all different issues that need to be handled individually. Perhaps we could list them on separate lines?

And now as well there is a warning that is shown when interacting with WP-CLI

Nice!

Apart from that: I was wondering if we could somehow use the WP HTTP API with FasterImage, removing the absolute requirement for cURL.

That paragraph is a bit long. Took me a second to realize these are all different issues that need to be handled individually. Perhaps we could list them on separate lines?

@swissspidy How about like this:

Apart from that: I was wondering if we could somehow use the WP HTTP API with FasterImage, removing the absolute requirement for cURL.

I've thought about that, but the problem is FasterImage directly calls cURL. We'd need to modify FasterImage to allow plugging in a different HTTP API. And I'm pretty sure the WordPress HTTP API doesn't accommodate request parallelization (like Guzzle does).

I suppose each subsequent error line in WP-CLI should have a bullet point.

Much better already, thanks!

Since the extension list is a bit repetitive, what about something like this:

$extensions = array_map(
   function ( $ext ) {
      return "<code>{ $ext }</code>";
   },
   $extensions
);

sprintf(
  _n(
    'The following PHP extension is missing: %s. Please contact your host ...',
    'The following PHP extensions are missing: %s.Please contact your host ...',
    count( $extensions ),
    'amp'
  ),
  implode( ', ', $extensions )
);

Like so:

Looks great! 😻

Cherry-picked onto 1.1 branch: 5a9c98e

Hi,
As a web-hosting company, we have blocked curl_muli_* function to prevent compromised websites from doing ddos attacks,
As far as I checked, despite the previous versions, the new one only works with curl_muli_* functions, is it possible to consider an option so your plugin also be compatible with "curl_init" funstion as well?
Thanks alot,

@mehrdadabed Hello, I have some questions for you:

we have blocked curl_muli_* function to prevent compromised websites from doing ddos attacks

How are you blocking the function? Are you using a forked version of the cURL extension or some other means to prevent access to this function?

I was curious if this function would specifically be a problem for DDoS attacks. I was thinking that the non-blocking HTTP requests that WordPress makes normally for cron could be used in almost the same way as cURL Multi. I created a script to test, and it seems indeed that cURL multi is able to make requests at 3⨉ the rate of non-blocking cURL.

Even so, is 3⨉ is not 30⨉. So disabling cURL Multi only seems to help marginally, not on the order of magnitudes. So is it still worthwhile?

As far as I checked, despite the previous versions, the new one only works with curl_muli_* functions, is it possible to consider an option so your plugin also be compatible with "curl_init" funstion as well?

See also conversation on #1809. We dropped support for non-multi requests as we assumed that it was available in all PHP 5.4 installations. You are on PHP 5.4+ and yet have this function disabled? Is this a common practice among hosts? It's the first I've seen a report of it.

Are sites you host currently getting PHP server errors due to this function not existing?

At the very least, what we need to do here is check not only if the cURL extension is installed but also we need to check if the curl_multi_* functions exist. If both are not true, then the plugin would need to short-circuit and show an error message.

Otherwise, if this is indeed a common scenario, we may need to bring back FastImage which was removed in #1809. I'm wary of that, however, because the library is no longer being maintained, and the capabilities are different than FasterImage (e.g. SVG support).

/cc @felixarntz

@westonruter you can hopefully disabled functions with disabled_functions in php configuration. Documentation
You can found many articles which blocks this function for security reasons like this one. So it can be very common to found this function blocked.

I get error 500 with function disabled and this in log :

PHP Warning: curl_multi_exec() has been disabled for security reasons in .../amp/vendor/fasterimage/fasterimage/src/FasterImage/FasterImage.php on line 91

OK, I've opened #2319 to check for the required functions and classes in addition to the required extensions. This will at least prevent a fatal error on your server and will inform the user of what is missing. I believe the ultimate fix for you is going to be for FasterImage to support falling-back to only using curl_init() when curl_multi_init() is not available. I've opened willwashburn/fasterimage#16 toward this end.

Hi and thanks for the answer,
I do understand your concern about your script performance and speed, and certainly curl_multi functions act faster than regular "curl" ones, no doubt,
But we - as a web-hosting provider - concern about, is the number of "simultaneous connections" that could be established by a php script, as you know, it's possible to create thousands of php connections at the same time by curl_multi functions, while it's needed to wait for each connection response when regular "curl" is used, consequently monitoring/controlling outgoing connection is significantly easier in regular curl functions in compare with curl_multi ones,
So I kindly ask you to provide such option to use curl_init when curl_multi_init is disabled,
Thank you so much,
Abed.

Please follow willwashburn/fasterimage#16 the resolution.

FasterImage has been updated with the fallback support.

Merged update into AMP plugin: #2422

So this will be part of 1.1.2, perhaps released today.

@mehrdadabed Please test: #2423