Major cache, cookie or session issue after upgrade to 5.1.5

[DisasterDotCom]

So I posted all of these issues over at vBulletin.com, and I also opened up tickets. The response from support (after 24 hours) was "Clear your system cache and local browser cache". This was the first thing we tried before we even opened up tickets, and I'm not getting love over there so I thought I'd ask for suggestions here as to how to track these gremlins down. I'm so close to switching to Xenforo (found someone who will custom move our site to Xenforo for under $200, including users, threads and ensuring our URLs all match). Anyway...

We "upgraded" from 5.1.4 to 5.1.5. We immediately started having the following issues:


If someone posts a reply to a thread and then goes back to the main forum page, the new reply doesn't show up as the latest (the topic still shows 0 replies). If they then go back into the thread, the reply doesn't show up until they refresh the page. Obviously a browser cache issue somewhere, but it's happening consistently across our user base and can be consistently reproduced.
When people delete notifications, they aren't actually deleting. The number at the top of the page decrements, but when you click on a new page it goes back up and the notification you deleted reappears.
When people click on certain links within the forums (local internal links) they are logged out (cookie issue? We tried deleting ALL cookies for the domain and still have the same issues)
When we go to /forums, the sub-headings of the menu (i.e. Today's Posts, Who's Online, etc.) don't show up, but they do when you go any other page (such as /forums/forum)
Using the search in the upper right corner of AdminCP logs the admin/mod out


These issues all seem to be related to a caching or cookie issue, or maybe a session issue somewhere. They are causing MASSIVE usability issues across our forums. Please help!

[ForceHSS]

Many reasons I am with vb4. Would your host not move you for free or would you not think of using vb4 it would mean a fresh install

[DisasterDotCom]

If I leave vb5, I want to move to a platform that's modern and under development. vb4 has lots of plugins and features, but it is no longer under active development. Mobile access is VERY important, and Xenforo beats out vb4 on this. But.. I would prefer if this thread focuses on the issue at hand as opposed to switching platforms (I shouldn't have mentioned that in my original post). Also, we're self-hosted on a distributed server system, so it's up to us (me) to do whatever is needed.

[ForceHSS]

If you go to Cookies and HTTP Header Options and enable "Add No-Cache HTTP Headers does it work

[DisasterDotCom]

Sorry... updated the vbulletin.com thread with this info but not this one...

I did that a couple of hours ago. I'm having a hard time telling if it worked or not. I enabled it then cleared the system cache, and now I see sporadic results. Sometimes it works, sometimes it doesn't. In every case, I've verified that no-cache, no-store, max-age=0, must-revalidate are in the header.

[Lynne]

What are your Cookie Domain and Cookie Path in AdminCP > Settings > Options > Cookie Settings?

Did you make sure your cookie prefix is set to the same thing in both the root config.php file and the /core/includes/config.php file?

Did you add anything to the default 5.1.5 .htaccess file?

[DisasterDotCom]

So... the root config had an empty cookie prefix, and the core/includes config had "bb" as the cookie prefix. These files have not changed since prior to the upgrade, but I set the root config to also be "bb". I then turned off the no-cache, cleared the system cache, and the problem is still there.

The cookie path is /. The .htaccess file has not changed since August. The only difference between my .htaccess and the one that shipped with 5.1.5 is the rewritebase (my file - /forums/, stock file is just /).

I thought it might also be a memcached thing so I turned off memcache (I assume VB falls back to file based storage then?) but that didn't make a difference either.

The whole thing where refreshing the pages makes the new stuff appear.. has to be a browser caching issue somewhere, but with it being userbase-wide it has to be coming from the server side somewhere.

P.S. There were definitely some changes made to the software that didn't make it into the release notes. I also noticed that the manual sitemap generation required me to put in a new full path to the sitemap location before it would work. There's nothing in the release notes about this change.

[ozzy47]

IMO, I would restore your 5.1.4 backup you took before upgrading, then mirror your live site on a test site. Then upgrade the test site to 5.1.5 and see if you can work out the issues on the test site.

[helenblog]

lol vb5 still have more problems, it maybe reason why i'm not ready go with vb5, still using vb4 and feeling good with it.

I think somone should consider and studying before installing a vb version, sure it is suitable for your requirement and your web host.

[ozzy47]

Lets stick with the original post, and not turn this into a version discussion, stick with trying to help the OP.

[DisasterDotCom]

Thanks ozzy. Yeah - I'm considering that, but I'm not certain how I can import new threads from the past four days into a restore. We didn't hear about this until 3 days after the upgrade occurred, but we did verify that it was happening almost immediately after. I don't want to lose the updates (we're a disaster and crisis forum, and there are numerous discussions in our "active disasters" forums about what's going on in the world right now). But.. if I can't figure this out today, I'll go back no matter what.

[ozzy47]

Yeah, it kinda sucks, but that may be your best option at this point in time, better off go loose a couple of days, rather than loosing members cause of the issues.

Hopefully though, vB support come with a breakthrough today though.

[DisasterDotCom]

When a page has been updated, shouldn't vBulletin be resetting the Date: in the HTTP header?

