Most people make changes directly to their live WordPress website, logging on across the internet to customise their theme or to create and edit pages or posts. All very straightforward, but there is another way to develop a WordPress website – and, depending on your circumstances, it might be much better! You can set up a local copy of your website and make the changes ‘at home’ then upload new versions of your website to your hosting account when you are ready to do so. Compared to working remotely, local website development with WordPress has a lot of advantages, few disadvantages and is much easier than you might imagine.

Remote Development

The traditional way of developing a WordPress site is to log on to it from a local PC. In effect, you are logging on to a website that is running remotely on your hosting company’s web server. The hosting company provides disk space and other resources and makes your website publicly available to  internet users. They might even back up your website and provide some additional security.

Problems With Remote Development

The basic, fundamental problem with remote development is that there is no separation between the live website and the development website, they are one and the same. This means that all development is ‘in public view’ and any mistakes made or problems created are immediately and publicly visible. Further, when the live website is being modified, it may look ‘incomplete’ or even be rendered unusable, especially if significant changes are being made.

Public Mistakes

Any mistakes made in the live website are immediately visible to the public. You cannot check and test the website changes in private. Serious mistakes in your website will have an effect on your credibility, trustworthiness and, ultimately, on your brand. If your development and live websites are one and the same, you cannot avoid making ‘public mistakes’. The only remedy is to fix them immediately, which is not always possible.

Downtime Costs

If you are carrying out major work directly on the live website, your may need to display an ‘under construction’ banner and your site may be unavailable. This will directly erffect your business. Or, if you decide to continue to allow access, your site may appear incomplete, again effecting your reputation and brand. In either case, development comes under time pressure and this could lead to the creation of a less good, more hurried, less tested website.

Local Website Development

An alternative approach to having a single website that serves as both the development and live site is to separate these functions into two websites. One way of doing this is to use a second public website at a different, but not obvious, domain – something like instead of In this article though, we are going to talk about local development with WordPress. The advantages of this are increased privacy, improved performance and easier access to the website for development.

Separating the development site from the live site addresses both of the major issues of the remote development approach – any mistakes or problems created by changing the local site are not visible to the public and there is minimal downtime on the live website. It is only unavailable while it is being updated using a new version deployed from the development system.

The quality of your website increases because problems are found and fixed before they are introduced into the live system and website availability increases because the live system is updated very quickly using a stable and tested version, built locally.

Local Development Workflow

Though approaches to local website development with WordPress vary, the workflow is going to look something like this –

The website is developed locally until a new version of the website is ready to be deployed into the live hosting account, replacing the existing public website. Development and testing are private. Problems fixed during testing can never be visible to the public because they never make it onto the public, live site. The live system is never ‘under construction’ because construction takes place in the local development environment.

During development, the local version will always be more recent than the live version. When you deploy to the live site, the versions will be brought into step. As soon as you then make changes to the local development website, they will be out of step again. The live version will ‘jump’ from one version to the next, as it is updated.

Problems With Local Development

In the local development model, the only writeable version of the website is the local one. All changes are made to it and the live website is replaced by new versions from the local development environment. However, if changes are made directly to the live system while the local system is being developed, any such changes will not be preserved unless they are replicated in the development system as well. Any changes in the live site not copied back into the local site will be lost when a new version is deployed and the live site is overwritten.

So, a significant potential problem with a local development model is that it assumes that no changes are made to the live system while development of the local system is taking place. Unfortunately, something as simple as having comments switched on in the live system may invalidate this assumption. Of course, if multiple people are accessing and changing the website, including clients, this also raises issues about how changes are controlled.

For whatever reason, if you cannot gaurantee that the local system is the only writeable version of the website, there are a few strategies for dealing with this but they depend on the nature of the changes in the live system, their timing and scope, and also the nature of the local devlopment taking place at the same time.

First of all, it may be possible for the local and live systems to be writeable in turn. In other words, there is still only one website that is writeable, but it will change. So, when local development is taking place, no changes are being made to the live site and vice versa. In this way of working, the live website needs to be migrated back into the local environment before development work can start. Also, the nature of the changes, to both the local and live site must be such that they can be temporarily halted, when the writeable version is ‘transferred’.

When it is not possible to stop changes being made to the live system, it may be that these changes are limited enough in scope that they can be easily identified and copied into the local site. For example, where changes are being made to only the content of specific pages these could be copied by hand or the built in export/import tool could be used. There may be other tools that could be used as well for this – for example, the Divi theme allows for the export and import of pages by using its export layout tool. Whatever method is used, the changes to be copied need to be identifiable and limited in scope or this becomes very time consuimg and error prone.

