Announcement

Collapse
No announcement yet.

Site continually refreshes when users try to login: problem with DST setting

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

  • Site continually refreshes when users try to login: problem with DST setting

    If this exists as a thread elsewhere, sorry, I searched for this and nothing came up.

    We are still having issues with the site continually refreshing when users try to login. There is a JIRA for this here.

    http://tracker.vbulletin.com/browse/VBV-14445

    The answer to my support tickets said that for individual users you can fix this by setting "Automatically detect DST" to no in their individual user profiles.

    To the best of my knowledge there is no way to set the default for "Automatically detect DST" to no for all users [is this correct?]

    The fix in the JIRA says run this query.

    UPDATE user SET options=options - 64 WHERE options & 64;

    May I just clarify:

    Does this mean

    - You go to admincp, Maintenance, Execute SQL Query
    - in the box titled Manual Query you type in UPDATE user SET options=options-64 WHERE options & 64; [and nothing else]
    - you press the button saying "Continue"
    - and the above will just change DST to "NO" for all users? Have I correctly understood?

  • #2
    The JIRA says this issue was fixed in 5.2.3. Are you running that version?

    GIPHY for vB5 AutoLinker Auto-Create Flag Report Topic Social Icons in Postbit Clear Cache Cron DragDrop Upload Topic AJAX AutoUpdate Custom Avatars Selector Stop Links in Posts...and more!

    Comment


    • jdj
      jdj commented
      Editing a comment
      I'm running 5.2.3.

  • #3
    If you have upgraded to 5.2.3, make sure your templates are up to date. Also clear your browser cache to see if it continues.
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API - Full / Mobile
    Vote for your favorite feature requests and the bugs you want to see fixed.

    Comment


    • #4
      Originally posted by Wayne Luke View Post
      If you have upgraded to 5.2.3, make sure your templates are up to date. Also clear your browser cache to see if it continues.
      Thanks.

      Although one of my other admins reported this as still a problem I'm struggling to replicate it post upgrade. Could issues with JavaScript cause something like this? Also, would you mind answering the other two questions in my original post?

      - is that all I have to put in the box to run this query
      - is there any way to set "Automatically Set DST" to "No" as the default for all new users? Where do you set this?

      Comment


      • #5
        Javascript is definitely the cause since it all occurs on the user's computer with their Javascript engine. If they are using ad or script blockers it can cause the problem.

        1) Yes. Otherwise, we would have given a different query.

        2) Same place you've always set defaults for new users. Settings -> Options -> User Registration Options.
        Translations provided by Google.

        Wayne Luke
        The Rabid Badger - a vBulletin Cloud demonstration site.
        vBulletin 5 API - Full / Mobile
        Vote for your favorite feature requests and the bugs you want to see fixed.

        Comment


        • #6
          Originally posted by Wayne Luke View Post
          2) Same place you've always set defaults for new users. Settings -> Options -> User Registration Options.
          Thank you for the reply.

          Under Settings, Options, User Registration Options there is no option under Default Registration Options to set the default for Automatically Detect DST (AD DST) to either yes or no. In fact, there's nowhere under Settings, Options, User Registration Options to set the default for AD DST.

          Whether there ever was a setting to change this somewhere or not I don't know. I'm running 5.2.3 and in 5.2.3. if you create a new user the default is AD DST "Yes" and there is no option to change it that I can see; that's why I asked the question.

          Comment


          • #7
            Originally posted by Wayne Luke View Post
            Javascript is definitely the cause since it all occurs on the user's computer with their Javascript engine. If they are using ad or script blockers it can cause the problem.
            One of the other (non-forum) PHP-based programmes I use has a setting in it which is entitled "Clear combined CSS and JS" which forces that particular software programme to regenerate the*/js file which can stop problems. There's nothing like this in vBulletin in admincp, Maintenance. Does the Clear System Cache function in Maintenance do this in vBulletin?

            Comment


            • #8
              Originally posted by jdj View Post

              One of the other (non-forum) PHP-based programmes I use has a setting in it which is entitled "Clear combined CSS and JS" which forces that particular software programme to regenerate the*/js file which can stop problems. There's nothing like this in vBulletin in admincp, Maintenance. Does the Clear System Cache function in Maintenance do this in vBulletin?
              No.. the end user has to clear their browser cache to reset the Javascript on their end.
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API - Full / Mobile
              Vote for your favorite feature requests and the bugs you want to see fixed.

              Comment


              • #9
                Originally posted by jdj View Post

                Thank you for the reply.

                Under Settings, Options, User Registration Options there is no option under Default Registration Options to set the default for Automatically Detect DST (AD DST) to either yes or no. In fact, there's nowhere under Settings, Options, User Registration Options to set the default for AD DST.

                Whether there ever was a setting to change this somewhere or not I don't know. I'm running 5.2.3 and in 5.2.3. if you create a new user the default is AD DST "Yes" and there is no option to change it that I can see; that's why I asked the question.
                It would be there if is exists. Sorry, I don't remember every single setting and just assumed it would be there. Users can set this in their Settings after you turn it off for them using the query above.

                The problem only affects a small number of end users and we can't reliably recreate it to test if the fixes work for everyone.
                Translations provided by Google.

                Wayne Luke
                The Rabid Badger - a vBulletin Cloud demonstration site.
                vBulletin 5 API - Full / Mobile
                Vote for your favorite feature requests and the bugs you want to see fixed.

                Comment


                • #10
                  Originally posted by Wayne Luke View Post

                  No.. the end user has to clear their browser cache to reset the Javascript on their end.
                  Thanks. On this other non-forum programme that I use one of the options to decrease page loading time which you set if you wish to is to Combine, Minify and Compress CSS and JS. We've experienced problems occasionally post upgrade of this other software with some users who are unable to use the site running this software and the reason appears to be a mis-match between the js or other software on the server and the js saved in their browser. This "Clear Combined CSS and JS" button in this software forces the users browser to go and get the new js or new combined js and css when they next visit. Although it's not a standard recommendation for this software having experienced a problem with this more than once I'm now going to include it in my upgrade routine.

                  That experience with another programme is making me wonder about vB: I was wondering whether there would be any feature in vB that could do the same thing i.e. rather than have the end user clear their browser (which you have to tell them to do, assuming you even know that they are having a problem) after an upgrade you would just force their browser to get some new js when they next visit and incorporate that into your upgrade or maintenance routine.

                  Comment


                  • #11
                    Originally posted by jdj View Post
                    The fix in the JIRA says run this query.

                    UPDATE user SET options=options - 64 WHERE options & 64;

                    May I just clarify:

                    Does this mean

                    - You go to admincp, Maintenance, Execute SQL Query
                    - in the box titled Manual Query you type in UPDATE user SET options=options-64 WHERE options & 64; [and nothing else]
                    - you press the button saying "Continue"
                    - and the above will just change DST to "NO" for all users? Have I correctly understood?
                    I've just tested this out on my test site. I went to admincp, Maintenance, Execute SQL Query
                    - in the box titled Manual Query I copied and pasted UPDATE user SET options=options - 64 WHERE options & 64; exactly as shown
                    - I pressed "Continue"
                    - I was given the warning under "Confirm Query Execution" which says "This query may modify data in your database...": I then pressed the button saying "Continue"

                    The result was
                    Message
                    An error occurred while attempting to execute your query. The following information was returned.
                    error number: 1146
                    error desc: Table '[name of my test database].user' doesn't exist

                    Comment


                    • #12
                      Then you're using a prefix for some reason. You will need to add your custom prefix to the user table name. You can find your prefix listed in your /core/includes/config.php file.

                      The default table prefix is empty and sufficient for 99.99% of installations.
                      Translations provided by Google.

                      Wayne Luke
                      The Rabid Badger - a vBulletin Cloud demonstration site.
                      vBulletin 5 API - Full / Mobile
                      Vote for your favorite feature requests and the bugs you want to see fixed.

                      Comment


                      • #13
                        Originally posted by Wayne Luke View Post
                        Then you're using a prefix for some reason. You will need to add your custom prefix to the user table name. You can find your prefix listed in your /core/includes/config.php file.

                        The default table prefix is empty and sufficient for 99.99% of installations.
                        OK so it should be

                        UPDATE [add prefix here]user SET options=options - 64 WHERE options & 64;

                        Comment


                        • #14
                          Yes.

                          Remember your prefix may (or may not) have an underscore in it. That needs to go in too if it has one.
                          MARK.B | vBULLETIN SUPPORT

                          TalkNewsUK - My vBulletin 5.5.6 Demo
                          AdminAmmo - My Cloud Demo

                          Comment

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