Trouble with page caching and article / forms saving

phiw13 · 2020-06-19 06:57:04

Server: Apache, PHP 7.3, MySql 5.7
Host: Dreamhost
browser(s): Safari 13.1 and Firefox (latest release and beta)
TXP 4.8.1

Issue description:

the content of textarea(s) on Pages/Forms and Write tab (I mostly tested on those 3 panes) is apparently saved when pressing the button or using the keyboard shortcut. The message pane shows it green face. Your updated content is there right in front of you.
Now, after performing the above, navigate to any other pane and do “something”. Next, go back to the pane you just saved your ‘important input‘™. Gone. Or so it seems.
Log out and close the tab – after a short while, log back in (same browser). Magic! Your ‘important input‘™ appears where it should.

The issue seems to be that both browsers cache the state of the page when first loading and don’t refresh it during the session. I have verified that the content is effectively saved to the DB and is available for use by the front-end, it is just that the change is not displayed in on the back-end side. Running in debug mode or with the browser console open didn’t tell me anything.

It only affects the content of a textarea, I think. Possibly affected is the multi-edit widget on the list panels (same issue: input/action is registered but not reflected when revising the pane), but I am not 100% sure about that one; my blood pressure was already going freaky like it was.

I have tested with the barebones htaccess file that TXP needs (removing all my further CSP/gzipping/etc optimisations). It seems new with TXP 4.8.1, although I skipped 4.8 on those sites.

Particularly annoying is the Write panel (I mostly use BBEdit to edit the page and forms files and then use update theme from disk).

Question(s) – has anybody seen a similar behaviour? Can “something” be blamed on the host – and what would that “something” be? Is there a workaround, setting no-cache headers inside the textpattern directory?

Bloke · 2020-06-19 07:29:45

Hmmm. I can’t repeat this on 4.7.x or 4.8.x on my server but it certainly sounds plausible. As to what’s causing it, I’m not entirely sure. Maybe it doesn’t cache Ajax responses, only full page reloads? That sounds the most likely avenue since almost all panels now commit their content via Ajax.

When you say in step 2, “go back” do you mean via the Back button or from the Txp menu? Not that it makes a difference in my tests, I still see the new content I added, I’m just curious. Hopefully somebody can come up with an .htaccess rule that’ll prevent caching to fix this because it sounds frustrating.

Sorry I can’t be of an help beyond providing a possible resource to explore.

Last edited by Bloke (2020-06-19 07:30:10)

phiw13 · 2020-06-19 07:44:26

Bloke wrote #323841:

Hmmm. I can’t repeat this on 4.7.x or 4.8.x on my server but it certainly sounds plausible. As to what’s causing it, I’m not entirely sure. Maybe it doesn’t cache Ajax responses, only full page reloads? That sounds the most likely avenue since almost all panels now commit their content via Ajax.

Yeah, locally it all works perfectly and my wife’s site works fine, but that is still using 4.7.latest and a different host. I suspect something with AJAX and browsers caching routines, but I am mostly out of dept here.

When you say in step 2, “go back” do you mean via the Back button or from the Txp menu?

Via the TXP menu. For the forms panel, when I first started it opened with form_abcd selected, I edited form_xyz, saved and then went somewhere else. Going back to the forms panel, form_abcd was selected (unexpected) and form_xyz showed the unedited state.

The input[type=text] fields are not affected ( I can create a new form, and name it while leaving the textarea blank, that works fine, going back, the form is there).

Sorry I can’t be of an help beyond providing a possible resource to explore.

Will have a look at that over the WE. Meanwhile, any suggestion for some .htaccess incantations would be nice.

Bloke · 2020-06-19 08:01:31

Yeah that Forms thing is definitely unexpected. It’s meant to remember the last edited one and show it.

It’d be interesting to know what headers the browser returns on Ajax saves vs regular page reloads. The inspector’s Network panel might help but I’ve not used Safari’s. Firefox’s should be helpful.

What’s intriguing though is that only texrareas are affected. Well, that and actual saves such as the Forms panel which reverts the entire panel – Name (and Type?) fields included.

Definitely sounds servery, but if this phenomenon is fairly widespread on some hosts such as Dreamhost and it transpires there’s something we can do in core to help, then we’ll do what it takes.

kuopassa · 2020-06-20 02:32:45

I have the same problem with some Textpattern installations of different versions. A temporary fix is to keep the browser’s Inspector/Chrome DevTools open with “Disable cache” checked in the Network tab.

phiw13 · 2020-06-20 03:27:47

kuopassa wrote #323854:

I have the same problem with some Textpattern installations of different versions.

hmm. so not really a new issue.

A temporary fix is to keep the browser’s Inspector/Chrome DevTools open with “Disable cache” checked in the Network tab.

That’s an idea… It probably would work with Safari and Firefox as well, both have similar settings. Gonna test that soonish.

phiw13 · 2020-06-21 02:19:22

So temporarily disabling caching through the browsers developper tools does indeed seems to be a workaround – for desktop browsers. Tested with both Safari and Firefox. I did not notice any significant performance loss, although that is not easy to fully quantify. For someone using a tablet or a small device (phone and the like) it is still problematic. I don’t think any browser on iOS or Android offer the equivalent.

Thanks Petri for the workaround.

@ Stef,
Do you think “something” could eventually be done inside the core code ?

DragonBard · 2020-07-03 22:26:17

I’m also on DreamHost and was seeing similar issues that a refresh of the browser window seemed to clear up. Then I saw some other weirdness on the back end that I finally figured out only occurred when using FastCGI. Disabling FastCGI made the weirdness go away. Perhaps check and see if you have FastCGI turned on on DreamHost?

Textpattern CMS

Textpattern CMS support forum

#1 2020-06-19 06:57:04