The last scenario is where significant and widespread changes are being made to the live site, but development changes are limited in scope. In this scenario, you may have no choice but to consider the live system to be the writeable system and to migrate individual pieces of development up to the live site.

In all of these scenarios, it goes with out saying that having a backup of the version of the website that is about to be overwritten is a crucial precaution. In fact, in this situation not only should you take a backup, but you should also test it by re-installing it somewhere else.

More Good News

We outlined the main benefits of using a local development environment above but there are others and we will now discuss these in a little more detail.

Local Updates First

Keeping a WordPress site up to date is almost a full time job. If you use anything more than a trivial number of plugins things get even tougher. Most people know that failing to make updates to your site increases the chance of having security problems so not applying updates isn’t a great option. On the other hand, doing anything to a website involves some level of risk. The risk of updating your site and it breaking is small but cannot be ignored. Even if nothing bad happens, it is possible that changes might be needed after the update. Having a local copy that you can make updates to BEFORE making them to the live site is valuable insurance – it minimises the possibility of problems in your live site and, even if an update forces you to make other changes, you can work out what is needed on your local site first before updating the live site.

Access All Areas

Let’s put this up front – I love this bit…. if you have your website in a local system you can actually see it !  The website file system becomes visible. In fact, this is a picture of the files in this website, from my local development environment. Being able to see and easily access the files inside WordPress makes it much easier to make changes behind the scenes – for example if you want to compress all of your image files locally, this can easily be done using something like FileOptimizer or LightRoom.

Unleash The Child

Where this also works fantastically well is when child themes are being used. Suddenly, it is very easy to access and modify the child source files because this can all be done locally, simply by editing files in your child file system.

It’s Faster Too

With the exception of the deplyment of the website to the live system, just about everything about your workflow should be faster when using a local development environment. After all, your hosting account is running on a machine that you share with lots of other websites. If you have a relatively slow internet connection, this will impact of performance as well.

Bad People Do Bad Things

If we use a local development approach to our workflow, the local site can always be used to replace the live site and that’s going to be a good insurance against the live site being hacked or infected. We ought to be able to ‘clean’ our live site by replacing it with a copy of the most recently uploaded version (it’s a good idea to keep copies of the uploaded versions on your local system). In effect, the local development version is acting as a backup of the live system. It is possibly though that, occassionaly, you might want to deploy from the live system back to the local system. You should try to avoid doing this as it is possible that the live system may have been infected or hacked without you noticing.

Backup (and Test the Backup)

Backups are a good thing. Restoring from a backup can fix lots of serious problems. Please backup your website, repeatedly, and then test that the backups have worked, repeatedly.

There are a number of well known plugins that can be used to backup your live site. However, the disk space available to store these backups may be relatively small. Usually any backups would be stored in the hosting account or in a cloud service of your choice.

An alternative is to not take backups of the live system at all but to rely on backups of the local development system. This approach will only work if no changes are being made to the live system. 

If we are relying on local backups only, there are a couple of issues to be aware of. Firstly, it’s probably best to still use a plugin to do the backups and not simply rely on backing up all of the files from the development system folders. If you use a plugin, you will have a backup that is independent of your development environment, it will be easier to test the backups (by re-loading them into the development system as a new – renamed – website) and you should be more certain of including the website database in the backup (the database is stored in your SQL Server and is not beneath the website root folder so you are unlikely to include it if you simply backup your file system).

Also, running a backup of a big website is likely to slow it down. Much better to avoid slowing down the live website if possible. Of course, backups of the live system could be scheduled for 2am, but WordPress has an issue with it’s scheduling system. Unfortunately, scheduled events will not run on their due time but instead will run when the first visitor ‘wakens’ the website after the due time. So it is possible that the backup of the live system will always run when visitors are accessing it.

Independence is a Good Thing

If you use the remote development model then you are quite dependent on your hosting company. What would happen if they were to deny you access to your hosting account? If they are taking backups of your website, they may not have worked – have you tested them? There could be all sorts of circumstances in which having a copy of your website running locally would be really helpful.

What You Need For Local Development

To set up your local WordPress development environment you will need a PHP system, a web server and a SQL database. These are all supplied by your hosting company in the live hosting account. This is one of the things you pay your hosting company for. If you want them in your local system, you are going to have to set them up. It turns out to not be too difficult.

