Reinstall to address persistent session timeout issue?

  • agreda

    (@agreda)


    10 years, 5 months ago

    Hi. I’m hoping some experts here may be able to confirm if this last resort attempt might fix a nagging issue of our users at tripawds.com being consistently and randomly logged out.

    (I have searched these forums for related issues and found no relative solution. The commonly recommended fix of ensuring the WP domain and Site URL match is irrelevant since this is a multisite network.)

    Background: Ever since migrating our network to a new more robust dedicated server, we are experiencing a persistent issue with users of all levels being randomly logged out, often multiple times a day. Multiple (perhaps all) users seem to be consecutively logged out at the same time. If in the WP Admin, the pop-up will display a session expired message. There are no errors generated in any server logs.

    Note: We have a team of five who has been troubleshooting this issue for two months. I have taken all the usual steps to rule out any plugin or theme causing the issue. Yes, I have deactivated and reactivated all plugins, reset the plugins folder, and tried the default theme. I have done this multiple times. I have deactivated any security plugins, and we use no caching plugin.

    My server managers and I have also ruled out mod_security as the cause by disabling that at the user, domain and server level. My sever managers, and Peer1 support techs, have reviewed the Apache, MySQL, and PHP configuration, at great length. Still we are stuck with users continually being logged out of the site. So…

    One of our managers is suggesting we do a fresh install of WordPress and import all the data. His reasoning is that since the old server ran PHP 5.2, and the new one has PHP 5.4, there may be some functions no longer running optimally…

    I *suspect* that this (mis)configuration is what might be causing the timeouts. Maybe some function got deprecated, or maybe some function works JUST a little differently when on 5.4 vs. 5.2.

    So, by running a fresh installation of WP, the installer will configure WP to be optimized for 5.4, hopefully ameliorating the problems we’re seeing. I will grant you that this just an educated GUESS…This theory comes from how software is usually installed on systems. The installer checks the environment…By changing the environment (i.e. PHP5.2 to PHP5.4), doesn’t it make sense to also change the software configuration as well?

    Is he on to something here? Would this be your next step if faced with such an issue?

    We’re considering setting up another domain to test this theory, with a fresh WP network install, and data import, but that raises it’s own issues of having to move gigs of files, a mutigigabyte database, and editing db tables for the domain change. Ugh.

    Could/should I just archive the current core files. Do the fresh install and point wp-config to the current db?

    Any feedback or other suggestions are greatly appreciated. And I’m happy to provide any additional information.

    Thank you!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter agreda

    (@agreda)

    10 years, 5 months ago

    So…I’m still dealing with this messy issue of users getting logged out unexpectedly and repeatedly. I’ve even attempted to address the issue by forcing WordPress to keep users logged in with the following function:

    /* Keep Users Logged In! */
add_filter( 'auth_cookie_expiration', 'keep_me_logged_in_for_1_year' );

function keep_me_logged_in_for_1_year( $expirein ) {
    return 31556926; // 1 year in seconds
}

    Yet, users of all levels still get logged out of the site. Sometimes many times a day. Has anyone experienced such an issue on a multisite install?

    I have still not attempted the clean install on new domain approach I originally described above, as suggested by my server manager. Why not? Because 1. I have other newer installs that don’t have the issue; 2. I think there must be other steps to try first; And, 3. It opens a whole new can of worms…

    For starters, a new install will not have any wp_1_x tables since the primary site will just use wp_x. On our current install the main site is wp_1 so importing that db into the new install would be a major pain. Wouldn’t it?

    Any and all feedback welcome! Thanks in advance for any help.

    Thread Starter agreda

    (@agreda)

    10 years, 5 months ago

    Might anyone be able to confirm or deny my server manager’s theory here?

    Please.

    My theory is, that during the process of adding those *.php files, the installation script checked the version of php, and had configured itself (somehow?) to use, for example, fileA.php – which is optimized for php version 5.3 – instead of fileB.php – which might be optimized for php versions lower than 5.3. So re-running that installation script might recognize a different php version, and then use the appropriate core file.

    I would even posit that, even though the exact same core files would be added to the server, only the ones that “work” with a certain php version would be used. Those files that were optimized for a *different* php version would be simply ignored, and not used.

    I am still hesitant to go to the trouble of a fresh install at a dev domain, with import of our multi-gigabyte database (not to mention moving all the files) based on an assumption. And, I still don’t know how to handle the wp_1 vs. wp_ table structure issue if I do.

    Anyone?

    Thanks!

    RyanHuggins

    (@ryanhuggins)

    10 years, 3 months ago

    I’m having the same error on a single site install. Did all the steps you did for troubleshooting, except configuring the server (shared hosting here). Happened after a move to a new hosting platform. I’m getting my admin account expired almost every time I do anything on the site today (other days it works fine). Very frustrating. No caching plugin either. Killing my productivity.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Reinstall to address persistent session timeout issue?’ is closed to new replies.