Replace file_get_contents($url) for better network support #1510

file_get_contents() can be, and often is, restricted by hosts. This leads to odd behaviour in Textpattern where, for example, the 'check for updates' continually reports as "failed" when in reality it's that core is restricted from making the type of request we tried.

Introduce a succinct Http/Curl wrapper in our library. I took a look around, but all the ones out there, while fully featured, are super bloaty for our needs.

shuber/curl was the minimalest approach I could find. We could probably rip some or all of that for our own purposes. But with my Object Oriented hat on, I kind of think we should adopt the 'Adapter' model, e.g. have an Http/Client class that accepts an Adapter to communicate over Sockets, Curl, or plain file_get/put_contents().

Perhaps when we construct a client it automagically tries:

• file_get_contents() as an adapter first if allow_url_fopen is on.
• Curl if(in_array ('curl', get_loaded_extensions()) is available.
• File sockets otherwise.

That means instead of file_get_contents($some_file_or_url) in core, we'd use something like:

Txp::get('\Textpattern\Http\Client')->get($some_file_or_url);

And it would then pick the most appropriate communication method based on what was available/compiled, and the nature of the file/URL being requested (i.e. files always get file_get_contents() but anything networky chooses the best method). Bonus points: a setAdapter(\Textpattern\Http\Adapter\Some-adapter) method would allow someone to override it or provide their own transport mechanism (e.g. FTP, File, local Test, ...). Plus we could expose a few configuration methods to set transport parameters, SSL stuff, yahde yahde if needed.

It's similar to the approach that Zend (now Laminas) have taken, but man their implementation has every bell and whistle imaginable. Full exception stacks, ability to set every individual parameter through hundreds of methods in almost half a MB of code, plus extra support libraries and URL objects, the list goes on. Yes, it's the "right" way to do it but sooooo overkill for what we need it for.

I'd rather start small with the correct methodologies and expand as and when we need anything extra.

Alternatively, we could just introduce a single, direct Http/Curl class and then anywhere we need to fetch any network-related content, do the detection in the calling environment and choose between file_get_contents() or Http/Curl at that point.

Any preferences or thoughts anybody?