Applicable to:
- Plesk for Linux
- Plesk for Windows
Symptoms
After performing a Website Copying from WordPress website example.com to example.net, the copied one (example.net) redirects to the main domain (example.com).
Cause
As the Website Copying function creates the exact copy of the site, the WordPress URL and wp-config.php file are not changed.
Resolution
Note: The best way to copy a WordPress site in order to avoid the issue described in this article is to use WordPress Toolkit Cloning feature. WordPress Toolkit will handle the changes automatically. In case cloning is not an option, proceed with the following resolution:
After copying a website and its database the following needs to be done:
1. Connect the copied website to the appropriate database:
b) Retrieve the Database name, user, and the password from the copied website at Domains > example.net > Databases:
c) With that done, go to Domains > example.net (copied website) > File Manager > httpdocs > and open the wp-config.php file;
d) Correct DB_NAME , DB_USER , and DB_PASSWORD with the information taken on step 1-b;
2. Define the address of the new website in WordPress settings through WP_HOME and WP_SITEURL variables in the wp-config.php file according to this guide.
3. Go to Domains > <copied_website_name> > WordPress
4. Update Access Credentials if it is required.
Note: Some plugins can be configured to redirect the website to the other website. In this case, disable plugins one-by-one and check the website availability.
Comments
23 comments
I wish I never had pushed on Copy Data. The copied website is being redirected to original domain and no way to get it back. We used backups, no luck.
Can somebody tell me which files we have to check so the dahm redirect is gone?
Hello,
As it said in the article, first of all it is needed to connect new database to the copied WorPress website. For that, please go to Plesk > Websites & Domains > example.com > Databases and check what database name, username and password are defined here. Once you have these parameters, please define them in /var/www/vhosts/example.com/httpdocs/wp-config.php file (DB_NAME option for database name, DB_USER for database user and DB_PASSWORD for user's pasword)
Then please insert the website's name in the same file. Just add WP_HOME and WP_SITEURL variables inside as it is described on WordPress official website:
https://codex.wordpress.org/Changing_The_Site_URL
Also, it is needed to check the database of the destination website and pay attention to
wp_optionstable.Reply me if you need more information on this.
The resolution given does not work properly either. You say the best way to copy a WordPress site in order to avoid the issue described in this article is to use WordPress Toolkit Cloning feature. And that the WordPress Toolkit will handle the changes automatically. Unfortunately cloning the website gives the same problem. In first instance it looks like everything works fine, but since a few months the cloned website switches back to the original (the cloned) domain after a few days.
Please solve this Plesk issue. With kind regards, Martine
Hello,
There are no preconditions when Plesk or WordPress Toolkit could revert back changes in cloned WordPress instance. Especially considering, that it was working fine for several months.
Most probably the backup of staging website was restored to production instance and overwrote database and "wp-config".
I think you misunderstood me Alexandr Nikolaenko.
The cloned Wordpress websites are not redirected after working for several months.
It is SINCE a few months that cloned Wordpress websites get a redirect to the original domain after a few days... Before (let's say February, March 2019) I did not have this problem.
Hi @Martine Kooi,
If the issue can be reproduced on your server in the following way:
we will be glad to investigate this issue deeper
Please create a request to the Support Department:
How to submit a request to Plesk support?
HI @Nikita Nikushkin,
I've had a similar experience, however it does not seem to be a redirect that happens.
The entire webspace seems to be "copied" from the initial source, as if it had never been cloned through the WordPress Toolkit Cloning feature, just simply copied over.
The database related to the "new clone" seems to have vanished, the wp-config files seems unchanged as mentioned above, so when opening the page it simply fetches the config for the source page. And thus opens and redirects to the source page rather than opening the cloned page.
Steps used to clone:
1. Create new webspace with new domain (it installs WordPress as default)
2. Go to "source webspace" Select "Clone" from the WordPress Toolkit
3. Select "use existing domain or sub domain"
4. Select the new webspace/ domain that was just created
5. Hit start.
Everything seemed fine at this point, new page loads ok with new domain, changes can be done, and no changes is done to the source page (so they are acting independently).
This was done on sunday 23. june. I noticed the issue just today friday 28th of june
Hello @Thomas,
I followed your steps but was not able to reproduce the issue - cloning feature works as expected
However, please make sure that all Plesk updates are installed and try to reproduce the issue again
If it still occurs we would be glad to take a look at the issue - please submit a request to the Support Department
We are having the same issue with cloning reverting. The clone works fine for 4 or 5 days and then the wp-config is overwritten, pointing back to the site that it was cloned from. The DB associated with the site reverts sometimes as well. When we detatch and reattach the wordpress instances it seemed to have helped, although we still run into it. We've had approximated 10 sites revert over the last few months, which is a big issue as they are all production. There is certainly an issue with cloning and we have opened up two tickets. Both times, they were not able to help us as the issue only happens several days after the clone.
Logs are not very helpful, but the problem happens on a physical hosting updated event (I believe).
I'm glad we are not the only one with the issue.
Hello @Scott Ashman,
Support Department tried to reproduce the issue as well, however, it is reproduced under specific conditions only, thus it is hard to catch it
Nevertheless, we had a case when a WordPress Backup Plugin, e.g. "UpdraftPlus", led to such behavior
Plesk clones 1:1. Thus, the configuration and settings of the plugin are copied as well. It leads the situation that the plugin contains information about configuration files from the old WordPress instance. After some time, this plugin replaces the config file for the domain as it differs from one presented in the plugin repository
If it is not your case, I suggest to perform the following steps on your server:
1. Create a new domain
2. Install WordPress on it
3. Remove all plugins
4. Clone a WordPress website
5. Monitor the config file
If the issue was not reproduced, check the plugins on the instances where the issue was found. Some of them could lead to such behavior
If the issue occurred again, please create a new request to the Support Department with providing this information
We will be glad to take a look at your server and find the root cause of the issue
My first post is from March 01, 2019 and you still have not fixed this....
Hello @Mike,
The behavior from this article is an expected one, Website Copying makes a copy as is.
As described in Resolution section, for WordPress copying there's a special function: https://docs.plesk.com/en-US/onyx/administrator-guide/website-management/wordpress-toolkit/access-wpcli.73391/#cloning-a-wordpress-website
Appreciate the reply Ivan. I've looked over the plugins on the sites effected and there isn't anything that should be touching wp-config.php. Plus, please note that the database listed in wp-toolkit is also reverted, which a plugin wouldn't be able to modify. I can only see that changing if perhaps you are re-scanning wp-config.php and setting the db based on that.
Finally, we always see this event when it happens :
server1.iad1.xxx.com APP 3:45 PM
Some events have taken place at server1.iad1.xxx.com
Physical hosting updated
These are all controlled sites, the end user has no access.
@Scott Ashman, could you please create a new request to the Support Department in order to take a deeper look.
We have monitored some of our deployed websites closer in regards to this issue for a couple months now, and it seems for us to be related to the plugin "All in one WP Migration" and specifically if there is a backup present on the site. A site only having the plugin installed is not affected.
@Thomas
Can you please clarify the steps to reproduce it once again? Should this plugin be installed on the source WP site or on the target one? The plugin's backup is not restored after the cloning, is it?
Don't know if this is resolved but I've just had the same issue today.
I've spent over 50 year as a programer, systems analyst and forensic systems analyst so don't easily give up.
I am also a web hosting re-seller so am in a better situation than some to investigate and back track.
I started building a test web site and then cloned it to a second web site as a testing environment for live users. This was then cloned to an absolutely live site for public consumption.
The live site was still linking to the original.
After much digging in the wordpress engine I suddenly noticed that all the links in the top menu were still pointing to the original site. So: -
from the appearance/menus/top menu I deleted the home page and reloaded it in the top menu. This appeared to sort out the rest of the links in the top menu and most of the other links as well.
I use paidmembershipro as a membership system and this was still pointing at the old site. As this new site has yet to go properly live and has no members I simply deleted the plugin and re-installed it. That seemed to fix that URL problem. Had I been live for some time It would have been more complex.
Some other plugins may need to be addressed for you, my other plugins appeared to be working.
To sum up: -
The wordpress tools do not clone properly. It does not do what it says on the box.
I am not concerned with the results that Messrs Plesk Support get when trying to emulate the system and faults, I am only concerned with the results I get.
This was a quick and dirty fix for a problem that would not have happened if the clone option functioned properly.
I hope all this helps somebody.
Ian
Hello Ian,
Thank you for sharing your feedback.
As I understood the issue has appeared not with website copying but cloning: it is definitely worth checking. To find root cause why after cloning website still points to the original one additional details are required. If the issue re-appears, please, feel free to submit request to support for investigation: https://support.plesk.com/hc/en-us/articles/213608509-How-to-submit-a-request-to-Plesk-support-
Not sure if this will help anyone with the same issues above - but we ran into the same thing. We had a functional and completed wordpress build and staged on a sub domain ready for proofing and production. In the past, when we are ready to move it live, we've used Updraft Plus without fail, but have noticed some irritating problems when the site is using certain plugins. Decided to use the cloning feature in Plesk. Clone looked good, logged into Wordpress dashboard on permanent (new) domain. Everything looked slick. When pulling up the new, permanent domain, however, - it redirects back to the staging site's domain. And yes. wp-config looked fine as it was pointing to a newly created/named database with new permissions.
Having read Ian's post, I thought to hit a random full url on a subpage of the permanent domain (e.g. domain.com/about-ducks). Low and behold. That works fine and remains in the correct domain. It turns out the problem is/was just the index page. We then deleted Updraft Plus and tried something that has worked for us in the past. To force a refresh of things, go to settings / permalinks and select a different method of linking. Doesn't matter what you choose. You can change it back. Save it. Once the page reloads defaulting to a new permalink structure, go back to the original one and save it again. Works for us. For some reason that "rebuilds" or flashes the linking structure and it will point to index on the correct domain.
To be clear. All pages NOT home/index were loading correctly. It was only the index/home that incorrectly loaded the cloned domain (staging site). Once changing and re-saving permalink settings, all links work as they should.
Hopefully that helps someone in the same situation as us.
Hello @James,
Thank you for sharing your feedback.
The described behavior is quite strange and interesting, so if you meet the same issue again and find a way to reproduce it please consider submitting a support request for further investigation: https://support.plesk.com/hc/en-us/articles/213608509-How-to-submit-a-request-to-Plesk-support-
James is describing exactly the problem I am having. I too, can access all but home page (it redirects to true site domain immediately on load). Plugins shut off, simple .htaccess file, all config and db connections correct with newly copied/cloned db. I did the permalink switcheroo thingy and VOILÀ! Success! Would be nice to know why, though. Thank you, James.
I can confirm the issue above, that previous users have faced, is still happening. Cloning and pushing to live does not work. Using the Wordpress Toolkit to do this does not work.
If you...
Further to this, if you perform a restore of the original site from a backup to undo all of the above, this also now does not work.
So, if you...
This is clearly a problem Plesk needs to address if it is still being brought up in 2022.
Unfortunately for me, James Moseman trick of changing the permalink structure did not work for me. I ended up having to use Softaculous to bring the Wordpress install in and clone and restore from there.
If Plesk could fix this, it would be great. It doesn't give me confidence in their "Smart Update" feature working, either, as that is essentially a clone and push to live process.
For reference, I did not have a software backup plugin installed that could cause any issues, and all caches were cleared and turned off (including server Nginx) before starting this process.
For now, I am sticking with using Softaculous to manage clones, pushes to live, backups, and restores of my sites.
I also ran into this problem and I did get it fixed. Here are my comments:
1. Instruction 1b above needs to be fixed. It says "Domains > example.net > Databases:" when it should say "Domains > example.com > Databases:". The screen shot is showing the ".com" example. Obviously that's the info you're trying to direct people to.
I did the modification of the wp-config file to point the live site to attach to the database of the staging site. I also edited the options tables in the database. It was still not working. I logged into the site and noticed some of my layouts were not looking quite right (columns were gone in my layout setup). I wasn't able to log in for a moment and wasn't sure what happened, but the site was still coming up. The same problems were happening with the staging database in use. The home url and a couple others came up right, but then I found myself on the staging url and all links were showing they'd go to staging. So I could tell that whether I was connected to the live site's database or the staging database, the same behavior was happening. I then reconnected the site to the live database again. After running the permalink change suggested by James, and verifying the URL and name in the Settings, I found the site looking right, and suddenly everything seems to be fixed, running on the live site.
So I did some of these suggestions and while I can't say what order of them worked, it did work and I do have this solved. That's the best I can share to add to the conversation. Thank you all for what you shared so far.
But yes, instruction 1b does need an edit.
Please sign in to leave a comment.