Add support for WP_Http class

[raamdev]

Currently the HTML Compressor requires cURL. It would be nice to fall back on the WP_Http class in those cases where the HTML Compressor is being used within a WordPress environment (as is the case for the Quick Cache plugin; see wpsharks/comet-cache#156).

[jaswrks]

I'm working on this together as part of my work on #16

[jaswrks]

This may not be possible. See comments here: 2330f51

[jaswrks]

http://www.php.net/manual/en/language.oop5.decon.php

[jaswrks]

This was implemented in v140520 of the HTML Compressor. However, it's not working with Quick Cache yet, since it runs in the shutdown phase and most objects have been destructed at this point. I'm going to leave this open until a proper workaround can be established.

In summary, support for WP_Http made it into 140520, but it's disabled internally until we get this working with plugins like Quick Cache. Until then, cURL is there to provide the needed functionality.

[raamdev]

Understood. Thanks!

[raamdev]

Hmm, just thinking about this a little more. Does this mean using WP_Http is a no-go here, or is there a workaround you have in mind?

I'm just wondering if I should open a new Quick Cache issue to track this or if I should abandon the idea and just work with the cURL detection and notice on the UI panel.

[jaswrks]

a workaround you have in mind

I'm thinking that WP_Http might be a no-go here. However, what we could do is add support for FOPEN streams when cURL is not available. This is what WP_Http does anyway. Of course it goes a bit further than that, but really the most common transports are either cURL or FOPEN. So if we support both of those, we'll already be very close to what WP_Http does.

Another slight possibility (still researching this), is that we might be able to hold an object reference to WP_Http open so that we force it to remain available in the shutdown phase. I'm not sure if I like that option yet. It just seems to work against what the shutdown phase is all about.

[raamdev]

Got it. Thanks. Falling back to FOPEN would be great if the WP_Http route doesn't make sense. I'll just leave this open for you and won't open a Quick Cache issue until you've come to some conclusion here. :)

[jaswrks]

FOPEN as a fallback transport layer has been implemented.
@raamdev You can do a git pull from Quick Cache if you like.
https://github.com/websharks/html-compressor/releases/tag/140816