Domain Mapping migration redirects to old domain

I am in the process of migrating a multisite instance to WP Engine. I have the filesystem copied and an unmodified database loaded. Also wp_home and wp_siteurl in wp-config.php overridden to a DNS that will work as the "original domain".
But Domain Mapping is being clever and decides that the request has come to the wrong URL and keeps redirect to the previous URL.

  • Ash

    Hello David King

    Even after reading, I am still a bit confused, I am sorry. Do you mean, you created a test instance voices.MAIN_DOMAIN.com to SUB.wpengine.com? And both are multisite, not url of a subsite, right?

    Also wp_home and wp_siteurl in wp-config.php overridden to a DNS that will work as the "original domain".

    How did you overwrite from wp-config.php? Using any define? If so, that define doesn't work well for multisite.

    But Domain Mapping is being clever and decides that the request has come to the wrong URL and keeps redirect to the previous URL.

    Besides, Domain Mapping doesn't set any redirect for the main domain, only the subsites. What happens when you deactivate domain mapping in test site, does the domain work by then?

    Please let us know about those. Also, if I got it wrong, please pardon me and explain a bit.

    Have a nice day!

    Cheers,
    Ash

  • David King

    Hi Ash,

    NB: I think the situation is resolved thanks to this article, however I'll explain what the issue was (for the benefit of anyone else reading this) and mark it closed.

    Even after reading, I am still a bit confused, I am sorry.

    Yeah, sorry, not the best OP but I didn't directly enter it, the ticket was created via chat support. I really should have begun by posting here rather than trying chat, but then I'd never tried chat support before so I thought I'd give it a try.

    To rephrase the issue: that we're migrating a WPMS instance running DM to WP Engine should be clear enough, but I don't want to risk substantial downtime (either because there is something peculiar about our instance that would take time to diagnose or else find that DM is somehow fundamentally incompatible or problematic with the way WPE works) by just taking the plunge and migrating the site and DNS entries 'on faith'. So I want to test it first.

    Normally, when I want to test something on a staging platform, I sync the filesystem, dump the live DB and load it into the staging DB. Then I do certain PHP-safe search-and-replace to substitute the staging URL for the live original URL and I have scripting that deletes all mappings (also jetpack! for anyone else reading this; fail to delete the 'jetpack_options' row from each table, and you'll really screw your jetpack instance! At least, this was true once upon a time) because it wouldn't normally matter on a staging instance — but DM is one of the most critical things to test so that isn't an option this time.

    Problem is, I normally do this all from the shell, but WPE don't offer shell access, only sftp, plus there's a bunch of transparent stuff that happens in between that I don't know about. They also rewrite bits of wp-config.php automatically, so there are constraints on what can be put in there.

    They do have phpMyAdmin, but it has an upload limit of 10 MB and our dump is about 600-700 MB compressed, so I have to sftp it to WPE and get a WPE engineer to load it from their end.

    The search-and-replace tool is nominally web-based PHP (though it has a CLI interface, too) so it probably could be used with WPE, but it would probably fail because of execution time limits. A DB-wide search-and-replace takes over half an hour on our instance. Also, it might annoy WPE because of the amount of MySQL activity it would generate.

    That all aside, I used a domain name that happens to be a SAN in our SSL certificate that I don't need right now but can map to some suitable site in the staging instance on WPE, but of course that domain name isn't included in table wp_domain_mapping so first we have to get into the dashboard to add it, and this is where the problems begin because our instance is set to force the original domain for wp-admin and wp-login, but the original domain in DNS still points to the live site.

    wget --user=user --password=pass --no-check-certificate -v -O/dev/null https://account.wpengine.com/wp-admin

    and you get (trimmed and redacted):

    HTTP request sent, awaiting response... 401 Unauthorized
    HTTP request sent, awaiting response... 301 Moved Permanently
    Location: http://account.wpengine.com/wp-admin/ [following]
    HTTP request sent, awaiting response... 302 Found
    Location: http://live.domain.com/ [following]
    Connecting to live.domain.com (live.domain.com)|x.x.x.x|:80... connected.

    The reason for HTTP AUTH is to disable WPE's varnish cache. We don't want stale cached objects interfering with our diagnostics, so that explains the first 401.

    The second request is a repeat to the same URL with the HTTP AUTH headers, and you see it try to redirect (for some reason?) to the non-SSL schema at the same URL again.

    The third attempt results in a redirect to the live domain which, of course, works, although note how it redirects to the root site URL rather than its dashboard, which is doubly not what we want.

    The reason for the --no-check-certificate is because the temporary domain being used as the 'original domain', what you called SUB.wpengine.com, is not in the SSL certificate, although at this stage that isn't a problem yet because we're getting redirected incorrectly. As it turned out, there is a bug in WP Engine's third-party SSL certificate support and so it was serving up a valid SSL certificate anyway, but that's by-the-by.

    Do you mean, you created a test instance voices.MAIN_DOMAIN.com to SUB.wpengine.com? And both are multisite, not url of a subsite, right?

    Correct, with the intention of mapping a spare domain that happens to be listed as a SAN in our SSL cert to test DM.

    Also wp_home and wp_siteurl in wp-config.php overridden to a DNS that will work as the "original domain".

    How did you overwrite from wp-config.php? Using any define? If so, that define doesn't work well for multisite.

    Yes, with the two defines. I would have expected that to work for WPMS in directory mode (as this is), at least, without DM involved. In the end, I edited the relevant SQL rows as described in the link at the beginning of this post at which point everything worked as it should.

    Besides, Domain Mapping doesn't set any redirect for the main domain, only the subsites.

    As you know, even basic WordPress has a very clear idea of where it "should" be and if it gets a request to the wrong domain, it will redirect the request to the right domain. This would be true even of WPMS+DM when accessing the root site.

    Thanks for looking into it anyway. So far as I can now see, things do appear to be working okay (but only by dint of editing the DB). That won't be a problem for the migration proper, because the DNS will follow to the new host, we're not trying to change any URL in the install.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.