Is it feasible to build and update a WordPress website offline?

4 comments

1. 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: https://stackoverflow.com/questions/9705849/how-to-set-up-a-stageing-enviorment-for-wordpress-wordpress-mu/10837071

   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.

   Log in to Reply

2. 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:WindowsSystem32driversetchosts ). 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:wampbinapacheapache2.4.9confextrahttpd-vhosts.conf
   

   and add sections like

   <VirtualHost *:80>
       ServerAdmin nik@blah.blah
       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/

   Log in to Reply

3. 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.

   Log in to Reply

4. 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. http://example.com

      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:windowssystem32driversetchosts to add 127.0.0.1 example.com 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.

   Log in to Reply