Having major cache issues, need advice

Hey all.

I work for a B2B company and on our website, we are having major cache issues. Whenever we do a substantial rollout of code, particularly when the "index.php" file is modified, the end users are continually having to "reload" in order to pick up the newest changes.

Here is what I have in place.

1) The following statements at top of PHP
   B) header("Cache-Control: no-cache, must-revalidate");   // HTTP/1.1

2) All the JS / CSS links have versioning applied - <link "....file.js?vers=1"> with the "?vers=1" getting incremented.

What else can be done? I'm looking for advice on how to determine if PHP config cache or Apache cache is playing a role in this.

Any help would be greatly appreciated.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

RobOwner (Aidellio)Commented:
Are you able to identify whether it is your js/css or your index file?
Normally I append the time using PHP to my critical js and css


WebspeederAuthor Commented:
I manually do the versioning. We thought about the time, but the end result would be the same, correct?
WebspeederAuthor Commented:
Well, when they reload the "index" file, everything snaps into place. I think it is that, because of that and also I manually version the JS / CSS files.
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

RobOwner (Aidellio)Commented:
Yes that's my understanding.  When the issue happens, do all the files load ok. I.e. Network tab and console in dev tools shows no errors?

I would change the way you're serving your js/css and append the time as the difference in the cache to live is going to be greater than a certain number that you're using now.
RobOwner (Aidellio)Commented:
Did you setup caching on your apache server?
WebspeederAuthor Commented:
I am not the one to do the cache setup in apache server, but I can check to see if that is in place. How would I check that?

Also, the issue isn't the individual JS / CSS files. Once the user reloads the page, everything loads and works fine. There are no errors seen before the reload.

I didn't mention this, but am thinking of it now, we use PHP SESSION variables too. The changes made to the index.php are that the session control is manually done now so the session is destroyed in a different way.

My suspicion is that the SESSION values are to blame, but if that were the case, closing out the browser and restarting would resolve the issue, correct? But a specific reload is necessary.
WebspeederAuthor Commented:
The index.php is the "login page". On reload, the login form comes up, they login and all is good. The issue is information is being "cached" (like the SESSION info) that makes the browser "think" the user is logged in.

Reloading the page picks up the new code to remove the cached information.
RobOwner (Aidellio)Commented:
Sounds like you've got quite a few variables at play here. I'm going to sleep on it and get back to you.
As for the caching, check the directives in your httpd.conf
Ray PaseurCommented:
The symptom related to the session sounds perfectly normal to me.  This is how sessions work.  Unless you manually invalidate the session data stores, if the client sends the correct session cookie, the server will find the session data and use it.
Dave BaldwinFixer of ProblemsCommented:
If refreshing the browser page fixes the problem, then I think it is browser caching.
Ray PaseurCommented:
Refreshing the browser page may not clear the cookies.  That could (and should) be under the control of the user's settings.
Dave BaldwinFixer of ProblemsCommented:
Webspeeder said...

Reloading the page picks up the new code to remove the cached information.

And as you know, the only part of a SESSION that the browser saves is the session_id in the session cookie.
Ray PaseurCommented:
Right.  Here is one possible scenario as I understand it, and I can see how it can be confusing, even though it is working perfectly.

Client logs in.
A server update occurs.
Client visits a new page (or refreshes the current page) - client is still logged in, but is seeing new updated content.
But... Client closes the browser and restarts it - browser does not return the cookie and is logged out.
Or... Client closes the browser and restarts it, but does not close all instances of the browser.  Things are confused.

When you ask a client to close the browser, you're not asking for what you really need.  What you really need is for the client to close every instance of the browser - all tabs and windows

Sentences like this are a "code smell" because they seem to contain some misused terms of art, and therefore potential misunderstanding of the way things work.
... the session control is manually done now so the session is destroyed in a different way.
Dave BaldwinFixer of ProblemsCommented:
Speaking of 'session_destroy', I'll post the page again http://php.net/manual/en/function.session-destroy.php because too many seem to think "their own way" is going to do it properly.  The example works and works properly.
Ray PaseurCommented:
Dave: Good point -- it's so easy to get caught up in obsolete code examples with a language like PHP that is now about 20 years old.  Too bad code examples do not come with expiration dates!  Too bad, also, that programmers do not read the online manual before they copy and install old code samples!
WebspeederAuthor Commented:
By session destroy, this is the complete PHP code that is ran.

  if (isset($_SERVER['HTTP_COOKIE'])) {
      $cookies = explode(';', $_SERVER['HTTP_COOKIE']);
      foreach($cookies as $cookie) {
          $parts = explode('=', $cookie);
          $name = trim($parts[0]);
          setcookie($name, '', time()-1000);
          setcookie($name, '', time()-1000, '/');

  setcookie('crowd_token_key', '', time()-10, '/', '.bigrocksports.com',false,true);
  setcookie('pctrl', '', time()-10, '/', '.bigrocksports.com',false,true);
  setcookie("PHPSESSID","",time()-3600,"/"); // delete session cookie
  $_SESSION = array();

  session_unset();     // unset $_SESSION variable for the run-time
  session_destroy();   // destroy session data in storage
WebspeederAuthor Commented:
But again, the main issue, I as far as I can see it, is that the "new" index.php is not being called on first pass. Once it's reloaded, it picks up the new code and all works as expected.

I think the next time I need to make a change to index.php, I will change to index.html, and inside index.html direct to index.php, something along those lines. Then I can make sure the proper file is hit.

BTW, some of the condescending / implication type remarks are hilarious.
WebspeederAuthor Commented:
Also, by manually, what I mean is on the server side. Evaluations are made that if not passed, the user is sent back to the login page.

Previously, PHP $SESSION controlled the session timeout.
Ray PaseurCommented:
This is all I've ever needed to dispose of a PHP session.
$_SESSION = array();
if (isset($_COOKIE[session_name()])) setcookie(session_name(), '', time() - date('Z') - 3600, '/');

Open in new window

If you have any cache algorithms on the server, you would want to have a cache-bust script.  On some of my installations I've used cacheing based on the URI for GET requests.  Obviously, if I change the response document, I need a way to flush the cache, since the request would be served first from cache and only from the server scripts if the cache was not useful.  The symptom of a cache hit is that the server returns the same document over and over, even after the document is changed on the server.  This happens until the cache is manually busted - asking the client to refresh the browser does not bust the cache.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dave BaldwinFixer of ProblemsCommented:
Just curious, did any of you actually read the PHP Man page?  I do add one thing to that code.  After session_destroy() I add another session_start() to create a new session_id that is different than the previous one.  Just to block access to things that were stored with the old session_id.

If it is a browser cache problem, refreshing the page with Ctrl-F5 does a complete refresh from the server in Firefox, IE and Chrome.
WebspeederAuthor Commented:
I will investiate the cache bust approach. Also, I'll add the restart session after destroy as suggested. So I'm giving credit to both resonses.

Thank you for your help.
Ray PaseurCommented:
Thanks for the points.  Theory and practice of using cache in a PHP script is detailed in this article:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Browsers

From novice to tech pro — start learning today.