Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,154
Website

Trouble with page caching and article / forms saving

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:

  1. 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.
  2. 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.
  3. 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?


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#2 2020-06-19 07:29:45

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,433
Website GitHub

Re: Trouble with page caching and article / forms saving

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)


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

#3 2020-06-19 07:44:26

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,154
Website

Re: Trouble with page caching and article / forms saving

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.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#4 2020-06-19 08:01:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,433
Website GitHub

Re: Trouble with page caching and article / forms saving

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.


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

#5 2020-06-20 02:32:45

kuopassa
Plugin Author
From: Porvoo, Finland
Registered: 2008-12-03
Posts: 236
Website

Re: Trouble with page caching and article / forms saving

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.

Offline

#6 2020-06-20 03:27:47

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,154
Website

Re: Trouble with page caching and article / forms saving

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.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#7 2020-06-21 02:19:22

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,154
Website

Re: Trouble with page caching and article / forms saving

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 ?


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#8 2020-07-03 22:26:17

DragonBard
Member
Registered: 2014-07-01
Posts: 16

Re: Trouble with page caching and article / forms saving

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?

Offline

Board footer

Powered by FluxBB