We are nearly ready to launch our new website. We will be moving the site from the hidden link subdomain to the root hidden link domain.
When I did this step with another site I recently worked on, we had lots of problems with Toolset Views and Archives changing or disappearing. On that site I did a manual migration and a global replacement on all instances of the development URL to change it to the real URL. I was told by your support that was a bad way to do this.
I was advised to use the Duplicator plugin. The problem there is the Duplicator plugin has a very high failure rate with large sites. This site we will be moving now will definitely not work with Duplicator.
So do you have any other advice you can offer to avoid a repeat of the problems I experienced with the other site?
Hi,
Thank you for contacting us and I'd be happy to assist.
Have you considered using the Duplicator Pro version? It offers a number of optimization features and we at Toolset, use it for testing out customer websites all the time. Some of those websites are pretty large too, and the success rate is very high for us. In short, I'll highly recommend it.
Our second choice usually is "All-in-One WP Migration", for a few hosts and server environments where Duplicator Pro is blocked/restricted:
https://wordpress.org/plugins/all-in-one-wp-migration/
regards,
Waqar
Thanks. We'll try All-in-One WP Migration first. If that fails, we'll try Duplicator Pro.
However, I do have one additional question for you on this. Will these options change URLs that are hard coded? That's why I would use the global replace approach in the database to cover ALL instances where domain changes are needed. I have MANY instances of URLs that need to change in pages and HTML widgets, custom menu links and such. I never had a problem with that approach until this first website with your Plugin installed where the migration somehow messed up several Views and archive pages built in Toolset.
If All-in-One WP Migration and/or Duplicator Pro won't change those hard-coded URL instances throughout the site, do you have any suggestions for something that would cover those instances as a second step that won't break Toolset functionality?
This next site that this account covers has MUCH more functionality built into it using Toolset. So if I encounter similar problems, it's going to be a considerable amount of work to have to make sure anything that breaks is rebuilt properly. I'm hoping to avoid that problem this time.
Thanks for writing back.
Yes, both these plugins (and other similar plugins too), apply extensively 'search and replace' operations at the database level, so you'll be covered in that aspect.
However, if you've added some hardcoded URLs in any files (e.g. in theme files), you may have to change them manually, after the migration.
OK, I'll give it a go then. Since you provided the solution that worked in my only other active ticket, I believe this site is now ready for launch. We'll launch it during the overnight hours so there won't be many or any people on it in case something goes wrong. Please keep this ticket active so I can ask further questions related to this should that become necessary. Assuming no major problems, I'll have this done before the weekend.
Great! Good luck with the launch and hope everything goes on smoothly.
This ticket will stay open for a couple of weeks and let me know if you need any further assistance with this.
I don't think All-in-One WP Migration is going to work. It's saying my max upload size is 512MB, but the backup made by All-in-One WP Migration is 4GB+. So I'll have to get a premium plugin (either Duplicator or this plugin) and hope there aren't further issues with this.
It's easier for me to do this manually than to do battle with these plugins for success. I'd rather not have to inform the client that they have to purchase yet another premium plugin just for this when I can do it manually. Can you give me any further direction for avoiding having Views and archives break when doing this manually? These problems with Toolset are the only time I've had problems with the manual migration approach.
Our ISP suggested that using wp search-replace in SSH might be a better way to do the global replacement in the database than the way I was doing it before.
https://developer.wordpress.org/cli/commands/search-replace/
Do you have any thoughts on this possibility?
I don't know what it is about the manual approach that caused our Toolset Views and Archives to break as they did.
I haven't personally used this "search-replace" method, but the link that you shared does mention:
"Search/replace intelligently handles PHP serialized data, and does not change primary key values."
So this sure does sound like it should work better than the manual search and replace, which doesn't take into account the sterilized data.
