Feedback to: Textpattern CMS 4.8.1 Released

Bloke · 2020-07-03 22:36:05

DragonBard wrote #324259:

If there is any diagnostic data you want me to collect, let me know and I am happy to provide it.

Thank you. Server stacks aren’t my forte, so I’m not entirely sure what info would be of use to find out what’s going on here.

Perhaps @gaekwad would have a view on this. Let’s see if he reads this and offers any thoughts.

Last edited by Bloke (2020-07-03 22:37:13)

phiw13 · 2020-07-03 23:27:23

I’ve just done some rather quick, basic test on Dreamhost running 7.4.3(fastCGI), the current recommend version, and the issue still seems to happen, but only intermittently, and does not seem to happen at all on one install.

(hmm, I wonder if I have any difference in the htaccess files between those two sites. gonna check later today)

bici · 2020-07-04 00:24:58

hello: just updated to 4.8.1… many thanks! it was oh so painless.
BUT why do we get this error:

“Update server inaccessible

The check for updates failed, often due to network congestion or a connection timeout. This situation usually resolves itself within an hour or two so try revisiting this panel later.”

of course it never resolves itself. ;-)

it may be an issue with opalstack hosting… or not.
OS has no issues with pinging and installing updates from EE, so not sure what the differences may be in contacting servers for info re updates.

in the meantime I’m heading off to update the rest of my websites. Again many thanks to the devs.

Bloke · 2020-07-04 01:13:15

bici wrote #324265:

Update server inaccessible

I’m willing to bet if this never clears for you that it’s a host security setting. If you dig into your php.ini or look at your PHP diagnostics from Txp’s Admin->Diagnostics panel, you’ll probably see mention of allow_url_fopen being disabled.

I’m considering adding a helper object to the upcoming 4.8.2 (if not there, definitely in 4.9.0) that will handle URL-based connections for us via cURL instead of using file_get_contents() all the time. Our use of the latter is because it’s built into PHP. It’s cheap. It’s fast. But it also has a lot of suppressed error messages around it to cater for situations when a server isn’t accessible or the call itself is blocked by the host.

The thing is, because we block errors we never find out why the connection fails. In this case specifically, if it can’t connect to textpattern.com at all due to a hosting configuration restriction, you’ll see that message all the time. It’s not really that the server is inaccessible, it’s that the hosting environment won’t let PHP contact the server in this manner.

Let me see if I can throw together a real quick test class tomorrow, we’ll plug it into your Diagnostics panel and see if the message goes away. If that’s the case, we can refine it and start to roll it out to replace our use of file_get_contents() throughout. This will greatly benefit our ability to update plugins directly from the Plugins panel in 4.9.

phiw13 · 2020-07-04 02:06:20

phiw13 wrote #324263:

I’ve just done some rather quick, basic test on Dreamhost running 7.4.3(fastCGI), the current recommend version, and the issue still seems to happen, but only intermittently, and does not seem to happen at all on one install.

here is the Dreamhost PHP config (PDF) if someone wants to dig in it.
I’ve modified the htaccess file for the site that has some issues, it is now basically the same as on the site where I don’t see caching issues (anymore). I still see some problems. no clue why. I verified also that the htaccess in /textpattern/ did not contain anything that might cause caching issues.

The htaccess file is structured to have the default Textpattern part first, then I include some caching stuff (based on h5bp) and CSP directives. the last part is site specific permanent redirects and any odd tidbit.

Sounds all very voodoo though…

gaekwad · 2020-07-04 14:49:35

Bloke wrote #324257:

Weird about FastCGI, though. I’ve not heard of anyone specifically complaining about Txp not running under it, and I’m pretty sure our demo servers run PHP-FPM.

Yup.

I’d love to find out what’s going on under the hood in such situations so we could see if there was anything we can do to stop it.

Nagging thought – we should prepare a boilerplate page/single-pager to approach hosting orgs that have finicky problems and ask for a gratis testing account: we can perhaps find a solution, they have happier customers, everyone wins.

Bloke · 2020-07-04 15:46:13

gaekwad wrote #324279:

we should prepare a boilerplate page/single-pager to approach hosting orgs that have finicky problems and ask for a gratis testing account

If they’re amenable to that, bring it on.

DragonBard · 2020-07-04 16:06:39

gaekwad wrote #324279:

Nagging thought – we should prepare a boilerplate page/single-pager to approach hosting orgs that have finicky problems and ask for a gratis testing account: we can perhaps find a solution, they have happier customers, everyone wins.

You want a testing account on DreamHost? I can give you one. I have unlimited hosting with “resell” rights. The only difference is I would be the one with the god account. I can set up a separate user for you and you would have full SSH and SFTP access. I can even provide limited access to their control panel, though that will require some coordination as I would have to set up the database first.

Last edited by DragonBard (2020-07-04 16:15:14)

bici · 2020-07-04 20:04:56

I have asked OS teach Support about this issue. Perhaps they have a valid reasons to keep allow_url_fopen off, or they may have other suggestions.

EDIT: their quick response:
Yes, just let me know the name of the application and I’ll enable that feature for you.

Such great service!

Last edited by bici (2020-07-04 20:23:21)

bici · 2020-07-04 20:58:01

Diagnostics
Pre-flight check
All checks passed.

allow_url_fopen On On

A-OK on OpalStack!

Bloke · 2020-07-04 22:09:31

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)

Textpattern CMS

Textpattern CMS support forum

#31 2020-07-03 22:36:05

Re: Feedback to: Textpattern CMS 4.8.1 Released

DragonBard wrote #324259:

#32 2020-07-03 23:27:23

Re: Feedback to: Textpattern CMS 4.8.1 Released

#33 2020-07-04 00:24:58

Re: Feedback to: Textpattern CMS 4.8.1 Released

#34 2020-07-04 01:13:15

Re: Feedback to: Textpattern CMS 4.8.1 Released

bici wrote #324265:

#35 2020-07-04 02:06:20

Re: Feedback to: Textpattern CMS 4.8.1 Released

phiw13 wrote #324263:

#36 2020-07-04 14:49:35

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324257:

#37 2020-07-04 15:46:13

Re: Feedback to: Textpattern CMS 4.8.1 Released

gaekwad wrote #324279:

#38 2020-07-04 16:06:39

Re: Feedback to: Textpattern CMS 4.8.1 Released

gaekwad wrote #324279:

#39 2020-07-04 20:04:56

Re: Feedback to: Textpattern CMS 4.8.1 Released

#40 2020-07-04 20:58:01

Re: Feedback to: Textpattern CMS 4.8.1 Released

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

Re: Feedback to: Textpattern CMS 4.8.1 Released

bici wrote #324290:

Board footer