As it happens, there are a few packages available that contain exactly what you need, for Windows, Linux and MacOS. Some are free and some are premium products. The ones I am aware of are –

Of these I have used WAMP and XAMPP. I have also downloaded and tried ServerPress. Lastly, Linux  has all of the required components available as well. Depending on what Linux distribution you are using, the components might be pre-installed, or you might need to install them yourself. Often, this setup is referred to as LAMPP.

You can download and use free versions of ServerPress, WAMP and XAMPP. The free version of ServerPress is limited in respect of functionality and the number of websites supported. The premium version of ServerPress includes technical support, allows for an unlimited number of websites and includes expanded functionality, especially around deployment to the live system. ServerPress has been built specifically for local WordPress development. I don’t know much about InstantWordPress I’m afraid.

I have also noticed recently that a number of NAS Servers include these tools as well, to allow people to have a local web server in their netowrk. Most NAS Servers are actually customised Linux PCs without a monitor. I’ve not tried setting up a devleopment environment on a NAS server. Many NAS Servers are intended simply to stream media or act as network backup archives. It is possible that performance of these systems would make it difficult to use them to host a development environment.

One of the advantages of local development for WordPress is that it makes it much easier to access the source files. So, in addition to the above, you might want an editor that has been designed to work with PHP, JavaScript and HTML, and there are a number of these including –

Lastly, though you can upload new versions of your website to the live hosting environment by hand, it is  much easier to use a tool to do this automatically. We use the Duplicator plugin but other tools are available including BackupBuddy and All-in-One WP Migration.

Setting Up Your Local Environment

Ok, we are going to cheat slightly here. There are so many options available for creating a local development environment for WordPress that we do not provide detailed instructions for how to install one of these local development environments. Please take a look at the resources listed at the bottom of this article for some guidence. From now on, we are, however, going to assume that XAMPP has been installed, since that is the environment that we happen to use.

Please make a careful note of any usernames and passwords you create. You will need these later.

Making XAMPP Available Network Wide

It could be very useful to allow access to your web server from all devices in your network. This could be to allow more than one person to develop websites or it could be to test your websites on different devices. Making this happen involves two steps – geting the web browser on your network devices to know where the web server is located and telling the web server that it is ok for it to serve pages to these devices.

If you point your web browser at http://localhost you will see the ‘Welcome to XAMPP’ message. This will only work on your local machine though, where XAMPP was installed. There are a few methods for telling devices in your network where your webserver is located, but most of these are rather complicated. For us, the simplest solution was to statically allocate the IP address of the machine the webserver was installed on, then always use that address when referring to it.

So, if the IP address of the machine that XAMPP is installed on is say,, using a URL of from other devices should allow them to locate the local web server. The IP address can be statically allocated by configuring your network router.

Another issue to be aware of though is that, by default, it is unlikely that your XAMPP web server will accept requests to provide web pages to any other devices apart from the machine it was installed on. If you are happy with the security implications of doing so, you can modify the Apache web server configuration file – httpd.conf – to allow this. You can access this file from the XAMPP control panel –

Here is the section from our httpd.conf file that allows anyone in our network to access the local development websites –

<Directory "E:/Xampp/htdocs">
    # Controls who can get stuff from this server.
    Require all granted

Just be aware that any changes you make to the configuration file will have no effect unless you restart the Apache web server. You can do this from the XAMPP Control Panel. Also, this configuration file will change depending on what web server is being used and even what version is being used. So, this ‘recipe’ may or may not work for you. Lastly, keep a note of this change as it may not survive installation of new versions of XAMPP.

Finally, any websites you install in your webserver need to use the static IP address for all internal links. In other words, the internal links should NOT refer to localhost but use instead. You need to watch out for this when creating internal links and when migrating a website into your local development environment. If your websites did use localhost as part of their internal links, they would not work when browsed from other devices in the network.

Installing a Website Under XAMPP

When you install XAMPP, you specify the folder to install it into. Whatever that folder is, your website files are assumed by XAMPP to be in a subfolder of this called htdocs. So, if you install XAMPP into E:/Xampp, your website files need be in subfolders of E:/Xampp/htdocs. For example, if you had a folder called E:/Xampp/htdocs/test then pointing your browser at (assuming that is the IP address of the machine where XAMPP was installed) should allow access to the website in the test subfolder. Note, the website database is NOT stored beneath the htdocs folder.

