I’m trying to use VVV, a Vagrant project dedicated to WordPress, to learn and practice developing a local website.
A few days worth of looking and learning led me to understand one of the key things to transfer a database from one server setting to another.
Indeed, VVV recommends setting up default websites from files pulled out of their github repository. These default websites have names like wordpressone.test or wordpresstwo.test. I made a third one with my own site name, workingfreshangle.test, that had the settings of their standard “mytest” option. I simply un-commented the relevant lines in the config/config.yml file and replaced “mytest” with “workingfreshangle”.
It worked, in that I had the content of their standard “wordpresstwo” website on a local URL called “workingfreshangle.test” .
It honestly took me a while to get that far, since I first thought I could save time by trying out their options to clone an existing website repository, which I already have set up on github for my freshangle website (private). For example, I twice uninstalled and reinstalled both Vagrant and VVV because I messed up with so many configuration files that I couldn’t remember which ones to replace with default files and which to leaves because they were as yet untouched. On a slow internet connection this is frustrating.
The next step was to hollow out the default website and replace it with a copy of my own.
There are two parts to this:
- the WordPress install files, which include the theme set up on my original server.
- the database itself. My server provider stores the database in a different area, so it isn’t in the same place as the other WordPress files.
First, I tried connecting the database up. I found out how to download a backup of my database, and what the basic database information was: database name, authorized user and the user’s password. I’m still a bit confused when it comes to the database host, because the “Database server” address didn’t seem to pull through. I suspect, though, that this is just because I only have a “Pro” plan with OVH, my provider. They had already denied me SSH access when I had the “Personal” plan – and it took me a whole day to find out that I needed to upgrade to pro just to have my SSH access. There wasn’t a single mention of this in the error messages I got when trying to ssh “in” my server.
I don’t like it when major corporations make things confusing. And I also don’t like it when you have to have an upgrade just to be able to do one of the most basic things in web development. It’s kind of like buying a car, then having to upgrade once to be able to back up, once more to be allowed to use the gearbox or cruise control, and yet another time for them to grant you access to side and rear view mirrors. All while never telling you that these options you’ve been reading documentation and forum questions about are simply not included in your plan!
So anyway I realized that no amount of tweaking the config file could get my local instance to fetch its data from the remote server.
As a fall-back, I decided to download a back-up of my website database, and install that on my computer in such a way that my local server and browser could access it.
OVH quickly sent me a file with my database back-up, which I downloaded. It was a .gz file, which no native Windows app can unzip. I was tempted to ditch Windows for Linux at that point. Developers always assume linux, so that would have spared me lots of time seeing whether their answers could be transcribed into Windows. I decided to download 7Zip instead. It worked and gave me a file with no extension. I could open it in sublimetext. (I later saw that I could import the file while still zipped, which would have saved me a few hours).
I had no idea what do to with that extension-less database mysql dump file. None of the VVV documentation explained where to place it or how to integrate it into the VVV image. The closest hint was this sentence :
I will probably realize in 6 months that this is of course something very basic, like A-B-C simple. But I don’t know that yet, and it’s frustrating, especially for something as noob-targeted as WordPress, which VVV purports to facilitate.
After all, I’m the kind of guy who edits documentation to replace acronyms with cleartext.
I hit a gold mine in one of the solved and closed issues related to databases and VVV, right here:
Hey @woshj you can use Sequel Pro or PHPMyAdmin to import the sql file. Keep in mind that an sql file isn’t a database, it’s just a text file. with. all the SQL commands to recreate the tables and their. contents. You can access PHPMyAdmin via the VVV dashboard on the righthand sidebar, and. there’s a Sequel Pro connection file in the
databasefolder you can use to set up Sequel Pro fastYou will also need to adjust your
wp-config.phpto have the same salts as the production site, otherwise the passwords won’t work. The same goes for all the plugins and themes.You might also need to do a search replace on your database after importing to change the production site URL to your local URL.
but now just displays a blank screen
Check your PHP error log, but, keep in mind that if your production site uses the ABC123 theme, you will need that theme to be present or WP. won’t be able to load it and you’ll get a blank frontend.
Fundamentally, there’s nothing VVV specific about this, if anything, standard WP migration guides and techniques should work for you.
Tom J Nowell
From the first part, I understood this:
- the importing of my downloaded database backup file must be done in phpMyAdmin. Open phpMyAdmin from the vvv.test dashboard. Login and password are whatever you set them to be in vvv-local/database/sql/init.sqo
- I would need to delete the innards of the standard default workingfreshangle database, and then import my backup inside it.
To delete the innards, on the left side panel of phpMyAdmin, select (click) the default database you want to eviscerate, like so:
And then, to empty it, select all tables with the Check all button, and in the drop-down list nearby select “Drop”. It prompts you with a red message, checking whether you’re really sure you want to delete all these tables, click yes after verifying that you’re on the correct database.
Then, an empty database name appears, with no tables. At this point, click the import button. That’s when I went to fetch that weird extension-less file and it loaded into the empty database, populating it with tables and all!
Hooray!
Almost. There was no more database error, but there was still a problem: blank page.
Luckily, the quote from above catered to that small issue:
if your production site uses the ABC123 theme, you will need that theme to be present or WP. won’t be able to load it and you’ll get a blank frontend.
Quick check on production server, my current theme is twentynineteen. The three default VVV-loaded themes are twentytwentyone, -two and -three.
Quick check: though the screen is blank, I am able to call up the /wp-admin/ page, and log in there. Interestingly, it still refers to the original website for authentication, but the URL seems to show that it will redirect me back to the local version of the site once I’m in. Let’s see.
Dead end. That just logs me back in to the production admin back-end. Sorry for raising your hopes there.
Next thing: copy over current twentynineteen theme files from production to my workingfreshangle local folder, next to the three existing theme files.
All right, finished copying. Now will test the workingfreshangle.test again.
Hooray! This time, it works! The whole website appears. The twentynineteen theme displays properly. The content is as it was when I did the backup.
Since I’m writing this post from production, I’ll just go ahead and publish it. Normally the content on the local site shouldn’t change.
Correct! See screenshot below: both websites are active, the unupdated local (left) and the updated remote/production server (right)
Summary:
- Install Vagrant, VirtualBox, VVV.
- Modify the config/config.yml file, uncommenting and replacing “mytest” with a name for your own project. In my case, “workingfreshangle”
- Run the vagrant box with
vagrant up --provision - From your web hosting provider’s dashboard, download the most recent backup of your database. Unzip it (or not). Check the table prefix and jot it down. In my case, I didn’t need the database name nor the username/password.
- In the newly created www folder, find the folder for your own project (“www/workingfreshangle” in my case), enter the /public_html/ folder, and open the wp-config.php file. Modify the table prefix to the one you noted just above.
- From the VVV dashboard, open myPhpAdmin by clicking on the button (username and password are defined in vvv-local/database/sql/init.sql). Navigate to your working local database, and clear its contents by selecting the tables and “dropping” them.
- With that same (empty) database still selected, import the backup of your production site.
- At this stage, clicking on your test website’s link from the vvv dashboard might get you a blank screen if themes don’t match.
- Copy over the relevant theme folder from your production server or repository to wp-content on your local computer inside the vagrant VVV folder. Voilà!
Last thoughts:
- There must still be something wrong, because I didn’t use my original database credentials given to me by my website host provider.
- Also, trying to log in to the back-end will redirect me to the production website.
- Edit: it seems this last problem might be related to the wp_options table: that’s where basic information related to the website is stored. It doesn’t contain anything about content (no posts, users, uploads, etc).