Ah! I see. You are correct, you have your own DB, it’s just a matter of figuring out how to access it. My previous post was based on some assumptions that turned out to be incorrect. Vagrant and Puppet are quite useful since they make setting up an environment such as yours fairly simple. They pretty much do all the setup for you. The problem is you do not have a good idea of what was done since you had no hand in it.
I’m not familiar with your specific environment, but I can assure you that you have a mySQL DB somewhere that contains your data. I don’t know why your mySQL console doesn’t report any DBs. It may be connected to an inoperative DB server. Unless you are a really big command line fan, the console is not all that useful IMO. I think most people prefer to interact with their DB through a GUI interface, usually phpMyAdmin, which is a web app, thus accessed through your browser.
First we should be sure the data in local-config-db.php is actually the correct data. This is not a standard WP file. The usual location for this data is wp-config.php in the WP root installation folder. Is the same data defined there? Or is local-config-db.php referenced with a require or include statement (or the *_once variants)? Whatever definitions are established in wp-config.php, whether by direct code or referenced file are what WP is using.
Being unfamiliar with your environment, I couldn’t say if phpMyAdmin is available or how to confirm it’s existence. If there’s no phpmyadmin folder in your html (or public_html or whatever serves as the server’s public root) folder, there would be an alias setup in the Apache configuration somewhere. Assuming you access your local server as localhost, phpMyAdmin is typically accessed as localhost/phpmyadmin/ in your browser. If that’s correct, you’ll get a login screen where the username and password that WP is using will get you in.
Once in, all DBs are listed on the left sidebar. It’s normal for there to be a few others besides the one for WP. The one you want is the one defined as DB_NAME in wp-config.php. Click on that DB. All the WP tables will be listed. If you go to the posts table, you’ll see all of your posts and much more. Never change anything through phpMyAdmin without first making a complete backup. It’s very easy to completely ruin the DB with phpMyAdmin!
It’s a good idea to learn how to make DB backups with phpMyAdmin. Click on the WP database again, then go to the Export tab. The defaults are usually just fine. Click Go and save the file somewhere safe. There’s no particular reason right now to have a backup other than it’s always a good idea ??
If that all worked out, you’ve identified the correct DB and you know how to directly access the data kept there. While there shouldn’t normally be a need to use phpMyAdmin at all, it can be very useful in development work or for fixing an unusual problem with WP, like resetting your password when the server’s email service does not work (common on localhost). While all this is useful information, it doesn’t answer your original question about how the import process works.
I’m not exactly sure what Vagrant and Puppet did beyond doing for you what is normally done manually. I do know what the manual process is, that I can describe. It’s reasonable to assume the same was done via script. I’m not sure what you started with, so I’ll start at the beginning.
The Apache server and mySQL server need to run in a Linux O/S. Since most of us do not run Linux, we setup a virtual machine that runs Linux. On this virtual machine Apache and mySQL servers are installed. The core WP files are downloaded from wordepress.org repository and placed in the desired installation folder in Apache’s server space. Typically the install.php script is run to setup WP, mainly by creating a DB and adding empty tables to it. Since we are cloning another site, this is not always necessary, depending on how the import is accomplished.
To clone a site, all the files in the original wp-content needs to be copied to the target installation. Additionally, the DB needs to be exported. While this can be done with the .sql backup file from phpMyAdmin, WP can also export content using XML files. .sql backup files can simply be imported in phpMyAdmin. The files are a series of SQL queries that create tables as needed and populates them with data.
With XML files, some kind of script needs to parse the files and add the data to the DB as it goes. This is commonly done with a WP plugin, but in your case Puppet handled this for you. XML files are very structured, so it’s a relatively simple script that reads each XML tag and associated data. The tags tell us exactly what sort of data is provided, so the script knows exactly what to do with each bit of data, whether it goes into the posts table, postmeta, options, or what, and in which column each bit of data is to be placed.
Once the wp-content files are copied and the DB populated, we are not quite done. All the site links in the DB, plus the settings in the options table all point to the source site. These references need to be changed to localhost references. Whether the import script does this as it goes or after the fact matters little, as long as it is done. With manual imports, we still use some kind of script to do this, as managing serialized data cannot be handled with a normal text editor search and replace.
Probably way more information than you anticipated! Hopefully at least some of it is useful.