If you wanted to install WordPress in your XAMPP WebServer, you would need to do two things – create an empty database in your SQL Server to hold your website data and extract the WordPress distribution into an appropriate subfolder of htdocs.

We can use the phpMyAdmin utility to create a new, empty database. phpMyAdmin was installed along with XAMPP. It is a web application that is started by simply pointing your browser at it. If you installed XAMPP at then you can run it by pointing your browser at It should also be available from the XAMPP DashBoard, if you have access to that. Here is what it will look like –

Note that I have removed some information from this screeshot for privacy.

On the left, you should see the databases stored in the server. To create a new database, simply click on the New link near the top of the left hand panel. Enter the name of your new database where it says Create Database/ Database Name then click on the Create button. If you want to remove a database, select it in the left panel (the database entry on the left will open to display the different tables in the database) then click on the Operations tab at the top of the screen and then select Drop The Database from the Remove Database panel. Be careful when you do this.

To get all of the WordPress files into the right place prior to installing WordPress, simply create a folder inside your htdocs folder and then extract all of the WordPress files out of the WordPress distribution zip file into the new folder. You can download the latest WordPress distribution zip file from

As you can see, in my system the WordPress websites are all stored in a subfolder of htdocs –


but that’s because toucans are very neat and tidy. You don’t have to be. You don’t need the extra WordPress folder.

If, on your machine, you extracted the WordPress file into E:/Xampp/htdocs/test for example, then pointing your web browser at should start the WordPress installation running. Answer the questions and it should install WordPress. The database name is the name of the one you just created using phpMyAdmin, the user name and password are for the SQL Server user account you created when you installed XAMPP, and the database host is, or whatever IP address you have used for the machine your webserver is intalled on.

Changes to the Live System

With the local WordPress development approach, you may choose to never make changes to the live system. The live system is changed only when a new version of the website is deployed from the development system. Deployment is a controlled process using a tested version of the website.

So why might we want to ignore this rule? Well, there is an overhead to deploying a complete new version to the live system. So, when we need to make a change that is simple and urgent and is limited in scope so has little chance of breaking something else, we might consider making the change both in the live system and in the development system.

In these circumstances though we can still make the change first in the development system where it can be tested before applying it to the live system. However, we need to be aware that during development, the live and local systems will be different, so we are not actually making a true test of the change when we test it locally. One way to solve this is to keep a separate, local copy of the live system. Then changes can be tested in the local copy before being applied to the live system.

Lastly, be sure that whatever you do, you remember to include any changes made to the live system in the development system as well, or that change will be lost at the next deployment.

Things Not To Do Locally

Firstly, it’s a good idea to make sure that Google analytics is switched OFF in the local site. You can do this by simply removing the analytics code – remember to put it back in the live system when you deploy to it. If you don’t remove the analytics Google will get data from your local site as well as your live site and you will get a ‘polluted’ set of data when viewing your analytics reports.

Also, switch off your cache plugin in your development system. If it is switched on it is possible that you will struggle to see some changes that you make – specifically changes to the CSS styling may not appear without you having to flush the caches, which could cause confusion if you don’t realise this is causing a problem. The expectation is that developing locally is going to be quick anyway so having the cache switched off should not be much of an issue. As ever, you need to remember to switch it on when you deploy to the live site.

Staging Sites

A staging site is a copy of your website that you upload to your hosting account but attach to a public domain that is different from that used by the live site.

A staging site can be useful to test your new website. The hosting environment and the local environment will be different and some problems may only become visible in the hosting environment. It can also be useful to test that the upload of your new website has worked. Neither of these are likely scenarios but it is definately useful to use a staging site as part of your testing.

The other situation where a staging site might be very useful is when you might want some else to review or test the website prior to replacing the live site. Unless you open up your local network to the outside world (not recommended) the staging site is a good way to do this.

Usually, the staging site will be attached to a domain something like –

