persistent cache problem in admin

[Draxeiro]

Hi people,

Ran into an interesting problem earlier today, one that I am quite sure is not caused by Get Simple but to cover all bases I am running it by you nonetheless.

Did an install of GS, everything went by without any problem. Until I created some new pages and tried uploading some photo's. Nothing seemed to happen. Until I refreshed the page, that is.

To make a long story (and a lot of testing and clicking about) short: whatever change is made in the admin, be it a new page, changes on a page, uploading images, switching templates, etc. No change is shown unless you refresh the page!

Tried it on multiple browsers, on multiple computers, everywhere the same story.

I have installed GS quite a few times, at different hosting companies, never something like this.

So I gave this particular hosting company a call about it. But they are adamant that it is caused by the CMS in question, not the server settings or anything like that.

Looking at my experience with installs on other hosts (never so much anything resembling this), I am more inclined to think THEY are the problem.

Can anybody shed some light on this? Is there a way around this, or would it be best for this client to switch hosts?

[shawn_a]

What do you mean no change is made ?

Are you saying that your actions on the admin side are not submitting or refreshing the page when you perfrom them ?

Some of these are ajax calls, maybe your webbrowser has some javascript error.

Can you walk us through an exact example of what you mean ?

What browser are you using? Some browsers have xss attack filters that cause your pages to not load.
See my xssoff plugin for details.

Either way always check your javascript console, it will tell you these things to help troubleshoot.

[Draxeiro]

What do you mean no change is made ?

Are you saying that your actions on the admin side are not submitting or refreshing the page when you perfrom them ?

Some of these are ajax calls, maybe your webbrowser has some javascript error.

Can you walk us through an exact example of what you mean ?

What browser are you using? Some browsers have xss attack filters that cause your pages to not load.
See my xssoff plugin for details.

Either way always check your javascript console, it will tell you these things to help troubleshoot.

It's rather a matter that no change is SHOWN without first refreshing the page.

The actions are submitting, in that respect everthing is working fine. But they aren't shown until you hit refresh and then they show.

Don't think it is a javascript problem in the browser, as this problem only shows on this install at this particular provider. Other GS installs of live sites at other providers work perfectly and do not show anything like this.

To walk you through an exact example of what I mean:

Create new page, fill in all the appropiate fields, enter some text and hit save. Then click 'view all pages' to return to the pagemanagement screen. New page is not shown. Hit refresh, new page shows up in the list.

At that same note: change the page order, hit save, page management screen does not show the change. Hit refresh: there it is.

Same goes for any action in the admin, change text in a page, save, leave the page, go back to it. Old text still there, hit refresh: change is shown.

Also goes for uploading files, switching templates, switching plugins on and off and what have you. For any change made the page needs to be refreshed for it to be shown.

But only at this provider, mind you.

Therefore it would seem to be a provider problem as opposed to something to do with GS.

Tried it on Firefox, IE and Chrome.

Hope you can shed some light on this, so that I know if it would be better to have them change hosting providers or not.

[shawn_a]

I would still check the javascript console, has nothing to do with javascript. The browser reports all issues there including xss filters. Also you cold get different errors on different sites on different host or the same, it all depends on whether that is triggering a filter or not, also there are server security filters that catch stuff also.

So I would start by checking javasript console in chrome for example.

If no errors, then check the network tab ( in chrome development for eg) to make sure your browser isn't caching everything. Which it could do if your timezones are set wrong on your install or some other header issue not sending the proper cache headers.

Then check your servers log files, to see if the request is hitting your access logs or if there is some mod security error in the error log.

[Draxeiro]

Hi Shawn,

First of all thanks for your help.

Switched on the javascript console in Chrome.

By the looks of it there aren't any noticable warnings/errors/or what have you, clicked on the console tab on the right, went through some actions in the admin: nothing (unless I am wrongly going about my business in the console of course).

In the network tab I do see some caching going on. But not too sure what to look at exactly. Compared it to properly functioning GS site at another provider and do not see any real difference. So I don't think it is caching everything.

Timezones are set correctly on my install in any case.

Downloaded a logfile but that only seems to show the accessed files, the time they were accessed and from which ip. Not really an eye opener either.

No error log to be found.

But to get things clear: is this caused by something to do with GS or is this most likely caused by a provider setting/security measure/whatever else?

For me the odd thing is that A. this doesn't show up on any other installs and B. things basically work as they should, EXCEPT for showing the changes as they should without that refresh.

The client is willing to move to another provider if it can't be solved. So if there's no way to solve this at this host a move would seem most wise.

[shawn_a]

I really have no idea, I have never heard of this.

Its either local caching in your browser , caching on the server, or your client is blocking responses.

You goto a page, change some stuff and watch the inspector when you click submit or whatever and see what the headers and response is from the server.

If you are saying that it works fine on the same host for another install, then I would suspect something with your GS install. I would almost bet its a xss injection security filter somewhere.

Also there is a gs log in data/logs/ or data/other/logs something like that.

Also check health check, also try turning debug mode on.

Also what plugins are installed ?

[Draxeiro]

That makes two of us....

Local caching in my browser I highly doubt, since then the problem would also rear its ugly head on other GS installs I tested. Only on this install at this host.

Furthermore I tried it with multiple browsers: all give the same problem.

Caching on the server would seem most likely, although the host denies this. Is there any way to check?

Not sure what you mean with my client blocking responses however....

If I change stuff in a page and watch the inspector I see some GET commands roll by, is that what you mean? Or am I looking at the wrong inspector?

