WordPress Development Server: Part 1
Duplicating WordPress on a development server using the same domain name
disclaimer
posted: 2013-02-08
Are you responsible for the care and feeding of a self-hosted WordPress, or other CMS-based website? Whether it’s your own personal blog, or company website, a development server is a must. It’s a safe haven for screwing up, I mean, developing a website—a place to test plug-ins, new code and styles, install and test updates, and proofread content before unleashing it on the unsuspecting public.
The question is: What is the ideal WordPress development server setup? The answer: There’s an answer? Well, maybe, but I’m not sure about the ideal part. If you’ve found a solution that makes you giddy with its utter utility and simplicity, please share it. Here’s one option.
Making an exact duplicate of WordPress on a development server:
This is a fairly straightforward development server setup. It duplicates a WordPress installation on a live server on a development server right down to the domain name. When WordPress is served from the development server, it’s indistinguishable from the live server. WordPress files and database are completely interchangeable. On the development server you can tweak styles, test code, log in to the WordPress admin panel, and create new posts and pages. You can even work from the beach, then later, back in the land of milk and internet access, after removing sand from your keyboard, update the files and database on the live server.
Aye, but here’s the rub:
- Switching back and forth between live and development servers requires commenting and uncommenting a hosts file entry
- As fatigue sets in during the wee-wee hours of the morning, you may forget which server you’re on
- No side by side comparisons because you can’t access both live and development servers at the same time from the same computer—too bad, because this is really useful
Development server software:
- 7, 64-bit
- Apache 2.2
- PHP 5.3
- MySQL 5.5 Community Server
Using the same versions of Apache, PHP, and MySQL as on the live server may help to keep your blood pressure at a reasonable level.
Assumptions:
- You have an existing WordPress installation on a live server that you want to duplicate on a development server.
- Your development server is up and running and can serve PHP pages from http://localhost/
- You have a passing fancy for the MySQL command line tool, mysql.exe, and can use it to log in to both development and live servers.
Duplicating WordPress on the development server:
-
Transfer WordPress files:
Use your favorite FTP client to transfer (copy) all WordPress files from the live server to the development server. Make sure to use the same directory structure. If WordPress files on the live server are stored in htdocs/blog, where htdocs is the web server’s root directory, transfer files to htdocs/blog (backslash for windows) on the development server.
-
Back up the WordPress database on the live server:
Use the MySQL backup utility mysqldump.exe to back up the WordPress database on the live server. The resulting “dump file” will be saved on your development server. Before getting started, you’ll need the following information. Here’s an example:
parameters description mysite.ca domain name of live server wp_user username for WordPress database on live server mysecret password for WordPress database on live server wp_db name of WordPress database on live server wp_bak.sql a file name you create for the dump file that will be saved on the development server Creating a new folder for .sql backup file, or use an existing one.
At the Windows command prompt, type:
C:\>mysqldump -h mysite.ca -u wp_user -pmysecret wp_db > C:\bak\wp_bak.sql
Press Enter.
The backup process is not at all confidence inspiring. While the dump is in progress you’ll see a flashing cursor sans command prompt. On completion, the command prompt C:\> returns—and that’s all you’ll get. Open the dump file in notepad to verify that there is actually something in it. Note: this does not use a secure connection.
-
Create a database:
Create an empty MySQL database and a user on the development server:
-
Log in to the mysql command line on the development server:
At the Windows command prompt, type:
C:\>mysql –h localhost –u root pmyrootpassword
Press Enter.
-
Create a MySQL database for WordPress using the same name as on the live server:
At the MySQL command prompt, type:
mysql> CREATE DATABASE wp_db;
Press Enter.
-
Create a user for the database with the same user name and password as on the live server:
At the MySQL command prompt, type:
mysql> CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'mysecret';
Press Enter.
-
Grant the user all privileges on the database:
At the MySQL command prompt, type:
mysql> GRANT ALL ON wp_db.* TO 'wp_user'@'localhost';
Press Enter.
Test your handiwork. Exit the MySQL monitor and log in as the new user from the Windows command line:
At the Windows command prompt, type:
C:\>mysql –h localhost -u wp_user –pmysecret -D wp_db
Press Enter.
At the MySQL command prompt, type:
mysql show databases;
Press Enter.
If mysql responds with this:
+--------------------+ | Database | +--------------------+ | information_schema | | wp_db | +--------------------+ 2 rows in set (0.00 sec)
pat yourself on the back and exit the command line.
-
-
Restore the database:
Use the backup file created from the live server to “restore” the empty WordPress database just created on the development server.
At the Windows command prompt, type:
C:\>mysql -h localhost -u wp_user -pmysecret –D wp_db < C:\bak\wp_bak.sql
Press Enter.
-
Create a name-based virtual host:
Adding a name-based virtual host to Apache’s configuration allows the use of the same domain name on the development server as on the live server. More importantly, it allows the same database to be used on both development and live servers.
-
Open Apache’s configuration file in notepad: C:\Apache2.2\conf\httpd.conf Find this line: # Include conf/extra/httpd-vhosts.conf
Uncomment the line by removing the hash (#) symbol so it looks like this:
Include conf/extra/httpd‑vhosts.conf
-
Open Apache’s virtual hosts file in notepad: C:\Apache2.2\conf\extra\httpd‑vhosts.conf Edit this line: NameVirtualHost *:80 so it looks like this:
NameVirtualHost 127.0.0.1:80
Add these lines:
# WordPress development server for blog.mysite.ca <VirtualHost 127.0.0.1:80> DocumentRoot C:/Apache2.2/htdocs/blog ServerName blog.mysite.ca </VirtualHost>
Save and close the file. Restart Apache.
In the above example I’m using the subdomain blog. On the web server, the WordPress files are actually located in the folder: htdocs/blog, but because the bog folder has been configured as a subdomain in the control panel of the webhosting account, the WordPress URL is blog.mysite.ca. Whether you use a subdomain or not for your WordPress installation, it makes sense to keep WordPress files neatly tucked away in their own folder. The document root will be a lot tidier.
-
-
Add entry to hosts file:
Since both development and live servers share the same domain name, blog.mysite.ca, we need a way to control which site is being displayed. This is where the operating system’s hosts file comes in. When blog.mysite.ca is entered in the web browser’s address bar, the operating system checks to see if the domain name is listed in its hosts file. If it’s not, the browser’s request is directed out over the internet ending up at the live server. However, if the operating system finds an entry in its hosts file that points the domain name back to the localhost (itself), the browser’s request is directed to the development server.
- Open notepad as administrator, then open the hosts file (the hosts file has no file extension): C:\Windows\System32\drivers\etc\hosts
- Add the following line: 127.0.0.1 blog.mysite.ca
- Save the hosts file and close it. This will point your browser to the development site.
To view the live site, open the hosts file in notepad and comment out the 127.0.0.1 blog.mysite.ca entry by putting a hash (#) symbol in front of it so it looks like this:
# 127.0.0.1 blog.mysite.ca
Save the file and close it.
One of the difficulties with using the same WordPress domain name on both development and live servers is that it is almost impossible to tell which site you’re actually viewing. One thing you could try is adding a style to the local site’s style sheet to distinguish it from the live site such as changing the background or text color in the header. Hmm, header text is chartreuse, this must be the local site.
To ensure you are actually viewing the site you want, flush the dns cache, and then refresh the browser window.
To flush the dns cache, at the command prompt type:
C:\>ipconfig /flushdns
Press Enter.
No comments yet…