Having major cache issues, need advice

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

E.g.

file.js?<?=microtime();>?

I manually do the versioning. We thought about the time, but the end result would be the same, correct?

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.

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.

Did you setup caching on your apache server?

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.

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.

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

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.
https://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_11909-PHP-Sessions-Simpler-Than-You-May-Think.html

If refreshing the browser page fixes the problem, then I think it is browser caching.

Refreshing the browser page may not clear the cookies.  That could (and should) be under the control of the user's settings.

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.

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.

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.

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!

By session destroy, this is the complete PHP code that is ran.

<?php
  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
 
?>

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.

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.

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.

Thanks for the points.  Theory and practice of using cache in a PHP script is detailed in this article:
https://www.experts-exchange.com/articles/18437/Improving-Web-Site-Performance-via-PHP-Cache.html