We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 5119
    • 90 Posts
    Anyone?

    This is really urgent. If there’s anyone who can help with an hour or two of their time, I’m happy to pay. I just really need to get this sorted out and I’d prefer the help of someone who is already familiar with MODx to know how everything interacts.
      • 7455
      • 2,204 Posts
      Quote from: Chocoholic at Jul 26, 2010, 08:56 AM

      Which line? I can only find stuff about caching which won’t be much help.

      the one that sets the cookie:
      change
      setcookie(session_name(), session_id(), $cookieLifetime, MODX_BASE_URL);

      to:
      setcookie(session_name(), session_id(), 604800, MODX_BASE_URL);

      604800 = 1 week
        follow me on twitter: @dimmy01
        • 5119
        • 90 Posts
        Dimmy, isn’t this for the CMS session and not the web user session? I’m stuck trying to find this line for web users...
        • It all uses the same SESSION, which session_name is stored in the cookie. It’s initially set in the function at the end of the config.inc.php file. All logging in/logging out does is add to the SESSION or (in the case of WebLogin) clear the SESSION on logout (which is something that needs work; it should only remove the WebLogin relevant array elements, not clear the whole session).
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 5119
            • 90 Posts
            When I tried that, the login screen would no longer let me log in! Switched it back to the text and the login worked once more.

            Could it be because the session.cookie_lifetime is set in my php.ini files elsewhere? I can’t think of any other reason why it wouldn’t work.

            Anyway, the problem still seems to be related to the session files disappearing from the directory. I guess that’s not a MODx-related problem if it is some sort of garbage collection, but I don’t understand how garbage collection is happening when I have no cron jobs set up for it. There’s definitely a shortage of session files going on.

            Stranger still, in the past 15 minutes, about eight empty sessions have been added to the directory - three all in the same minute, then four from the same minute that a manager user logged on, one two minutes later.
              • 5119
              • 90 Posts
              ARGH! So, I extended the time to a week for the session.cookie_lifetime in all my php.ini files. Seemed to work a treat for the first day and a bit. However, I logged in as a web user about three hours ago and it’s logged me out. If my cookie is valid for a week, why, when I do a grep on the temp session directory, has the cookie been deleted????

              I’m going to try setting garbage collection to 1/1000 chance of starting out of desperation.
                • 5119
                • 90 Posts
                Anyone? I’m going to lose my job if I can’t figure this out soon. I am seriously willing to pay for someone to have a look at this.

                Latest discovery is that after deleting all the browser cookies and logging in again, the site generates five cookies and each has a different expiry (listed in this order):
                _utmb - expires 24 mins from login (valid for .mydomain.com - no ’www’), contains 180808114.1.10.1283514511
                _ubmc - expires end of session (valid for .mydomain.com - no ’www’), contains 180808114
                _utma - expires 2yrs from now (valid for .mydomain.com - no ’www’), contains 180808114.1010225969.1283514511.1283514511.1283514511.1
                _utmz - expires 6mths and 2 days from now (valid for .mydomain.com - no ’www’), contains 180808114.1283514511.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
                SN4bfd6fdda0a7a - expiry is blank blank (valid for www.mydomain.com), contains f2oshifd12mv6puvaffgd5sms1

                Any ideas? I’ve got the php.ini file in as many directories as I believe it’s required, including the directories for weblogin, EasyEvents and TinyMCE.
                  • 5119
                  • 90 Posts
                  Can nobody shed any light? I’m finding things out bit-by-bit, but I’m really no closer to a solution. Even the offer of money hasn’t helped!

                  I’ve discovered that those utm* cookies are created by google analytics. This means that only the last cookie is actually being created. It doesn’t time out on Firefox for a few days, but it still times out really quickly in Safari (and probably IE too).

                  How can this be?
                    • 20413
                    • 2,877 Posts
                    @Chocoholic My php.ini:
                    ; 3 days login
                    session.cookie_lifetime=259200
                    session.gc_maxlifetime=259200


                    Haven’t tested it for 3 days yet but restarted Rockmelt and
                    I’m still logged in and have been longer than I used to be before. cool

                    update
                    3 days - [CHECK] smiley
                      @hawproductions | http://mrhaw.com/

                      Infograph: MODX Advanced Install in 7 steps:
                      http://forums.modx.com/thread/96954/infograph-modx-advanced-install-in-7-steps

                      Recap: Portland, OR (PDX) MODX CMS Meetup, Oct 6, 2015. US Bancorp Tower
                      http://mrhaw.com/modx_portland_oregon_pdx_modx_cms_meetup_oct_2015_us_bancorp_tower
                      • 5119
                      • 90 Posts
                      Thanks mate. I solved it a few months back. It turned out to be a typo in the javascript. Line-by-line checking found it in the end. The login now works perfectly.