Looks good to me.

thanks @mbabker
we don't need a tracker you can use this here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29475

Also i think we can close this: #1500 if favor of this one.

Wow, 1 hour between PR and merge without tests and without chance of discussion ?

What's going on here ? Why are Joomla QA processes not followed here ?

Are PLT members above the processes they impose on the community, or are they not also members of the community ?

Don't want to not say Thank You for all your hard work, but this is a rush-in:

This will silently break webservices (right now they break but there is a warning message that allows to fix the server config or change hoster).

Additionallly there are valid workarounds to implement at same time than silencing this warning:

1) http://edmondscommerce.github.io/curl/php-curl-curlopt_followlocation-and-open_basedir-or-safe-mode.html
2) http://www.php.net/manual/en/function.curl-setopt.php#102121

See discussions on Drupal and OwnCloud threads:
https://drupal.org/node/1699868
owncloud/core#1916

Any thoughts ?

Without creating functions to mock what this single option does, this is a
good enough solution IMO. To me, this PR isn't "silencing an error", but
rather properly checking a server configuration and disallowing code to
execute if the configuration will cause a warning and prevent the expected
result.

If you would like to propose an alternate solution, please do so. The fix
provided is one I've been using in a forked version of this class which is
shipped with a module interfacing with the Twitter API and I've not
experienced issues with it.

As to your process concerns, not a decision I made and I'm not getting into
that discussion at this time.

On Tuesday, April 29, 2014, beat notifications@github.com wrote:

Wow, 1 hour between PR and merge without tests and without chance of
discussion ?

What's going on here ? Why are Joomla QA processes not followed here ?

Are PLT members above the processes they impose on the community, or are
they not also members of the community ?

Don't want to not say Thank You for all your hard work, but this is a
rush-in:

This will silently break webservices (right now they break but there is a
warning message that allows to fix the server config or change hoster).

Additionallly there are valid workarounds to implement at same time than
silencing this warning:

1)
http://edmondscommerce.github.io/curl/php-curl-curlopt_followlocation-and-open_basedir-or-safe-mode.html
2) http://www.php.net/manual/en/function.curl-setopt.php#102121

See discussions on Drupal and OwnCloud threads:
https://drupal.org/node/1699868
owncloud/core#1916 owncloud/core#1916

Any thoughts ?

—
Reply to this email directly or view it on GitHub#3534 (comment)
.

Thanks Michael :-) Obviously, you followed the process by doing a normal PR. :-)

You have no issues with Twitter API today. But e.g. in 6 months from now Twitter does a redirect and your applications suddenly fails while it shouldn't fail. Most webservices change their URLs over time, and most do use redirects to keep the web ticking.

Now without such a warning, go guessing why a service doesn't work. It's an useful error message showing an incompatible server config.

Imho, the proper fix is to follow urls with alternate methods like the 2 I linked to at same time than fixing this warning. But it requires testing and can't be rushed into a release same day as packages are built.

@beat I would recommend following up with code of your own if you propose a more thorough solution. :) This works well for the current situation. Other solutions may exist, and your PR's are welcome.

@dbhurley Sure thing, but sure not in a release-day rush, and sure not without following processes in place !

I would expect nothing else. I'll watch for your PR.