Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#41 2020-07-04 22:09:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,612
Website

Re: Feedback to: Textpattern CMS 4.8.1 Released

bici wrote #324290:

Diagnostics
Pre-flight check
All checks passed.
allow_url_fopen On On

Excellent! That means this pesky issue is definitely related to allow_url_fopen(). No idea why I didn’t spot that before, it’s kind of obvious now I look at it with this fresh perspective, thank you for the confirmation.

/BEGIN TECH SPEAK

What we could do with is a nice, succinct Http/Curl wrapper in our library. I took a look around today 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. 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. I’m comfy having a go at coding this one day, but if anyone wants to jump start the process of distilling the above down into usable class(es), please be my guest.

/END TECH SPEAK

EDIT: issue opened to track this

Last edited by Bloke (2020-07-05 10:34:46)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB