Announcement

Collapse
No announcement yet.

Urgent: Numerous issues with website since upgrade to 5.1.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Urgent: Numerous issues with website since upgrade to 5.1.5

    So.. things are becoming somewhat of a disaster at Disaster.com. I opened tickets on these issues, but after a day I only got a reply suggesting the first thing we did to try to solve the problems - clearing the system cache and the local caches. These didn't work.

    Here's where we're at:
    1. 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.
    2. 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.
    3. 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)
    4. 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)
    5. 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!

  • #2
    BTW - if I go to Cookies and HTTP Header Options and enable "Add No-Cache HTTP Headers", things work (and I see a No-Cache in the headers vs. Cache-Control:max-age=3600). For performance issues, however, we can't leave this option on indefinitely. It kills response time on the site.

    Comment


    • #3
      Are you using the default 5.1.5 .htaccess file on the site or have you added some lines?

      Please don't PM or VM me for support - I only help out in the threads.
      vBulletin Manual & vBulletin 4.0 Code Documentation (API)
      Want help modifying your vbulletin forum? Head on over to vbulletin.org
      If I post CSS and you don't know where it goes, throw it into the additional.css template.

      W3Schools <- awesome site for html/css help

      Comment


      • #4
        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.

        Comment


        • #5
          Both config files need a cookie prefix, and they both need to be the same.
          If that was wrong beforehand, I'm surprised you haven't run into difficulties previously.

          Have you tried uploading tools.php (and the /core/install folder) and resetting the cookie path and prefix through there? Even when it looks right, it's been known to assist.
          MARK.B | vBULLETIN SUPPORT

          TalkNewsUK - My vBulletin 5.5.4 Demo
          AdminAmmo - My Cloud Demo

          Comment


          • #6
            Is there anything specific I should run in tools.php? It doesn't let you set the cookie prefix (but it does say that it's "bb"). In tools.php I had it reset the cookie domain and the cookie path, then cleared ALL cookies for the domain, turned off "Add No-Cache" (so caching is on), cleared system cache, cleared the local cache, and still have the same issues.
            Last edited by DisasterDotCom; Wed 4th Feb '15, 6:04am.

            Comment


            • #7
              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.

              Comment


              • #8
                Are you sure you have no cache headers being set on the webserver end?

                Comment


                • #9
                  BETWEEN testing I have no-cache headers set. In other words, I normally DO NOT have no-cache set. So.. when I test something.. I turn no-cache off, do the test, see the results, and then turn no-cache back on. I do not want no-cache to be on all the time as this greatly increases server load and shouldn't be needed. I need to figure out what's going on when no-cache is off. Expiration should work. If possible, perhaps we can schedule a time today for you to sign up for the forums (I'll turn no-cache off turning this time period) and you can view the behavior yourself.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      If your webserver/site is configured to send cache headers otherwise, that would tend to cause significant problems, then when you turn vBulletin's headers to force stuff off, its only as good as long as its on.

                      Comment


                      • #12
                        Just like to clear some stuff up here.

                        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.

                        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.

                        Comment


                        • #13
                          Not sure I understand what you're saying..?

                          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 https://www.disaster.com/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?

                          Comment


                          • #14
                            Alright... after 8 hours of troubleshooting, and Zachery 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.

                            P.S. vBulletin - I would recommend modifying your default .htaccess file that ships with the software to include these ExpiresByType directives so this problem doesn't affect others

                            Comment

                            widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                            Working...
                            X