![]() We also needed to trick MAMP into using connecting to local mySQL server through socket /tmp/mysql.sock a another huge thank you to for solving this and especially this line of code ![]() bash_profile of the user account to map mysqldump correctly so it would work with wordmove. Side notes: we needed to add the following “export PATH=$PATH:/Applications/MAMP/Library/bin” to the. So it turns out that you need to install a higher version of Ruby when using wordmove along with lftp and then need to be really really REALLY careful with syntax when creating the movefile… lets just say we hit a snag and we would like to give a huge shout out to Reddit and especially hurenkind5 for all their help troubleshooting with us . It is at this point that we would strongly suggest checking out the wordmove wiki for the right way to do things…. Once this was installed it was a matter of installing wordmove using the following cmd “gem install wordmove” or so we thought. So for those of you that might want to go down this route as we did here’s what we did.įirst off we decided to install MAMP on our local machines this works for us but there are many many other MySQL Apache PHP stacks out there to be used such as XAMPP, WAMP and AMPPS to name a few.Īfter the local stack was installed we decided to install Homebrew a package manager for OS X. After much looking we came across wordmove on github and the below video. The first thing that came to mind would be to configure GIT in someway or another to help in the process but we decided that this was not going to work for our projects. So we needed to figure out a system that would not cost the client anything and work with the limitations of shared hosting. In fairness freistilbox is offering fantastic prices for their services but some clients just like to stick with what they know and use shared hosting. ![]() In an ideal world we would have all our sites on hosting providers like or pantheon.io with multi development environments that allow for the free flow of information between development environments, but not all our clients can affored these services. Normally this wouldn’t be too much of an issue but it just so happened that the connection speeds were shocking and with the server timing out it became a bit of an BIG issue considering the core of WordPress is 1471 files and there were about 5k+ extra files that came with the new website which included the additional plugins and client files to make up the website.Īfter this we decided to take a long hard look at what the most efficient way to transfer files from one environment to another. This in turn caused us to have to unzip the duplicator file manually on the local environment and then manually upload the files one at a time. The issue occurred due to the length of the file paths and the server timing out during the install process. However we recently ran into a fairly big issue with one site was when extracting the Subdomain Duplicator files on a live website. The obvious downside to this was that you could / might miss some information along the way if the live site was updated during the migration process and you would have some downtime of the live site while the new subdomain site was being unpackaged. Once we had created these two backups we would then FTP into the live environment delete all and then FTP in the newly developed subdomain duplicator file to the live environment run the installer we would have a brand new website up and running. Once we were happy we would use the Duplicator Plugin to package up that live website as backup and then the subdomain environment. Our normal practice was to create a subdomain for the new website (then we would build out the new site on this subdomain. We decided to start to look at our development environment and how we migrate information from our local machines up to live sites. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |