How you build and deploy a WordPress site will vary greatly depending on the project scope. The following are a few tips for dealing with production, staging and dev sites as a single developer working with a small business client.
Start development locally using Git (Theme folders only).
You might ask, why Git if I’m only a single developer. Great question. Without Git you have no track record of what happened when and where. Things don’t simply break. Things break when things changes. In WordPress that means either you changed something in code or something changed during a plugin or WordPress update.
While this won’t be a guide on how to use Git, a good tool for getting started is Tower. The secret for keeping things from getting too complex is only commit your theme folder. That leaves your production site flexible enough to receive plugin and WordPress updates outside of Git deployments. The only thing you’ll be pushing/pulling with Git are theme changes. This can be done by running git init at the root of the current website project and the following .gitignore file.
*~
.DS_Store
.svn
.cvs
*.bak
*.swp
Thumbs.db
# wordpress specific
wp-config.php
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/*
wp-content/backup-db/*
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
wp-content/cache/*
wp-content/cache/supercache/*
wc-logs/
php.ini
.htaccess
# anchorhost specific
wp-content/debug.log
wp-content/mu-plugins/
wp-content/plugins/
config.codekit
.sass-cache
robots.txt
# wpengine specific
.smushit-status
.gitattributes
_wpeprivate
wp-content/object-cache.php
wp-content/mu-plugins/mu-plugin.php
wp-content/mu-plugins/slt-force-strong-passwords.php
wp-content/mu-plugins/limit-login-attempts
wp-content/mu-plugins/wpengine-common
wp-content/mysql.sql
# wp core (as of 3.4.1)
/db-config.php
/index.php
/license.txt
/readme.html
/wp-activate.php
/wp-app.php
/wp-atom.php
/wp-blog-header.php
/wp-comments-post.php
/wp-commentsrss2.php
/wp-config-sample.php
/wp-cron.php
/wp-feed.php
/wp-links-opml.php
/wp-load.php
/wp-login.php
/wp-mail.php
/wp-rdf.php
/wp-rss.php
/wp-rss2.php
/wp-pass.php
/wp-register.php
/wp-settings.php
/wp-signup.php
/wp-trackback.php
/xmlrpc.php
/wp-admin
/wp-includes
/wp-content/index.php
/wp-content/themes/twentyten
/wp-content/themes/index.php
/wp-content/plugins/index.php
# large/disallowed file types
# a CDN should be used for these
*.hqx
*.bin
*.exe
*.dll
*.deb
*.dmg
*.iso
*.img
*.msi
*.msp
*.msm
*.mid
*.midi
*.kar
*.mp3
*.ogg
*.m4a
*.ra
*.3gpp
*.3gp
*.mp4
*.mpeg
*.mpg
*.mov
*.webm
*.flv
*.m4v
*.mng
*.asx
*.asf
*.wmv
*.avi
Deploy to public site when your ready to show to client
If it’s a new website then I recommend deploying directly to where you plan to host the live site under a default name. With WP Engine that would look something like http://projectname.wpengine.com. Launching is then as simple as pointing DNS to WP Engine, adding domain mapping and a bulk updating urls.
If remaking an existing site then I recommend cloning the existing site into staging and deploying directly to that cloned copy. The launch process would vary depending on if you need to pull over anything from production. If not you could deploy fresh from staging.
Avoid workflows requiring deploys staging to/from production
Production to staging deployments with WP Engine is a one click process. It’s all or nothing. When your ready to deploy the staging site back to production you have two options.
- Deploy Staging to Production which will destroy any changes to production like new orders and new form fill outs or
- Manually copy of your theme changes and reapply any page or content changes manually.
These are both painful options. It’s best to avoid unless it’s a one time thing like handling an entire new website redesign launch.
Theme updates locally, content updates publicly
All theme development should happen on your local computer then deployed via Git. There is no need for the development site to be fancy and polished with all the right information. When building sites you only need to get the core structure in place which be accomplished with fake content.
Content updates like page and post population should always be made on the final customer facing site. While building a new site all of these can be done before putting it the website live with it’s final domain name. After launch you can continue to make page revisions just as your client would.
Update the site like you’re the client. Use staging for previews only.
If you’ve created a good website, then making changes should be as simple as hitting an edit button. If there is a major new feature you’d like to preview before putting on the live site then use a staging clone. A staging site can be generated quickly from the production site and used to preview your locally development. I would treat the staging site as a local dev copy and plan for the info to be out of sync. Any changes should be manually reintroduced on production to prevent any information from being lost on production.