⊶ Moving WordPress ⊶ Introduction, description & demystification of the process
Moving a WordPress site is, by far, the most popular support topic because it needs to be done fairly regularly for various reasons by a large number of people and the variety of hosting environments and levels of control and knowledge of the person performing the move provides a certain challenge in accurately communicating the process in a single location for the largest number of people.
Once this information is understood and you move a few WordPress sites, you’ll see it’s really very easy, but it’s imperative to understand what’s involved and what we’re doing if we expect a positive and trouble-free result that’s repeatable. If we create a proper mental image of what we’re doing before we begin and actually “see” it in our heads, the likelihood of repeatable success increases.
“Moving” a site is defined as: changing the domain/URL or location (physically or virtually), either by: moving the local (sub)directory or DocumentRoot, moving the site to a new physical server/hosting, completely or in part changing the domain name.
• The database contains page text, links, any extra code or text added into the page/post editors or widgets, user account details, various site settings, and other dynamic content. A good way to visualise the database is similar to a case of beer vs. a single bottle. The case represents the database server itself, MySQL / MariaDB, a single bottle represents a database container, the beer inside represents the data within the container or a dump of this data.
• The DocumentRoot contains 2 main components: The WordPress core files (all the files contained in the standard download, wp-admin/, wp-includes/ and the loose files in the DocumentRoot, index.php, wp-config.php, etc) and the wp-content/ directory containing: theme files, plugin files, media uploads, other uploads from forms or other plugins, etc.
Important files and directories in the DocumentRoot to consider:
Note: WordPress does not store files such as images, documents, etc in the database. This would make most databases extremely large and slow and is very inefficient.
Before we begin
Most importantly, you must *want* to do this and you *will* succeed.
- If you’re developing locally, at the very least you should have an intermediate understanding of: DNS, Apache httpd or nginx, MySQL or MariaDB, FTP, SSH, Linux filesystem management & excellent communication skills. If you do not, when you run into trouble it will be very cumbersome to try and help you.
- For the purposes of this guide we’ll assume: DNS is already functioning, our old site is “example.org“, our new site is called “example.com” and our database name and user are database_name / database_user
- We’ll also assume, if moving to a VPS or dedicated server that you either understand Apache httpd or nginx webserver setup and configuration and related technologies (FTP, SSH, sudo, MySQL / MariaDB) or you have someone on your team that does.
- We’ll also assume a basic understanding of Linux and other commonly related web technologies.
- Remember, we can never teach another, only show what we have done. Anyone can choose to follow step-by-step, ignore, alter, omit or be indifferent to anything presented here. You will only learn by doing this, then doing it again and again and again and helping others do it.
- Despite all of this, howtos, guides and tutorials are for experts, beginners should always read the documentation, which is why you will see so many things here linked back to official documentation. For the simple reason, experts have the ability to determine correct/useful information from incorrect/poor information based on experience and previous knowledge, by definition a new person does not have this advantage.
- Lastly, DO NOT copy/paste *any* commands, configurations or code given here that you do not understand without first researching it independently of this site.