The platform is not dependent on curl, so factually it's incorrect that update checks don't work when curl is not available as there are other ways the API tries to work.

Our API does not go in depth checking the disabled functions directive for every possible function in an adapter, and I don't believe we should be adding this.

We can and should improve the error message shown in the UI where practical, but I don't believe we should be adding checks for disabled functions here (otherwise that opens a can of worms and it conceivably needs to be done everywhere we have isSupported() type checks and that soon trickles down to checking every native PHP function.

Hm, I created the title based on the message "Warning: curl_exec() has been disabled...". I also checked for fopen, which was enabled.

Unfortunately I cannot contribute any technical solutions, only information about the - in my eyes strangely configured host system. Please let me know if I can provide anything here before the provider changes the settings.

@mbabker disabling curl for pseudo-security reasons is actually a well known pattern that i saw at many different hosts, I would say it’s worth the the extra check

If we're going to make it a habit of checking disabled functions then realistically every isSupported check needs to scan every function that might be used by an adapter (HTTP transports, cache mechanisms, session handlers, database drivers, etc.). I don't think one off exceptions in one code path is a good idea personally.

If we start checking curl_exec(), what happens if you've got a questionable sysadmin that disables curl_init() instead? We're already having to work around this because someone thought it was a good idea to disable parse_ini_file().

I haven't heard anyone complaining about mysqli_connect being disabled for security reasons, for curl however this is a real world issue.

I get your point, it's an exception - but a worthy in my opionion.

Not saying it's not a real world issue, but I don't think just coming back in and monkey patching core every time there is a "I can't do this because a function was added to the disable_functions INI directive" issue report is right either.

Either across the board we make it a best practice to check this directive any place we have an API that checks if an adapter can be used in the environment and consistently do it with everything (and I really do mean everything because, like I pointed out, we can monkey patch checking curl_exec() but when someone disables curl_init() or curl_setopt() you're in just as much trouble) or we don't do it at all and leave this type of check to a system dashboard in com_admin (which I personally think is the way to go about it, the production code should not be littered full of ini_get('disable_functions') calls).

leave this type of check to a system dashboard in com_admin

You mean to display an information to the user saying "hey, your stupid host disabled curl, Joomla can't connect to the outside world"? Well, but how does it help the end user? His host most likely won't change his mind, so the user-friendly alternative would be, that JHttp just changes over to a supported driver and that let's us end up with ini_get calls again.

Alternative: add a helper function doing function_exists && is_callable && !in_array(explode(ini_get(...)))?

option=com_admin&view=healthcheck

Add sane things here:

• Is an HTTP adapter available for use?
  • No? Why not? Guide user somewhere...
• Is a cache adapter available for use?
• Is caching enabled?
  • No? Educate user why this may be beneficial...

Alternative: add a helper function doing function_exists && is_callable && !in_array(explode(ini_get(...)))?

You can't make a Joomla\CMS\Environment::willThisActuallyWork() sanely because different environments call for different things (i.e. can't do extension_loaded() for Memcached in some environments and have to rely on class_exists(), clearly you can't rely on extension_loaded() for curl and have to get into this stupid disable_functions check (and it would apply to all of our HTTP adapters, not just curl, because it's more common to block or disable things like fopen() and fsockopen(), or disable allow_url_fopen or the ability to do a request through file_get_contents() than it is to turn off curl in this half-assed broken way; BTW I do all of that quite commonly).

Again, it's a real problem and I'm not denying that, but the way I see it either we start checking the disabled function list for everything in core as a best practice (which does mean the potential of "is mysqli_connect() disabled?" checks), or we're going to be in here monkey patching until we're all blue in the face because some "smart" guy decided to turn off a random function because they know no better. And frankly I treat issues like this as a server level responsibility to fix, not an application level responsibility. Even king of no technical stuff should ever be seen by the end user WordPress doesn't do this level of checking.

#ycfs if you have a nice shiny car, but take the wheels off each night so the car doesnt get stolen and then complain you cannot drive to work in the morning, thats not the car manufacturers issue...

PHP is designed to work. If you then go and disable functions in php with the ini setting disable_function then you are on your own...

You dont "secure" a PHP installation by disabling functions. If 2019... there is no reason for ANY php functions to be disabled in this way.

whats the Status of this Issue?

I guess someone has to make a decision if the problem is worth an exception or not.

thanks @SniperSister, calling @HLeithner as Release Lead.

I follow michael's way, it doesn't make sense to check every if every function of a package is available. Especially if the hoster disable the wrong function like curl_exec instead of the curl_init.

Anyway a dashboard that could check the server would make sense. The question is if there is a 3rd party lib that we can use for this.

This type of health check would have to be written specific for Joomla (most of it would be the standard component MVC structure, all you're really writing then is a series of checks to either check the Joomla config for recommended settings or the PHP config for recommended settings and enabled/disabled capabilities, and adding in plugin hooks so extensions could add their own things here similar to com_privacy capabilities).

so closing?

This type of health check would have to be written specific for Joomla (most of it would be the standard component MVC structure, all you're really writing then is a series of checks to either check the Joomla config for recommended settings or the PHP config for recommended settings and enabled/disabled capabilities, and adding in plugin hooks so extensions could add their own things here similar to com_privacy capabilities).

sounds good but have to be done ;-)

I thought a bit more in the direction, lib xy say me if curl, mysql, postgres, you name it "really" work. a typ of unit test.

Maybe I'm wrong, but I think there are 2 other ways to get the updates working. But the Transport substitudes coming not into play because of disabeling and not being aware that there is a problem. So could it be an option to disable curl in Joomla! so that the transport substitudes can take over?

@HLeithner are we looking at doing this or can this be closed? Based on what I can read it looks like the issue is something that is not advisable to apply to J3.

Still an valid issue even if no body seams to be interested to solve it or has the problem at all.