Feedback to: Textpattern CMS 4.8.1 Released

Bloke · 2020-07-03 18:49:26

DragonBard wrote #324250:

It flips back to the last form viewed in the other theme, then when I click on the form I wanted, it again flips back to the last version viewed in the other theme.

Yes, it goes back to the last saved form in any theme. Not the last viewed form. We don’t track views.

I’d prefer for the view to stay locked to the selected theme in the Theme drop down.

It will (should!) if you save a form first:

Visit Theme A and look at the form you want to compare.
CTRL/CMD-S.
Flip theme. The form loaded will be the same one you just saved (assuming it exists in the target theme you just flipped to, otherwise it’ll show the first Form in the list and set that as your new base).

If it’s not doing that, then you may have some aggressive caching going on.

Bloke · 2020-07-03 18:54:25

DragonBard wrote #324248:

For example, I was on Empty theme, looking at the article default form. Then I clicked on the Comments comments form, and instead of seeing the Empty version, I now see the Default theme version.

That’s definitely not right. The theme should stick.

Just try this to humour me please:

Open your web browser’s Inspector.
Browse to its Network panel.
Check the ‘Disable Cache’ option.
Now navigate your Forms. Does it behave more logically, staying on the theme you were last using when clicking around the forms within it?
Enable the cache again, and close the inspector.
Navigate your forms this time. Does the behaviour change from when you had the cache disabled? If so, there’s something in your server setup that’s getting in the way of Txp’s normal operation and we need to figure out what.

DragonBard · 2020-07-03 21:01:44

Bloke wrote #324252:

Just try this to humour me please:

Open your web browser’s Inspector.

Browse to its Network panel.

Check the ‘Disable Cache’ option.

Now navigate your Forms. Does it behave more logically, staying on the theme you were last using when clicking around the forms within it?

Enable the cache again, and close the inspector.

Navigate your forms this time. Does the behaviour change from when you had the cache disabled? If so, there’s something in your server setup that’s getting in the way of Txp’s normal operation and we need to figure out what.

Disabling the cache on the network panel behaves as I expect. Re-enabling it and I get the weird flipping behaviour again. I’m hosted on DreamHost. I take it I should post the diagnostics. Detail Low or High?

Last edited by DragonBard (2020-07-03 21:03:23)

DragonBard · 2020-07-03 21:30:11

Solved the mystery. I was running the site under PHP 7.3.12 w/Fast CGI. Switched to PHP 7.3.12 CGI and the weird flip flopping with editing Forms went away. Is Textpattern not Fast CGI compatible? It’s fine with me, just good to know that was what was causing the weirdness.

Thanks!

Bloke · 2020-07-03 21:51:25

Glad you got it sorted.

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.

You are, however, the second person in as many weeks mentioning weird cache issues on Dreamhost. I wonder if they have some particular settings in their FastCGI implementation that aggressively caches things and causes odd behaviour in Textpattern.

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.

DragonBard · 2020-07-03 22:28:01

Bloke wrote #324257:

Glad you got it sorted.

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.

You are, however, the second person in as many weeks mentioning weird cache issues on Dreamhost. I wonder if they have some particular settings in their FastCGI implementation that aggressively caches things and causes odd behaviour in Textpattern.

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.

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

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.

Textpattern CMS

Textpattern CMS support forum

#25 2020-07-03 18:49:26

Re: Feedback to: Textpattern CMS 4.8.1 Released

DragonBard wrote #324250:

#26 2020-07-03 18:54:25

Re: Feedback to: Textpattern CMS 4.8.1 Released

DragonBard wrote #324248:

#27 2020-07-03 21:01:44

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324252:

#28 2020-07-03 21:30:11

Re: Feedback to: Textpattern CMS 4.8.1 Released

#29 2020-07-03 21:51:25

Re: Feedback to: Textpattern CMS 4.8.1 Released

#30 2020-07-03 22:28:01

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324257:

#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:

Board footer