Sign up ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

It appears that Wordpress is designed to have websites constructed and maintained online - in the live website. I see some posts here that indicate some people are doing such development offline - in Localhost. But the effort to move a website online - especially for updates - appears to be complex, somewhat manual, and not at all automated. In fact, it's not clear of just the changes can be moved, or if the entire website would have to be reloaded. This seems complicated by visitor changes to the live website while updates are being created. And backups or version control of content - well I haven't gone far on that yet.

So what works? Is it just best to make changes to the live website? What would be the best approach for doing development offline?

share|improve this question

migrated from Jun 11 '12 at 15:00

This question came from our site for professional and enthusiast programmers.

5 Answers 5

It totally depends on the types of changes being made. If you're modifying a theme or a plugin, depending on what the changes are, you can likely build them locally or on a remote dev server, then push them to production with ease.

That works for a user or two, with more users you need version control - something like Git or SVN - to track and merge changes.

See this:

I usually prefer to have a remote dev server because it's easier to replicate the production environment, and it's easier to access from multiple machines. The way I set it up is no slower than local development... possibly even faster.

share|improve this answer

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 fields in 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:   website1 bikefun website3

Then edit your webserver config to create virtual hosts. I'm using WAMP, so I edit


and add sections like

<VirtualHost *:80>
    DocumentRoot "c:/wamp/www/bikefun"
    ServerName bikefun

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 control panel 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 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 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.

This setup then scales if you are working with other developers on the same project and each of you has a local dev copy.

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:

share|improve this answer

We run all of our development locally on our machines. We use MAMP Pro to host our local environments and databases. Git is used for version control and we deploy those changes to our production servers with Beanstalk.

Once development is done locally (which is mainly done for speed reasons - it's much faster to work on your machine than on a server), we will do an export/dump of the database. Once the database is imported and the files are deployed, it's just a matter of changing a few values in the database and wp-config.php.

I would advise strongly against making any changes to any live website. You want to make changes in a protected (read: not public) environment to make sure you don't royally mess something up. Admittedly, however, it does take quite a bit of work to get an infrastructure in place that makes it easy to modify live sites safely.

For now, I'd stick with getting MAMP (WAMP if your on Windows) running on your machine and getting a local site up and running.

share|improve this answer
"Once the database is imported..." What do you upload, the entire database? Doesn't that delete visitor data from production? And what "files are deployed"? –  Patrick Moloney Jun 11 '12 at 17:44
Yes, we export the entire database from development and then import it into production. You are correct - it does delete user data. But that's not an issue if it's a brand new site and there is no user data! Sorry, I was a bit vague regarding files. The whole shebang: WP files, our theme, images, .htaccess, etc. –  perpetualstudent Jun 11 '12 at 20:04

I have just upgraded a large WordPress site through a number of environments, taking each one completely offline whilst I performed the upgrade. We're using IIS as the web server, but since I appreciate most people use Apache, I'll try and keep the steps as generic as possible to apply to both setups.

These are the steps:

  1. Take site offline (bear in mind we did this in IIS, so if using Apache, you would need to use Apache's config to do this):

    a) Take a note of how 404 redirects are done in the web config. You'll need this later. Change 404 redirects to point to root of the site, e.g.

    b) Change web server config to point to a holding page in a separate folder structure to the one holding the WordPress site. We set up just one file, index.html with a "Website in maintenance" message.

The site is now shutdown and cannot be accessed or updated. It is effectively static whilst you upgrade it - unless you have another web config pointing to the WordPress folder. If you do, take this offline in the same way.

  1. Create a backup copy of the files in the WordPress folder.

  2. Create a backup of the WordPress database. (make sure you know how to restore a database if you need to - we use heidisql to backup and restore).

  3. Copy all site files to a local web server and set up the local web server to have exactly the same domain as your live site. On a windows machine editing c:\windows\system32\drivers\etc\hosts to add is required to ensure the browser resolves to the local machine.

Note that even though you'll only be upgrading files locally initially, you will be upgrading the live database, and any database backup's/ restores etc refer to the live database ie that used by the live site.

  1. Make a list of all active plugins.

  2. Deactivate all plugins

  3. Upgrade all plugins

  4. Upgrade WordPress, following steps as proompted including upgrading database.

  5. Before activating plugins, see if any more plugins need updating (this can happen - even if you've already completed a round of upgrading them)

  6. Activate each plugin which requires activation 1 by 1. If you're prompted to upgrade plugin at this stage, upgrade it.

  7. Test the site on both the front and back ends. If you get any unrecoverable errors, restore the back up site files to your local server and restore your live backup database and start again from step 6. If you get the same issues again, you may need to do some research into how to resolve them before going any further. If you need to restore you old live site in the meantime, restore the database, and then follow steps 14 and 15 below.

  8. Following successful testing of the site on your local machine, copy the files from your local installation back to your live WordPress folder.

  9. On your local machine, comment out "#" the entry made in your hosts file in 4 above.

  10. Reverse what was done in 1) above by:

    a) Changing web server config to point to live WordPress site.

    b) Restoring 404 redirect to what it was before you changed it

  11. Test your site on the live domain.

share|improve this answer

Just use as I think this is the best plugin on the market...and no I have no commercial interest in it.

Cheers Mac

share|improve this answer
Lone link is considered a poor answer (see FAQ) since it is meaningless by itself and target resource is not guaranteed to be alive in the future. Please try to include at least summary of information you are linking to. –  Rarst Jul 16 '13 at 9:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.