Here's what I'm seeing... I make the original post at 15:12:05 UTC. I make a reply immediately after at 15:12:10 UTC. The page still shows the Date: as 15:12:05 UTC. I leave the page and go to the main forum page, then return to the post. It STILL shows the Date: as 15:12:05 UTC until I refresh it. So.. the client isn't being told there's an update to the page. This is set by vBulletin, isn't it? Since the pages are create dynamically?

This is through header inspection in the network tab of Chrome developer tools.

[Paul M]

The response from support (after 24 hours) was "Clear your system cache and local browser cache". This was the first thing we tried before we even opened up tickets
Did you tell support you did that before they replied ?
They dont have special magic powers to know what you have or have not done. ;)


These issues all seem to be related to a caching or cookie issue, or maybe a session issue somewhere. They are causing MASSIVE usability issues across our forums. Please help!
Those are not cookie issues, they look like cache issues, possibly within vB, but hard to tell.

Turn off the vB Cache system for a while (its in options, not sure where, I cannot look it up from here).

[DisasterDotCom]

No - I'm not complaining that the first thing they told me was to clear the caches. What is a bit upsetting is that I replied to the request within 15 seconds and they have not replied back yet (since yesterday) except on the vbulletin.com board. But, right now, I care more about solving these problems than complaining about poor support response times.

In between testing I'm enabling the "no-cache" function ("Add No-Cache HTTP Headers").

I do appreciate your responses.

--------------- Added 1423067894 at 1423067894 ---------------

So just to update... I turned debug on in the config file and looked at time stamps (generated BY vbulletin at the bottom of each rendered page):

Initial Post - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
After Comment - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
Click on forum link - Current Time: Wed, 04 Feb 2015 11:31:03 -0500
Hit refresh - Current Time: Wed, 04 Feb 2015 11:33:12 -0500
Click on topic again - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
Click refresh - Current Time: Wed, 04 Feb 2015 11:35:15 -0500

Note that when I click on the forum link I go back in time (even though I've made a new post). I refresh, we come back to the current time.

Then when I click on the topic again, the time stamp matches the initial post time - NOT the time after I made the comment. Once again, I refresh and we come back to the current time and the reply shows.

[Zachery]

vBulletin has two choices for cache headers: NONE, zip, zilch, nada, no headers will be sent AT ALL in regards to caching content. That or we EXPLICITLY send a no cache header. Those are the ONLY two options with the software. If ANY other cache headers are being sent, its coming from the webserver and or its configuration. At least, in regards to the HTML content type, which is the output of all normal vBulletin page(s)

You refreshing (forcing your browser to ignore the cache headers) is doing exactly what it should, forcing a check. The reason the site is "responsive" when cache headers are on, is your browser is just grabing the site from its local cache, instead of waiting for webrequests/responses.

[DisasterDotCom]

Update...

The headers get sent down by vBulletin or Apache, but the only thing that's changed is vBulletin, and this started immediately after the change. It occurs with both Chrome and Firefox.

Looking at the logs:

1. I click on new thread GET /forums/new-content/44 HTTP/1.1
2. I make the post POST /forums/create-content/text/ HTTP/1.1
3. The page refreshes GET /forums/forum/general/test-forum/28305-this-is-another-new-topic
4. I add a reply POST /forums/create-content/text/ HTTP/1.1
5. The reply shows up POST /forums/create-content/loadnode HTTP/1.1
6. I go to the parent forum of the post GET /forums/forum/general/test-forum HTTP/1.1
7. I click on the post, page displays and a POST /forums/ajax/api/node/incrementNodeview HTTP/1.1 and then GET /forums/foru...-another-testt HTTP/1.1

Everything has a status code of 200. Item 6 and 7 have a Cache-Control: max-age=3600 and the date and time of the original post.

Isn't the process from the client to the server supposed to be something like... pull down the original page and cache it locally. Request the same page later, send a request to the server for a header to see if the page has a new time, if they match then pull the local copy, if they don't match send the new copy. Apache has no idea whether the page has been updated or not - that is generated by vBulletin, correct?

--------------- Added 1423090573 at 1423090573 ---------------

Alright... after 8 hours of troubleshooting, and Zachery (on vbulletin.com) mentioning that there are only two types of caching - on or off - I found this is not a vBulletin issue.

For future reference... IF you have vBulletin installed in a subdirectory (i.e. /forums), and the PARENT directory has an .htaccess file, the directives from this parent .htaccess file will be used. Any directives you have in the subdirectory will override those of the parent, but if there's something in the parent that's NOT in the subdirectory .htaccess, it will be pulled from the parent.

In our case, the parent .htaccess had the following directives (in addition to many others):

ExpiresByType text/html A3600
ExpiresByType text/richtext A3600

These were setting a 3600 second (60 minute) expiration on HTML content.

I've modified the vBulletin .htaccess file to be the following:

ExpiresByType text/html A0
ExpiresByType text/richtext A0

This effectively sets max-age to 0 so HTML does not cache.

We're still trying to figure out why this is corresponding to the upgrade to 5.1.5. Something had to change somewhere, because (as far as we know) nothing else changed.

[ozzy47]

Well glad to hear that is sorted. :) Now you don't have to roll back to the backup. :)

[Zachery]

We changed some of the facebook code, which was previously always sending headers, and no longer does.

Also, .htaccess / vhost rules always filter into sub-folders.