Geekly Articles each Day
📜 ⬆️ ⬇️

WordPress Site Migration Guide



Every web developer regularly faces the challenge of migration. This includes the deployment (deploy) of a local version on a remote server, and the transfer of a working site from one server to another. Some printed publications for programmers are called “Cookbook” - which literally means “recipe book”. Recipes are many, which one is the best - a matter of taste. In this article, the author will tell you what technology he considers the transfer of a typical WordPress site to be optimal, and why.

Also, this material is suitable for those who want to learn more about backing up the site and its subsequent restoration. Because in fact it is two necessary steps for the implementation of migration.

Data backup


From a technical point of view, we have to make copies of the two components of the site:

Every web developer should take care of the integrity of website data. Therefore, as a rule, after the working version is deployed on a remote server, the site developer sets up data backup or “backup” (from English “backup copy”, backup).
')
Sometimes taking care of creating backups is manifested by a hosting company. This most often happens when you use a simple website hosting service.

What is the main goal of the developer when transferring a site from one server to another? Nothing to lose. That is, at the new site, the site should be completely identical to the same site on the old one.

First of all, you must make sure that after creating a backup copy of the site, no changes will be made on it.

The easiest way is to appeal to all editors of the site with a request not to make changes to the contents of the site during the transfer (for example, for the next half hour). If, for example, you run a blog on WordPress , then there is no need to negotiate with anyone.

In the case when there is no such possibility, it is necessary to transfer the site to the maintenance mode.

Maintenance mode


You may have noticed that when WordPress updates the plugins or the core of the system, site visitors see a white background instead of its contents and over a large heading “ The site is closed for maintenance for a while. Come in a minute. ".

How to force a site into it?

For this you need to create a file called .maintenance in the root of the site and place the following PHP code in it:

 <?php $upgrading = time();


Result:


In principle, this will be enough so that no one (except the server administrator) can use the site.

However, if you want to make the page more attractive, you can create a maintenance.php file in the wp-content folder that will be loaded instead of the original text. In it, you can create any kind of picture for the waiting end of the user's work.

You can also recommend a special plugin that can be used for the same purposes:


Now that we know for sure that no data will be changed during the migration process, we can start creating a backup copy of the database.

Database backup


There are several ways to back up your WordPress database:

In order to save space in the post I will not talk about the first two methods, they are quite trivial.

If you have access to the server console, and you know how to use the terminal, this will significantly speed up the work.

First of all, because creating a backup is performed by a single command:

 mysqldump -u[] -p[] [__] > [___].sql


It will be good to archive the dump database on the go:

 mysqldump -u[] -p[] [__] | gzip >[___].sql.gz


Text files, which is a database dump, are archived in the best way. The size of the archive can be significantly lower than the size of the database dump. This is important when transferring, because 100MB transfer much faster than 1GB, for example.

Some hosting companies provide the ability to archive site data through the service control panel:

After that, an archived copy of the database and the site comes to the mail.

However, not every hosting provides such opportunities to customers, so if this option is present, it is most convenient to use it.

Backup files


The WordPress file system usually looks like this (without subdirectories and their contents):
 ├── index.php ├── license.txt ├── readme.html ├── wp-activate.php ├── wp-admin ├── wp-blog-header.php ├── wp-comments-post.php ├── wp-config-sample.php ├── wp-config.php ├── wp-content ├── wp-cron.php ├── wp-includes ├── wp-links-opml.php ├── wp-load.php ├── wp-login.php ├── wp-mail.php ├── wp-settings.php ├── wp-signup.php ├── wp-trackback.php └── xmlrpc.php


In principle, we are most interested in the wp-content folder and the wp-config.php configuration file.

First of all, because all the other folders and files of different WordPress installations (in case of using the latest version of the system ) are not different from each other.

Important: the fastest way to transfer files is to create an archive, transfer the archive and then unzip it on the destination server.

WordPress consists of hundreds of files. In the case when you have been driving the site for a long time, all the images, plugins and themes that you have downloaded will be added to this.

Imagine FTP transferring thousands or even several thousand small files. To transfer each of them, you must first establish and then break the connection. As a result, the process turns out to be long and sometimes it happens that something is lost on the way. Especially when the files are transferred first to the local computer, and then to the new remote server.

Using to transfer the archive, you move only 1 file. Yes, it is much larger in size, but due to the fact that only one connection to the server is required, the transfer is faster. At current speeds of access to the Internet, the time difference can be dozens, hundreds of times.

I strongly recommend to use the archive as a container for transporting a large cluster of small files.
So you can use console utilities like rsync , but for this you need to have skills to work with the console of the north. Several training materials on the topic in English. - one and the second .


Data recovery


So, the archive of the site files and the database dump are transferred to the new server.

Recreating file structure


The first step is to unpack the archive in such a way as to fully restore the original structure of files and folders.



To restore the original structure and not to bungle with folders, you need to follow the following rule:

It is necessary to unpack the archive in the same place where it was created.

For example, if you compressed a site using the console archiver from the root of the site zip -r "full-backup.zip" * , then unpack it on the new server also at the root of the site unzip full-backup.zip .

Please note that invisible files that are .htaccess not always archived with the rest. Therefore, if “beautiful addresses” do not work on your new site, first of all check whether you transferred .htaccess to the root of the site.

Do not forget to delete the archive with the site’s file structure from the server so that outsiders cannot download it.

Recreating the database


Before restoring the database, you need to make sure that the corresponding new database has already been created on the new server.

If it is not there yet, then you can create a new database in different ways:

As a result, we should have on hand:

In some cases, when the database is on another server, we need to know the host address (usually - localhost , if on the same machine).

Using this data we have to import our database dump.

Again, we can do this with the same means.

In phpMyAdmin, select the database, the “Import” tab, select the dump file and send the request form.



If you are using the console, use the mysql -u[_] -p[] [__] < [__].sql .

In case the database dump was archived: gunzip < [__].sql.gz |mysql -u[_] -p[] [__] .

Do not forget to remove the database dump from the server or move it to a safe place, in case it was there.

Configuring the configuration file


Now you need to open the wp-config.php file in the editor and set the appropriate settings for connecting to the new database:



Do not forget to delete the .maintenance file from the root folder of the site.

It remains only to check the performance of the site!

Conclusion


I hope that this guide will be useful to those who are still preoccupied with the issue of migrating a WordPress site and looking for answers to questions.

Probably, more experienced web developers will want to share their own ideas on the topic with their colleagues.

Well, that's what comments are made for. Therefore, any advice, additions and just sharing experience is strongly welcome.

PS An important addition to the comments from nik_vr :
When transferring from a localhost to a real server, one should not forget about the site address. Domain change with simultaneous transfer according to your instructions will make the site completely inoperative. Therefore, the instruction should add one more step (relevant when changing the domain, including - when transferring from a local server to a combat server). For example, we assume that the side is transferred from the domain mysite.local to the domain mysite.ru .

In the saved WordPress database dump, we are looking for all occurrences of mysite.local and replace them with mysite.ru . You can do this in any normal text editor (for example, Notepad ++). After replacing, we carefully save the database, not forgetting the encoding (in the case of more or less modern versions of WordPress, you need UTF-8 encoding without BOM).


After importing the database, you can run the following MySQL command:

 UPDATE wp_options SET option_value = 'http://mysite.ru' WHERE option_value = 'http://mysite.local';

Source: https://habr.com/ru/post/246659/

More articles:


All Articles