By the way, I didn't say it works fine on the same host for another install. I said it works fine on other installs on various other hosts.

Checked the GS logs, nothing strange in there.

Healthcheck has all lights green. Debug mode doesn't show any message whatsoever.

With regards to the plugin, tried it both with all plugin switched off and on. No difference. Here's the plugin list in any case: Google Analytics, Imagizer, Send Anonymous Data, Custom Title, I18N Base,I18N Custom Fields and I18N.

However I use this plugin combo more often, without any problem whatsoever, so I cannot image that being the culprit either.

Now you are much more of a specialist than me (I am a graphic designer by trade), so you will have more of an educated guess here. But personally I cannot fathom what would be the cause within GS. I guess something is conflicting with a security filter or what have you.

The oddest thing is that apart from having to refresh literally everything in the admin functionality is fine.

[Draxeiro]

Truth be told I think a switch to another hosting company would probably be the wisest move, agreed?

[mvlcek]

Maybe Apache is configured to send cache-Headers for php files.
Did you look at the headers sent from the server (e.g. via firefox plugin livehttpheaders or the network tab of firebug)?

[shawn_a]

Well I just lost my response cause this forum sucks and keeps asking dumb spam questions over an over.

[Draxeiro]

Maybe Apache is configured to send cache-Headers for php files.
Did you look at the headers sent from the server (e.g. via firefox plugin livehttpheaders or the network tab of firebug)?

Installed that addon earlier this morning and took a look. Problem is that I am not entirely sure what to look for.

So I scanned for mentions of cache and ran into this when I changed a bit of text, left the page, and went back to it:

Code:

If-Modified-Since: Fri, 27 Jul 2012 05:41:43 GMT
If-None-Match: "4315d34-f98-4c5c92abd73da"
Cache-Control: max-age=0

HTTP/1.1 304 Not Modified
Date: Sat, 28 Jul 2012 07:41:26 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=5, max=98
Etag: "4315d34-f98-4c5c92abd73da"
Expires: Sun, 29 Jul 2012 07:41:26 GMT
Cache-Control: max-age=86400

Probably totally standard, but I did wonder when I saw cache-control: max-age=86400

But if mvlcek is right in that Apache is configured to send cache-Headers for php files, then basically the only party who can solve this is the provider, right?

By the way, if somebody wants to take a look you're more than welcome to, it's a test install in a sub folder so I can PM login details without any probs.

However, since the client doesn't mind moving provider I think that probably is the easiest solution in the end.

[mvlcek]

So I scanned for mentions of cache and ran into this when I changed a bit of text, left the page, and went back to it:

Code:

...
HTTP/1.1 304 Not Modified
...
Expires: Sun, 29 Jul 2012 07:41:26 GMT
Cache-Control: max-age=86400

You should never get one of the above response headers with a PHP file.

Possible reasons:

• You might have some some cache statements in your .htaccess file -> delete them
  
• You use a fancy URL ending in .htm or .html, causing apache to cache by default -> you can probably overwrite this in your .htaccess
  
• Your provider uses weird default cache settings -> you can probably overwrite this in your .htaccess
  

Try adding the following to the beginning of your .htaccess to prevent caching:

Code:

<FilesMatch "\.(php|html|html)$">
        ExpiresDefault A0
        Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform"
        Header set Pragma "no-cache"
    </FilesMatch>

(copied from http://blog.splash.de/2010/01/29/cache-k...-htaccess/)

[Draxeiro]

You should never get one of the above response headers with a PHP file.

Possible reasons:

• You might have some some cache statements in your .htaccess file -> delete them
  
• You use a fancy URL ending in .htm or .html, causing apache to cache by default -> you can probably overwrite this in your .htaccess
  
• Your provider uses weird default cache settings -> you can probably overwrite this in your .htaccess
  

Try adding the following to the beginning of your .htaccess to prevent caching:

Code:

<FilesMatch "\.(php|html|html)$">
        ExpiresDefault A0
        Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform"
        Header set Pragma "no-cache"
    </FilesMatch>

(copied from http://blog.splash.de/2010/01/29/cache-k...-htaccess/)

Did some checking, lets see:

• no cache statements in the .htaccess file.
  
• also no fancy url ending in the fancy urls (just the standard setting, ie. fancy urls switched on)
  
• must be something like this
  

Tried adding the code you suggested, but makes no difference, changes are not shown without first hitting refresh. Mind you, this goes for everything, change the navigation order, save. First a refresh needed to see the change. Delete a page, first a refresh needed, switch off plugin, first a refresh needed. The only action that does not need a refresh is when a file is deleted via the files tab. That does show immediately.

When I had this provider on the phone they said the standard line 'this is not caused by us but your CMS system is causing it', ie. the easy way out.

The fact that this never happens at any other provider nor is a known problem they didn't have an explanation for.

[shawn_a]

What browsers have you tried this site in ?
It certainly is bizarre.

[Draxeiro]

What browsers have you tried this site in ?
It certainly is bizarre.

Lets see: Firefox, IE9, Chrome and Opera. At first I thougt 'its probably firefox' infamous cache' but then the problem only showed on this install. Other GS installs (at other providers) were fine.

But then it turns out to behave the same way on all browsers, and on multiple computers.
So yes, bizarre is indeed the word, I guess something in the GS admin doesn't see eye to eye with their particular apache setup.

[shawn_a]

Too bad you can't see your whole apache conf.

[Draxeiro]

Went through their control panel and took a look in the FTP folders, nothing to be found sadly.

Unless the client doesn't mind constantly refreshing the page I think the only option at this point will probably be to move to another host.