Page Safe and PHP

If it’s truly a browser cache issue, why does it work with earlier versions of PHP?

Also why does it work on other hosting companies?

You can also set up an htaccess rule that wouldn’t allow the login page to be cached by the browser. For example this will not allow the browsers to cache any html, JavaScript or PHP file.

<filesMatch "\.(html|htm|js|php)$">
  FileETag None
  <ifModule mod_headers.c>
     Header unset ETag
     Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
     Header set Pragma "no-cache"
     Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
  </ifModule>
</filesMatch>

Yes, that’s all very strange. With one site, this effect only appears with Safari. All other browsers working just fine…

I do not think that it is the browser caching the page. It’s the server. Or more likely a cache proxy that sits in front of the server.

But why does that page I’ve mentioned not work in Safari but in each and every other browser? If it would be s.th. on the server the login would also not work with Firefox and Chrome. But it does…

Not sure if I understand what you’re saying you think is happening.

Servers like Apache to my knowledge don’t proxy anything, what would be the point, they’re the starting point for the page.

If it’s a separate “proxy server” then how does it only appear when the PHP version is changed?

I don’t understand any of this. I’m not really a developer, I’m a novelist. My husband wanted specific things for his website so I picked up Rapidweaver because it used to be fairly WYSIWYG. Also the community is usually helpful and courteous.

All I know is that Page Safe used to work really well for my husband’s webinars, for years. Now suddenly it’s not working well–maybe it’s Site Ground’s fault–and I’m getting upset emails from previously happy customers.

I would appreciate any help whatsoever.

~Traci

What is Siteground saying about this? PageSafe has not changed. Therefore, it must be something that they did on the server.

I think everyone is trying to help you get this fixed.

Can’t you switch it back to 7.2.34, until you get this sorted out?

When are they actually going to remove 7.2.34(”soon” is pretty vague)?

Can you set up a test subdomain with the hosting company? That way you can leave the production domain set to the 7.2.34 version that works and have a test domain that we can experiment with to figure out what is different? This would also keep the customers happy until you get things working.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.