Permanent Link to Install WordPress Locally 1 Of 2"
Install WordPress Locally 1 and 2<br />by Jeff Chandler on December 30th, 2007 in HOW-TO<br />Welcome to part one of a two part series of articles that will guide you through the process of installing a fresh copy of WordPress or your public WordPress blog to your local machine. The first part of this series will guide you through the installation and configuration of a piece of software called WampServer. Why would you want to do this you ask? Having your WordPress blog installed on your local machine not only acts as a backup, but it gives you the option of really digging into the inner workings of your blog without having to worry about it breaking and therefor, rendering the thing useless to the public. Not only that, but it’s much faster to play with things on your local machine than it is with a LIVE site on the internet.<br />For this article, I am using Windows XP Service Pack 2 and something called WampServer. WampServer is a piece of software that installs everything you need to turn your PC into a webserver. This includes Apache, MySQL, PHP, SQLitemanager and PHPMyAdmin. Before we get started, head on over to the official WampServer download page and grab a copy of WampServer 2.<br />WampServer Installation:<br />The installation process is pretty simple. After accepting the license agreement and specifying where the WampServer files will be installed to, the installation file will be unpacked, doing all of the heavy work for you. Using a software application such as WampServer to install all of your webserver needs for you automatically, is the easiest way to turn your machine, into a web server. Once the installation is finished, you’ll be prompted to locate your default browser executable file. In my case, I had to direct the install to my FireFox executable file which is usually within the Mozilla folder.<br />One of the first things you’ll have to configure is the PHP mail parameters. For SMTP, the default value of localhost is correct. As for the email address, you can choose to type one in, or not. This can always be changed later. Once this setting is configured, you’ll be greeted with a confirmation box that tells you the installation of WampServer has been completed. Leave the option “Launch WampServer 2 now” check marked and click the finish button.<br />Configuring WampServer Files:<br />One important piece of information I have to mention. The webserver acts on port 80 which is the port responsible for HTTP traffic. If you are running Skype with it’s default configuration, you’ll notice that your Webserver is offline once you start the program. This is because by default, Skype uses port 80 and 443 for incoming connections. You can either change the port that Skype uses or you can close, then re open Skype after your Webserver is online, forcing Skype to use a different port. In essence, make sure port 80 is clear before you launch WampServer or else the Apache web service will not run.<br />I’ve also been informed by ayusli that will you also need to disable IIS if that is running on your system. If you don’t, you may not be able to access localhost.<br />Once your WampServer is online, you’ll need to edit a few files to change the configuration to allow for larger databases to be imported. These changes will take place within the PHP.ini file. The PHP.ini file is a text file that contains the configuration for the PHP programming language. The first thing you’ll need to change is the upload_max_filesize attribute. By default, this is set to 2Megabytes. This is too small of a value, so increase this to 50 or 100megs. It doesn’t need to have a specific value so long as it is larger than the size of the database file you will be importing later on in this guide. The other setting you’ll need to change is post_max_size. By default this is set to 8Megabytes. Change this to the same value as the upload_max_filesize limit. After you make this change, reboot your computer. This will ensure the changes you made to the php.ini file take effect.<br />End Of Part 1:<br />If you plan on doing a fresh install of WordPress, you won’t have to worry about making any changes to the PHP.ini file after you install WampServer. However, if you plan on taking a copy of your public blog and transferring it to your local machine, the changes described above need to happen or else you will likely run into problems such as your database file being too large to import.<br />Part 2:<br />Part 2 of this series will go into details on how to install a fresh copy of WordPress as well as how to transfer your existing WordPress blog on the internet onto your local machine. It’s not as easy as transferring the database and then extracting a backup of files into a folder. There are a few more required tricks that need to be performed before a public blog can be successfully transferred.<br />Installing WordPress Fresh:<br />One thing you must know before we move on is that, by default, your database username is ‘root‘ and the default password is blank. In other words, there is no password assigned to the username of root. This would be extremely insecure if this web server were made available to the public but because it’s assigned to the local address of your machine, you have nothing to worry about.<br />To begin, left click on the WampServer icon and select PHPMyAdmin. Where the text labeled CREATE NEW DATABASE is located, type in the name of the database that will house your installation of WordPress. For simplicity, I normally call the database wordpress. Then click on the Create button. We now have an empty database that the WP installation files can work with.<br />Download the latest version of WordPress, then extract the files to your desktop. Open the WordPress folder and look for WP-Config-Sample. Open this file in your preferred text editor. The DB_Name is the name of the database you created for WordPress. The DB_Useris root. The DB_Password is blank. These three values are the only ones you’ll have to change. Once those changes are in place, save the file as WP-Config.PHP<br />If you want to install WordPress into the ROOT directory as you would on a public web server, take all of the files and folders within the WordPress folder and move them into the WWW folder. WWW is the same as Public_HTML and is the folder which houses all of your web documents. If you don’t want to install WordPress into the root directory, create a new directory and place all of the files into that one. Just make sure the files are within the WWW folder, or else they won’t be accessible.<br />Once that’s finished, point your browser to http://localhost/wp-admin/install.php Follow the directions as they are pretty self explanatory and when your finished, you’ll have a fully functioning, fresh install of WordPress that you can do whatever you want with.<br />Migrating WordPress From Public To Localhost:<br />Migrating an existing WordPress install onto your local computer is not as easy as a fresh install. If you haven’t already, make sure you have made the appropriate PHP.ini file changes that were explained in part 1. If you don’t, you will run into numerous errors about the SQL file being too large to import.<br />In my circumstance, my webhost offers it’s customers Cpanel as a means to control all aspects of my Webhosting account. Cpanel provides me with a way to generate a full backup of my domain. This backup includes all of the hardcoded directories and files attached to my domain as well as any databases I have created. After you create a full backup of your domain through Cpanel (if you have that option) download the backup to your desktop. Once downloaded, open up the file and browse to the Public_HTML directory. Extract this directory’s contents into the WWW folder on your hard drive.<br />Once that’s finished, look inside of the mysql directory within your backup file. This directory contains all of the MySQL databases you have created through your webhosting account. Extract the SQL file that pertains to your WordPress install and place it on the desktop.<br />Ok, before we move on, let’s review where we’re at. We backed up all of the files related to the hosting account and then downloaded that file to the desktop. We then extracted all of the files within the Public_HTML directory into the WWW directory. We then looked inside of the backup file and extracted the SQL file that pertains to the WordPress installation. At this point, the folder structure within the WWW folder on your hard drive should mimic that of what you would see within the Public_HTML folder on your webhost.<br />Now, left click on the WampServer icon and click on PHPMyAdmin. Click on the link that says IMPORT. Click on the BROWSE button and locate the SQL file you extracted to your desktop that pertains to your WordPress installation. After you locate and double click on the file, click on the GO button. It might take a little while, but the import process should be successful. If you receive an error that states the SQL file was too large, please re-visit part 1 and make sure the changes were saved to your PHP.ini file. Also, I wanted to share that if you have the SezWho comment rating plugin installed, you may receive errors that are related to the plugins database tables. If this is the case, you will need to open the SQL file in a text editor and remove all of the lines that pertain to those tables which are usually prefixed with sz_ and then try to import the SQL file again.<br />If the import was successful, pat yourself on the back because were almost through with this process.<br />If you do not want to do the next step through the database you can instead, add these constants to your WP-Config file and they will perform the same function as the database edits.<br />define('WP_HOME', 'localhost');define('WP_SITEURL','localhost');<br />In PHPMyAdmin, the database you imported will now be selectable in the drop menu that is located near the top left portion of the webpage. Click on the drop down arrow and select the database you just imported. Near the top center of the page, there will be a series of tabs. Click on the SEARCH tab. In the search box, type in the full URL to which your public WordPress install refers to. In my case, I typed in http://www.jeffro2pt0.com This will search the entire database for entries of that domain. The search results should find entries related to that domain within the table WP-OPTIONS. Click on the Browse link to dig into this particular table.<br />You only need to concern yourself with the top two entries, SiteURL and HOME. Click on thePencil icon for SiteURL which is just to the left of the X icon. This will open up the editing page. In the large text box on the bottom, change the URL to http://localhost then click on the GO button. Now do the same thing for HOME. After you change HOME, you can exit out of PHPMyAdmin.<br />If you have never opened the .htaccess file to hard code redirection attributes, you can skip the next step and you are essentially finished.<br />The last thing to do is to edit the .htaccess file and remove any hard coded redirection attributes. If you don’t do this, each time you try to load your blog on your local machine, it will automatically redirect to your public blog or which ever URL you configured in your .htaccess file.<br />Victory Lane:<br />If you’ve managed to read this far, congratulations. After all of that, you should be able to access and browse your blog on your local machine exactly how you would in a public domain. This guide is by no means a cure for all. This was my detailed approach as to how I migrated my public install to a local install. Some of the actions I performed may not have been necessary, nor required, but this is the way I did it and it worked!<br />If you have a correction or a different way of doing things, by all means leave a comment. I will edit this article as corrections come in so the most accurate information is presented.<br />Also, now that you have the ability to dig around the ins and outs of your blog through the database, you’ll be able to see some things that you might not of known about before. Stay tuned for another article which highlights a VERY important issue pertaining to plugin developers that needs to be discussed. Perhaps we’ll be able to come up with a solution.<br />