Concur with @perpetualstudent about offline development.
If you start by installing on the webserver, then always copy in the direction of your PC dev you won't be overriding user data.
There are two records in the wp_options table that need to be modified each time you copy the database, these are siteurl and home that need to change to point to your local PC webserver.
For this I use the windows /etc/hosts file (on Windows 7 you need to run an editor as administrator to edit this file, and it's at C:\Windows\System32\drivers\etc\hosts ). Create static DNS names for your site(s) like this:
127.0.0.1 website1 bikefun website3
Then edit your webserver config to create virtual hosts. I'm using WAMP, so I edit
C:\wamp\bin\apache\apache2.4.9\conf\extra\httpd-vhosts.conf
and add sections like
<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot "c:/wamp/www/bikefun"
ServerName bikefun
</VirtualHost>
then you can point your browser at http://bikefun (e.g.). This is better than just running via http://localhost/src/bikefun for example, apart from anything else it keeps the relative paths the same on your PC vs your production server.
To refresh your local version so it's the same as your webserver, takes two steps. The one you have to do most frequently is the database. I use SQLyog which can make a copy of the remote database onto your local PC, the first time you do this, you create an empty database on local, then switch to the server, right click on the database name and "copy to different host". Be careful when copying that you don't accidentally overwrite a production database, make sure you are copying to your local PC!
If you are using cPanel you can download a dump of the database and execute that locally.
After copying, you need to change those two fields in the wp_options table.
When setting up your local PC version the first time, you need to copy the webroot files from the webserver, or else duplicate the exact install locally. For example, on the webserver go to webroot and use something like
tar -czf name.tgz website-directory/
then copy name.tgz to your local machine and extract it into your local webroot with something like 7-zip.
Subsequently I rarely repeat the copy of the files, you can keep the local copy synchronised by doing the same version updates and installing the same plugins etc. But you can repeat the file copy anytime if things get messed up on the local PC.
If you are modifying or writing plugins or themes, you need version control. I almost always create a child theme and put it into version control, but this is not necessary if you aren't modifying the theme. Once I create a new plugin, or edit an existing one, I create a GIT repository in the plugin or theme directory and clone that to github.com. Then I clone from github to the webserver (assuming you created/edited it on your local PC). That way you can develop locally and push your changes up to github (or your repository of choice) and pull them down into the webserver to upgrade the plugin/theme there.
git pull origin master
This gives you the ability to roll-back should things go wrong despite your careful testing on your local PC. So both your WordPress webroots will have one or more GIT repositories embedded in wp-content inside plugins or themes directory. To deploy from github to the live server, I use a simple shell script:
#!/bin/bash
# Argument = -w <website> -t <theme> -n <name>
# if -t is not given, plugin is assumed
usage()
{
cat << EOF
usage: $0 options
Deploy a git repository to a wordpress theme or plugin
OPTIONS:
-h Show this message
-w website. e.g. bikefun
-t it's a theme, otherwise it's a plugin
-n name of plugin or theme
EOF
}
THEME="false"
WEBSITE=
NAME=
# anything that needs a parameter has a : after it.
while getopts .htw:n:. OPTION
do
case $OPTION in
h)
usage
exit 1
;;
t)
THEME="true"
;;
w) WEBSITE=$OPTARG
;;
n)
NAME=$OPTARG
;;
?)
usage
exit
;;
esac
done
if [[ -z $WEBSITE ]]
then
usage
exit 1
fi
if [[ -z $NAME ]]
then
usage
exit 1
fi
# make sure the repository is up-to-date
cd /home/lamp/webroot
cd $WEBSITE
cd wp-content
if [ $THEME = "true" ]
then
cd themes
else
cd plugins
fi
cd $NAME
# overwrite any local changes -
# this gives freedom to hotfix directly on the server and later overwrite it
git fetch origin master
git reset --hard FETCH_HEAD
git clean -df
service apache2 reload
Using GIT scales if you are working with other developers on the same project and each of you has a local dev copy. But I also find it handy because I switch between desktop and laptop.
Sometimes I am working on my laptop where there is no internet connection. It's a great way to fill in a long plane flight and there are no interruptions or distractions while you work! Here's an article about how to stop timeouts from slowing everything down when you are using WordPress offline: http://www.cbdweb.net/wordpress-development-offline/
