Moving domain to a new WP install

We cannot log into russellteam.com. We migrated using Snapshot, but I can't verify just yet what's the cause of the issue. The migration went off without a hitch. I could log in fine. As soon as we mapped the domain, login access ended. I'm seeing the following error on login page:

ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.

Debug mode shows me no errors so far. I migrated to russellteam.dangeroustactics.com and I could log in fine. But as soon as I mapped the domain russellteam.com, all of a sudden I can't access the backend.

The original multisite where the site was located was demo.dangeroustactics.com. The one where it's been migrated is dangeroustactics.com. It worked great both before and after the migration. It's mapping the domain that seems to be what triggers the login issue.

Since the wordpress installs are both on the same box (we're consolidating everyone to a single WP multisite), all I did was move the site straight over and change the document root, so the domain would resolve at the right directory.

So far, I've tried disabling all plugins across the entire network. I've reverted to default theme. I've changed salts. I've checked wp-config and htaccess and don't see anything that jumps out at me. I'm kind of at a loss as to what I should check next. Any insight is much appreciated!

  • Kasia Swiderska

    Hello Christian,

    Where in wp-config.php did you place define('COOKIE_DOMAIN', false);? Was it before or after line /* That's all, stop editing! Happy blogging. */ ? I has to be before it. It should not break your network.
    Are you using our DOmain Mapping plugin? Did you enabled there cross domain login?

    Is it possible for you to grant access
    http://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/ ? (if you are using Domain Mapping plugin you would need to diable it to get into wp-admin)

    kind regards,
    Kasia

  • Christian

    Hi Kasia, I really appreciate the feedback. yes, I edited prior to /* That's all, stop editing! Happy blogging. */

    As soon as I removed that line, the sites all came back.

    I'm just now switching to WPMU mapping plugin. I've been using wp mu domain mapping for years without issue, but there's clearly an issue now, so I'm ruling out everything possible.

    I've enabled support access and welcome any and all feedback. Really appreciate the second set of eyes on this. I feel like it's gotta be some little detail.

    For what it's worth, if I rename the site russellteam.dangeroustactics.com, I immediately have admin access to the site again. And as soon as I go back to russellteam.com, the site stays up in a browser no problem but I go back to getting that cookie error and not being able to login. So it seems reasonable to me it's either gotta be domain or domain mapping related.

  • Christian

    I'm configuring your domain mapping plugin now. It appears you recommend cname for mapping a domain as opposed to A record. Perhaps this is part of the cause of the issue I've been experiencing? I've always set an A record and then changed the name in site settings prior to mapping a domain. Granted, this has been with wp mu domain mapping plugin, but I thought the approach was solid. I'll set a cname instead and see if it helps. Any reason I should remove the A record?

    I don't pretend to be a dns guru, just following the tutorials I've come across over the years. Thanks very much for the assist.

  • Christian

    Umm...so ok! I configured your domain mapping plugin and all of a sudden logins work again. I keep moving more and more functionality over to WPMU because the stuff you build just seems to work better.

    I honestly don't know why it's different (i'm running the old wp mu domain mapping on three other networks with no issues), but I'm very happy the site is working.

    One difference is that it seems I can now access the subsites through either their subdomain OR the mapped domain. Both routes seem to work fine. This is no problem as far as I'm concerned, but...
    1. does this represent an SEO issue?
    2. Is there any other reason I should be concerned about being able to access a client site via their subdomain as well as their mapped domain?

    Just a new paradigm for me in this area, so I don't want to make any assumptions. Thank you!

  • Kasia Swiderska

    Hello Christian,

    One difference is that it seems I can now access the subsites through either their subdomain OR the mapped domain. Both routes seem to work fine. This is no problem as far as I'm concerned, but...

    I checked domain you mentioned and orginal url redirects to mapped domain - so it doesn't look it avaliable from both urls. Maybe this was cache issue on your side?

    If you mean that you can access dashboard with original url - thats ok, that is no SEO issue, as long as front end resolves urls correctly.

    I'm configuring your domain mapping plugin now. It appears you recommend cname for mapping a domain as opposed to A record.

    If you read usage page you will see that CNAME is used when you want to map subdomain to your subsite - A record is used when mapping top level domains. So it depends on what do you want to map.

    CNAMEs are used for sub domain mapping. i.e. you want to map blog.userdomain.com to usersite.yourdomain.com

    A Records are for mapping TLDs aka Top Level Domains. i.e. userdomain.com mapped into usersite.yourdomain.com

    so you still should use A record for TLD domain.

    kind regards,
    Kasia

  • Christian

    I really appreciate that clarification Kasia. Thank you. Just to confirm, in 99% of cases we'll be doing TLD, not subdomain mapping. So it sounds like A record method is still the way to go.

    Just to confirm, accessing the admin via subdomain is definitely still possible after mapping and propagation have completed. I can cruise around the admin dashboard and always stay on the subdomain. I've never had that happen before with the last plugin we used, but I'm not concerned as long as it doesn't represent any negative SEO effects. Also, any attempt to access the front end via subdomain automatically redirects to TLD as expected. So I think we're good there.

    Clients can still access their dashboard via TLD without being redirected to subdomain, so it appears the dashboard can be accessed either way. Brilliant.

    Thanks again for the assist. Much appreciated!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.