One of the great lessons that have been applied to the development of sites with WordPress, and of which I am particularly keen to lecture is the need to maintain a local version development as close as possible to what you use in production, which also It is supported and supports a lot of other good practices such as avoiding cowboy coding, using version control, etc.
Since the client is not one of the objectives of the project, the ability to import a database to have a replica of development should be simple and quick to implement. Although there are many plugins and tools to do so, for me the easiest way is to use very basic through the command line tools.
To generate the export of database I prefer to use the mysqldump tool, which probably included debiese come to install MySQL.
You can use the following command to generate a "dump" which is more friendly with version control system (although this may not be the best idea) and faster import:
mysqldump --skip-extended-insert --no-autocommit --single-transaction dbname> backup.sql
If you need to download this support from a remote network, you can export and compression in a single pass with:
mysqldump --skip-extended-insert --no-autocommit --single-transaction dbname | gzip> backup.sql.gz
With this, the speed that generates the support is significantly higher than what you would expect from phpMyAdmin or WordPress plugins.
URL replace references
In a WordPress site, the main URL of your site will be in a lot of parts, for example links between posts, navigation menu items, settings ... but fundamentally also plugins will be in two base camps Data are what determine the URL of your site: the home site url options and table settings.
To be able to run the site locally'll need at least modify these options, but to make it the fastest way you can change as often as the online URL appears for a development domain, you can do with:
sed 's / www.foobar.net / www.foobar.dev / g' -i backup.sql
www.foobar.net site URL is online
www.foobar.dev is the URL you use in local development
backup.sql is the database dump (uncompressed)
This command will replace all URLs in the same file. In OSX this is a slightly different syntax, but you can also choose the version:
sed 's / www.foobar.net / www.foobar.dev / g' backup.sql> local.sql
This is necessary to make several points: ideally, the production domain and local development must have the same number of characters, as otherwise all information stored in serialized data will be corrupted and will be empty. That is, complex configurations of plugins, widgets settings, theme options, serialized metadata posts or users.
As you can see there is a significant constraint that would be ... if it were not because you can shape your development environment to avoid problems with this.
Already in the final step, one can only import the database. If you saved the credentials to access MySQL in your home directory, this is as simple as:
mysql dbname <backup.sql
Otherwise, you need to use more options, such as:
-user mysql -p dbname <backup.sql
So that the user specified database is used and you ask the password (which is also better if you can not secure access to your home directory).
Again, here the importing speed is significantly higher than what you can get with phpMyAdmin or other tools, as you will be importing data "hotline" to the database server.
You also have the advantage that they (usually) do not have problems of weight limit of the file you want to import - here again there are some outstanding issues on OSX, depending on how you have installed MySQL, but even then you can import large databases .
(No) to synchronize uploaded files /
Finally, for a full replica can you synchronize the files in the uploads folder with rsync, which is a very powerful and useful tool ... but you can also have such reliable results but without lowering tens of GB configuring your web server and reverse proxy.