depending on whether you choose to use a subdomain ( and or a subdirectory ( to implement it in your hosting account. I tend to use a subdomain because it places the file system for the staging site outside of the main site’s file structure, thus backups of the main site will not contain the staging site. Also, unlike subdirectories, subdomains are treated as separate domains by Google and this might help your main website to be insulated from any SEO effect of having a public staging site. However, there are arguments for and against either approach.

Just be aware that some hosting companies provide you with a really old version of the PHP compiler when you use a subdomain. We don’t know why they do this but it may cause strange errors if it is old enough. Usually, you can specify the version of PHP to be used in your htaccess file. You can check for the PHP version by using a phpinfo.php file and pointing your browser at it. This file should look something like –


// Show all information, defaults to INFO_ALL

// Show just the module information.
// phpinfo(8) yields identical results.


Before Deploying to the Live Site

Here are a couple of important caveats. Firstly, be sure that you can restore your live site from a backup. You are about to replace it with a new version and it would be great if you could rollback to it if something goes wrong. If your hosting company are taking backups, that is good. If your hosting account allows multiple databases, that’s good too because one option is to create a database for each version of your website that you deploy. This will naturally preserve the existing one, and you can delete it later, when you are happy with the new version.

Second, if changes can be made to your live system by others, you must carefully manage those changes so you can identify them and be able to replicate them in the development system before deployment. In other words, deploying to the live system should not lose any changes that might have been made to it.

Lastly, you could test your new site using a staging site before deploying to the live domain. This might show up problems that were not visible in your local environment.

Deploying to the Live Site with Duplicator

There are a few ways to actually deploy your new website to the live site including doing it entirely by hand…..

In our workflow, we use a tool called Duplicator and this is a description of how we use it. Duplicator is a backup and migration tool, available in a free and premium (Pro) version. Everything described here can be done with the free version. It was the premium version that was used in the screenshots.

We assume that you have tested the new version of the website locally and that you are happy it is ‘complete’ and ready to be deployed.

The scenario described here is that we are uploading a new version of our website to our live staging site. The new version is called version 0.95 and the version installed in the staging site at the moment is called version 0.94. We also have an older version of the staging site, called version 0.93 stored in our hosting account (but it is not live).

Ok, Here is Your Warning

If you migrate websites into hosting accounts, it is possible that you will accidently cause damage. Worst case scenario, you could destroy a website or two. So…. always, always, always be careful what you are doing and take lots of backups. Take small and safe steps, until you are confident of the process. Always ask yourself, before clicking on any button…. “what damage can this do and can I recover from it?”.

Though I have tried to make this article as clear as possible and to describe how to do this in a way that minimises the chances of disaster and maximises the chances of recovering from disaster, I take no responsibility for what you might do as a result of reading this article 🙂

Creating The Package to be Deployed

So, the first thing we do, in our local environment, is to log on to the website and use Duplicator to make a local backup. As it happens, in this article we are using Duplicator Pro so it might look a little different if you are using the free version but they are broadly similar.

Duplicator calls these backups packages, as they contain multipls files. To create a package go to Duplicator Pro->Packages where you will see a (possibly empty) list of existing packages. To make a new package, simply click Create New. Next, you get the opportunity to change some of the settings. The default values should be fine but you may want to create a new Storage location first, otherwise Duplicator will store the generated files in the website folder. if you want to save the package to a folder on your local PC, just go to Duplicator Pro->Storage, click on Add New to create a new Storage location then give it a meaningful name, specify the storage type as local server and enter a Storage Folder as the location. Note that only a limited number of packages are stored unless you set Max Packages to zero. When happy, just save this new storage location and remember to specify it when making the package.

Now click Next and Duplicator Pro will ‘scan’ your website to check it and give you a report. Hopefully, this says everything is fine.

Our website is a little big. Hence, Duplicator Pro is warning us about it. We have a trick to address this that is discussed later. if you want to go ahead, click on the Build button to generate the package.

Duplicator Pro Version

In the Pro version, you can save packages in a number of locations. You just need to set up the ‘Storage’ before creating the Package. Yes, it’s a bit more complicated but that’s the price of flexibility 🙂 Set up the Storage to save the Package somewhere in your local file system.

Duplicator Free Version

If you are using the free version, you do not have a choice about storage location and the package is saved inside WordPress. All you need to do though is click on each file in turn and ‘download’ it into a safe place on your local file system.

And here are the files that were generated by our Duplicator Pro plugin. We gave the package a name of Version095. The text document is a log file, the ZIP file contains all of the files from your website (including an exported database file), the SQL file is another copy of the exported database file, the PHP installer file contains the code needed to deploy on the live site and…. I don’t know what the JSON file does 🙂 The free version only generates the PHP and ZIP files but they are all you need…..

Gathering Data From the Live Site

On the live site, we need to know the name of the database user account and password and the address of the host web server. We might also need to know the name of the database itself, depending on how we are going to do the deployment. More on this later. If you don’t have this information handy, you can find the current valjues from the live site. It’s all inside a file called wp-config.php at the top level of your website file structure. You can log on to the hosting company account and just download this file. Keep this information safe, you could re-use it next time – it won’t change unless you change it.

In the wp-config.php file, you should see something like the following (we have replaced our database name etc. in this example for obvious reasons) –

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'my-database-name');

/** MySQL database username */
define('DB_USER', 'my-user-name');

/** MySQL database password */
define('DB_PASSWORD', 'my-user-password');

/** MySQL hostname */
define('DB_HOST', '');

So you should see the database name, the database user’s name and password and the host web server name of your live site. The host is likely to be an IP address, but it doesn’t have to be. You are going to need this information or its equivalent when you deploy to the live site.

Upload The Package

You only need two files from the Duplicator package. If you are using the free version of Duplicator it will only generate these. The Pro version generates more files. You only need the ZIP (archive) and the PHP (installation) file. Either FTP these files to the hosting account or upload them using the hosting account file manager. it is possible that, within your hosting account, your website is stored in a folder called ‘public_html’. It may be called something else, though. If you onlt have one website, it might be stored directly beneath public_html. In other words, public_html may contain the wordpress folders. Personally, we prefer to store our websites in their own folder beneath public_html. As it happens, in the example here, we are going to deploy a new version to our staging site and this is in a subfolder called public_html/staging.

Preparing the Database

We keep a copy of the previous website in the hosting account so that, if something goes horribly wrong with the new install, we can quickly rollback to it. The easiest and quickest way to preserve the previous version of the live website is to use different databases for each version. So, to prepare for a deployment, we create a new database, being careful to give it a name that reflects the verion number of the website, and we delete all previous versions apart from the most recent….

This can be done from your CPANEL either using phpMyAdmin or by using the MySQL Databases tool if available. Using MySQL Databases we can see that there are already two versions of the staging website database. TBT_STAGE_094 is the database used by the live staging site and TBT_STAGE_093 is the previous version, still stored in the hosting account in case we need to rollback. We are uploading version 0.95 and we usually only keep one previous version so we can delete TBT_STAGE_093 (be careful to click on the right red button !). We also create a new database called TBT_STAGE_095 (by entering STAGE_095 in the new Database box). This is the database we are going to write to when we deploy the new version.

The only other thing needed to prepare our new database is that we need to specify which database users will have access to it and what permissions they will have. Without this, the WordPress site would not be able to connect to the database. If you scroll down the page in MySQL Databases you can see where the user accounts are set up –
If you want to create different users for each database, simply Add a New User, remembering to specify a password. You don’t have to do this though and could use the same user for each of your website databases. It would be more secure to create different users. To give the user access to the new TBT_STAGE_095 database, simply select the user and database where it says Add a User to a Database and then click Add. it will pop up a dialog asking about user privileges. Give this user all priveleges.
That’s the new database set up. It’s empty at the moment but when we deploy the Duplicator package, it will be filled with data.

Now For The Exciting Part

So, rename the website folder (staging is renamed to be staging-094). Then make a new folder (staging, in my case). It will be empty of course so move the duplicator install and zip files into it.

It’s not a great idea to include the version number in the name of the live folder because the subdomain would then need to be changed each time we deployed a new version.

If you are storing previous versions (such as staging-093 or somesuch, it should be safe to delete that folder now).

Accessing the Website Folder

You might also need to change access control on the folder in order to see its contents with your browser. You will know if this is an issue because you will get an Access Denied message if it is. If you get this message you might be able to get around it by creating an .htaccess file in the staging folder that contains –

Options +Indexes

Install the New Site

Point your browser at your domain by entering the site URL. You should see a listing of your two files. Click on the PHP file, the install file (usually it’s the smaller of the two). You should now be prompted for the installation of the website. There are tutorials for Duplicator widely available but here is what you do…

Duplicator will prompt you for the information we gathered earlier – the database name, database user name and password etc. Of course, if you created a new database, use its name and NOT the name from the wp-config.php file – that’s the name of the previous database, the one you are trying to temporarily preserve.

WARNING – if you use a database that has had a website deployed into it already you are about to destroy it.

Though we often use newly created (and empty) databases, we still need to select ‘Connect and Delete any Existing Data’ and NOT the option that creates a new database. If you try and create a new database, it is unlikely that Duplicator will have permission to do this.

Enter the Host server for your database (usually an IP address), the Database (it’s name), the User (the user account with permission to access the database) and the Password (that we set up when we created the user). If you have not created a new user account you will be entering the same User and Password each time you deploy a new version of the website (only the Database name will change as the version changes).

Click to test that everything is ok. This is testing that the user has access to the database. if this fails check you have typed the details in correctly then check the user has rights to the database. It is possiblr that this will fail due to incompatability between versions of the software environment used locally and used in the live hosting site. It is also possible that if you have just created a new database, it may take time for this to become available.

If you pass the database test, click next on the Advanced Options. We always force the file permissions to be 755 for directories and 644 for files. If there is an issue with files permissions in your website folder it can often be very difficult to diagnose and fix…. so safety first is our approach.

Lastly, we have found that we sometimes need to select ZipArchive as the uncompress tool, depending on how the hosting company have set up their environment. This will be slower than the ShellExec, but seems to us to be more available across different hosting companies. If you run ShellExec and it fails, you will need to delete everything from your installation folder, apart from the two uploaded files from the package, before trying again.

Now click on the tickbox to say you have read the warnings and notices. Finally, go ahead with the deployment by clicking on Run Deployment.

Duplicator will tell you that it is ‘Processing Files and Database’. What it is doing is unzipping your files into your installation folder and overwriting your database. So if this is a big website, this could take a while.

When this is done, you will be presented with the URL of the new website and the installation folder name. Duplicator does a good job of working these out but YOU MUST CHECK THEM CAREFULLY. They are critical to the operation of your website. The latest version of Duplicator Pro deon’t actually display these by default but the old settings of the website are read from the Duplicator files.

Duplicator Pro uses this information to change some settings in WordPress and to do a global search and replace of your website database for all references to your local domain, replacing these with references to your live domain. In other words, it relocates the website for you. Again, if this is a big website, it may take some time to do this.

When completed, you should get a screen that shows no errors. It is possible you will get warning messages and you should check them. Usualy, these can be ignored.

Now Log On

When Duplicator has finished you should log on to the website. It’s a good idea when you log on at first to do some housekeeping. We usually go straight to Settings->Permalinks and re-save them.

Another issue to be aware of is that by default Duplicator will give you a new (minimal) .htaccess and rename the original by adding .orig to its name. Your live site can’t use the original .htaccess from your development environment because it is likely to contain references to your development domain. So, the first thing we do is to deactivate and reactivate any plugins that modify to the .htaccess file so they can make appropraite changes to it. These are likely to include security and caching plugins. Of course, if you have made modifications by hand to your htaccess, you will need to replace these as well. If in doubt, carefully compare the htaccess generated by Duplicator with your original version. This should not be difficult as Duplicator will set up your site with a minimal htaccess file.

Generally, you should end up with an .htaccess file in your live website that looks very similar to the one from your development environment. If they are widely different, look hard for an explanation.

You should then check that your caching plugin is ON (if you want it), that your Google Analytics code is in place and that you are allowing search bots to crawl your site (Settings->Reading->Search Engine Visibility). For a staging site, there are good reasons for having all of these OFF. We explain our reasons for this elsewhere. 

Now Take a Good Look Around

Now take a good look around your website to make sure everything is working…

Rolling Back to the Previous Version

If something goes wrong…. and you want to rollback quickly to the previous version…. simply rename the staging (live) folder to be staging_broken and rename staging-094 (previous version) to be staging. Yes, it’s that simple. You should not need to do anything to the database at all. The wp-cofing.php files should still contain all of the information to connect the webiste to the correct database.

Migrating By Hand

Though Duplicator Pro does a good job at migrating websites, it is also possible to migrate a website by hand. The easiest way to do this is to have a zip file of all the files from the website plus a SQL Server file containing all of the data exported from the website database. With these two files it is possible to migrate the website into or out of our local development environment. Similarly to creating a new website in the web server, we need to put the website files in the right place and import the database into the SQL Server. To do this, simply create a new folder under htdocs to hold the new website and export the website files into it. Then use phpMyAdmin to create a new, empty database. Make sure the database is selected and then got to the Import tab and import the database tables from the zipped SQL file into the database. Now, go to the wp-config.php file in the install folder and edit it. Change the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to the new settings. Finally, and most importantly, you need to manually run some SQL code in order to globally substitute the internal URL addresses from the original location to the new location in your local development environment. The SQL code needed is going to look something like –

UPDATE wp_options SET option_value = replace(option_value, 'ORIGINAL-URL', 'NEW-URL') WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts SET guid = replace(guid, 'ORIGINAL-URL', 'NEW-URL');

UPDATE wp_posts SET post_content = replace(post_content, 'ORIGINAL-URL', 'NEW-URL');

UPDATE wp_postmeta SET meta_value = replace(meta_value,'ORIGINAL-URL', 'NEW-URL');

If you are using a security plugin, it is possible that it may have renamed the database prefix from ‘wp_’ to something else and you will need to replace this text in the SQL. You enter this code using phpMyAdmin in the dialog box in the SQL tab, one command at a time. Be sure to click on the ‘GO’ button to run this.

You might also need to replace the contents of the .htaccess file in the website toplevel folder with –

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

This is the ‘minimal htaccess’ file and should work. Depending on what plugins may have done to your htaccess, it is possible that you have the URL of the original site hard wired into it. Replacing it with the minimal file should solve this.

Lastly, it is always a good idea, on first logging in to the newly migrated site, to save the permalinks by going to Settings->Permalinks. If this is a staging site, we also recommend disabling any cache plugins, making sure that Google Analytics is not present and that web bots cannot actually crawl the site (Settings->Reading->Search Engine Visibility).

As you can see, using a tool to migrate your website is quicker and safer.

Manual Deployment from Duplicator

Sometimes, you may want to use Duplicator to install a website where the Duplicator ZIP file has already been unzipped into the installation folder. Or, you may have uploaded the approriate files yourself, in stages.

To use an already unzipped Duplicator deployment file, first make sure that no .htaccess or index.php files exist in the installation folder (just rename them – you might need them after the install). If you don’t do this, the browser may render a previous website or give a 404 file not found error or a 403 access forbidden error. What you want to see when you point your browser at your website is a directory listing that shows the php installer file in the installation folder. When you get this, click on it to run the installation file.

If you really are stuck you could try typing the full URL of the Duplicator installation file into your browser, rather than simply the website URL. So, somthing like

When the Duplicator installation runs, you should see the results of the Scan that it first does and, assuming everything is ok from the scan, just click on Start Deployment. The Step 1 ‘Deploy Files & Database’ screen should appear and you just need to enter the required information but then be sure to click on Advanced Options and select Manual Package Extraction. Next, as usual, click to acknowledge any warnings and notices and then click on Run Deployment. Everything should work as before but, instead of unzipping the distribution file, the files in the installation folder will be used.

Finally, don’t forget to put the index.php and .htaccess back if you renamed them earlier. If you did rename them and don’t put them back, your website will not work and you will probably just see a directory listing of your files.

When Things Go Wrong

Website is Too Big to Package
If your website is so big, that you cannot easily package it up for deployment….. try excluding wp-content/uploads. You can either add it into the Package by hand afterwards (by copying it into the Dplicator zip file) or, if you want to keep the size of the ZIP file itself down, you can upload any excluded files after you have deployed the website. Just make sure you put them in the right place.
Something Else Went Wrong
Check the error log in the CPANEL. This can provide crucial information.
Rollback to Previous Version
If something goes wrong…. and you want to rollback quickly to the previous version…. simply rename the staging folder to be staging_broken and rename staging-094 to be staging. Yes, it’s that simple. You should not need to do anything to the database at all. The wp-cofing.php files should still contain all of the information to connect the webiste to the correct database.
Incompatible Software
Duplicator is a bit fussy about what software versions you are using. You might get warnings about having too old a version of PHP, SQL or web server prior to building the package. You might get warnings on deployment because Duplicator compares the versions used locally with the software in the hosting account.

Difficult to give specific advice about resoling this other than many hosting companies let you change the software versions you are using. Check your hosting account setup. Also, you can actually specify the PHP version used in your .htaccess file (assuming you have multiple versions available to you).

Uploaded ZIP File is Corrupt
Most hosting accounts allow you to upload files by clicking on an ‘upload button’ in the file browser. However, some hosting accounts seem to be quite sensitive to the size of ZIP files uploaded in this way. If your uploaded ZIP file will not unzip or appears to be corrupt (check the file size!), try using a specialist FTP tool like Cyberduck.


Not in any particular order, here is a list of resources. We haven’t read all of these articles. Some are included here simply because they look interesting.

If you found our blog article useful, why not subscribe? Get all of our articles and tutorials delivered direct to your inbox!

You have Successfully Subscribed!