Warning: curl_exec() has been disabled for security reasons

[Ipstenu]

Some installs now use cURL when they didn't before following 4.6

​https://wordpress.org/support/topic/warning-curl_exec-has-been-disabled-for-security-reasons?replies=13

As Otto said:

Additionally, the new Requests_Transport_cURL class does indeed check for function_exists('curl_exec') before attempting to use it, so it seems likely that your host is using suhosin or some other means of disabling functions which doesn't cause PHP to properly report that function as disabled.

Also some Jetpack folks have reported it and it doesn't seem that they rolled back.

I don't know if there's a better check we can do for this.

[pross]

Maybe after a function_exists() it should try a curl_init() and check the response to make sure it will actually work. Just a thought.

[dd32]

Looks like there's a logic slip in Requests where it only bails from using cURL if BOTH curl_init() AND curl_exec() are unavailable. WordPress previously bailed when EITHER were unavailable.

Created a PR upstream: ​https://github.com/rmccue/Requests/pull/230

[Otto42]

Filter looks okay for back-compat.

[dd32]

In 38274:

Requests: Update to Requests master (fb5b517) which corrects a logic inversion in the cURL transport checks.

Previously if a host had only disabled one of curl_init() or curl_exec() it wouldn't get detected correctly by Requests, which caused cURL warnings for users on an affecte dhost.

Fixes #37700 for trunk.

[dd32]

Re-opening for 4.6 merging.

[SergeyBiryukov]

#37715 was marked as a duplicate.

[Whitegoodshelp]

I also had an issue with 4.6 update stopping Akismet from working and removing curl_exec from my php.ini file fixed the problem.

However, my tech support at my hosting company looked into this for me and successfully re-disabled curl_exec without the Wordpress issue recurring by simply adding the disable function curl_exec to all the php.ini files on the server. It seems Wordpress wasn't looking at the php.ini file I edited and looked at a different one.

Here's what they said in case it helps -

"I believe that due to the different php.ini files in use on the server, exactly where the call is being made by
WordPress has caused confusion. The /etc/php.ini file is the global PHP settings on the server. The php.ini files in the /opt/plesk/php/ directories are the php.ini files for each specific version of PHP that Plesk uses. The php.ini file in the document root is the WordPress specific php.ini file. It looks as though WordPress checks the global php.ini settings and not just its own specific php.ini settings for this check."

Andy

[Ipstenu]

Andy, that's not actually how PHP works. WordPress doesn't know the difference, it just knows what PHP tells it. You can check by making a phpinfo file, and see what that reports. It will be the same as what WP sees.

You may need to tell your host "WordPress is just a PHP app, so if PHP is reporting back the wrong information, then this is more likely due to a server configuration not prioritizing my local php.ini, or that my local php.ini is actually not correct. PHP isn't THAT smart :) "

[Whitegoodshelp]

Thanks Ipstenu. That makes sense. It's just that each time I added curl_exec to the disable functions in php.ini (via Plesk) Akismet stopped working and couldn't connect to its server, but when my tech support said they added it also to the 2 other php.ini files the issue was resolved which is why I thought the experience might help someone else in the same position. It remains a mystery but it fixed my issue with updating to 4.6 :)

[adam1920]

This is the solution!
In file wp-includes/Requests/Transport/cURL.php
change row 527

if (!function_exists('curl_init') && !function_exists('curl_exec')) {

to

if (!function_exists('curl_init') || !function_exists('curl_exec')) {

[swissspidy]

In 38338:

Requests: Update to Requests master (fb5b517) which corrects a logic inversion in the cURL transport checks.

Previously if a host had only disabled one of curl_init() or curl_exec() it wouldn't get detected correctly by Requests, which caused cURL warnings for users on an affected host.

Merge of [38274] to the 4.6 branch.

Fixes #37700.