New to the community? Start here

Membership 2 login failed after domain change

After moving site from domain.co to domain.co.nz the Membership 2 login is no longer working. If someone is trying to login he's redirected back to the same login page.
And sometimes with a request failed message.

The issue is present even with newly created users.

We tried re-installing the plugin and use Better Search Replace to replace all occurrence of old domain from the database but it's like some values were not updated.

  • Adam Czajczyk
    • Support Gorilla

    Hello Chris Milicich

    I hope you're well today and thank you for your question!

    I have checked your site and I noticed something more that's bothering me:

    1. after logging in on /account page with the test user that you provided I was taken back to the same login form on the /account page indeed; I couldn't also access any of the protected content that I was supposed to be able (according to the user's membership) but... I was actually logged in - entering /wp-admin directly showed that I was able to access it and was logged in to the site.

    2. even as an admin (logged in as admin via support access) I wasn't able to access account page or any other of the pages protected with Membership 2 Pro protection rules.

    That together makes me think that the core of the issue is slightly different. I think the user is in fact being logged in properly but for some reason the plugin doesn't seem to recognize that.

    Taking that into account, I'd actually start with checking if there's any sort of caching active on server - especially Varnish, Redis, Memcached or similar cache. Do you know if there is? If not, could you please double-check it and if there is clear it completely?

    If you cannot find any option for that in your server's management panel (such as e.g. cPanel or similar), could you please get in touch with your host to make sure about it?

    Let me know about results, please. Meanwhile, the issue was also reported to our developers and they were asked whether there are any additional changes/updates e.g. to the database that could be missed and should be performed after switching domain. We're waiting for their response and we'll update this ticket once we only hear back from them.

    Kind regards,
    Adam

  • Chris Milicich
    • New Recruit

    Response from the server host:

    There is php Opcache on the server, no Redis, Varnish, or Memcached. When we were testing yesterday, we disabled this for PHP 7.1 - the version collegesport is using - and attempted to log in.

    I've disabled Opcache again now, and have cleared all browser history and attempted to log in once more.

    Something you may want to relay back to WPMU support: when collegesport.co.nz cookies are cleared, and a login attempt is made, the process takes several seconds, and the message to the left of the login box says:

    "Please wait..."

    then

    "Logging in..."

    then it eventually comes back to 'Please login to access this page'.

    If there are cookies present, and a login attempt is made it says

    "Please wait..."

    very briefly, then immediately updates to:

    "Request failed, please try again."

    For now, we'll leave Opcache off, but it doesn't appear to materially affect the issue.

    Karl

  • Adam Czajczyk
    • Support Gorilla

    Hello Karl!

    Thank you for your response.

    I have checked the site again and it looks that cookies are set properly. It still actually does log me in even if it doesn't give me access:
    - I login via /account page
    - I'm taken back to /account page with a login form
    - I can manually access /wp-admin where I can see I'm logged in.

    Examining cookies in browser shows that they are set. I then did some investigation on the plugin code and here's how it goes (for /account page but the process is similar for every other membership page):

    page template is loaded -> the "ms_is_user_logged_in()" function is called -> that function actually only checks internal variable used to store whether the user is logged in -> if that returns that user is logged in, the account page is served instead of login form.

    So, I have investigated the "ms_is_user_logged_in()" function and - I'll skip the details "on the way" - in the end it actually is based on a core WP "is_user_logged_in()" function so ultimately that one is used to check whether the user is or is not logged in.

    That's a "weird" issue, I admit. Cookies are for proper domain and going through the code suggests that either the WP core "is_user_logged_in()" function fails in M2P plugin context or somewhere "on a way" in between that function is called and the "logged in" information is saved to the internal variable - there's something interfering.

    That's, however, a bit too much for me to go further so I'm afraid we'll need to wait for our developers' feedback on this after all. Please keep an eye on this ticket for further information.

    Kind regards,
    Adam

  • Ivan
    • Developer

    Hi Chris Milicich !

    Actually, it doesn't relate to Membership PRO. Your WordPress installation doesn't work properly at all. For example, Wordpress has get_current_user_id() function for getting current user id, but if you deactivate ALL plugins and enable a default theme (I tested 2016 theme) , then log in as Subscriber via default WP login form (domain/wp-login.php ) and then you open your home url - this function will return 0 instead of current user id. So, first of all, you should fix this issue before testing Membership Pro plugin or probably it will be better, find more safe way to relocate domains.

    Best,
    Ivan.

Thank NAME, for their help.

1 Point
5 Points
15 Points
Other

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.