Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

WordPress Local WordPress Development Local WordPress Development Local WordPress Development

Wordpress version control workflow

These are my impressions of most WP workflows:

Commando

Shared hosting with php5, phpmyadmin and cpanel

  1. Install wp on server
  2. Install plugins on server
  3. Edit theme files on server
  4. Save and refresh live site to see changes
  5. Backup wp using plugin
  6. If issues, restore from server plugin backup file

Local to Server FTP

Shared hosting with php5, phpmyadmin, cpanel and ssh

  1. Install wp locally
  2. Install plugins locally
  3. Install wp on server
  4. Install plugins on server
  5. Export local wp database and import to server with phpmyadmin
  6. Activate wp plugins on server, change database config from local etc.
  7. Edit theme files locally
  8. Use ftp/sftp software or rsync to upload edited files
  9. Once uploaded refresh live site to see changes
  10. Keep local and server db in sync using wp migrate plugin
  11. Backup wp locally and on server using plugin
  12. If issues, restore from server plugin backup file

Local to GitHub to Server

Shared hosting with php5, phpmyadmin, cpanel and ssh

  1. Install wp locally and create git repo
  2. Install plugins locally
  3. Edit theme files locally (git commit)
  4. Push local edited files (with commit history) to GitHub repo
  5. Install wp on server
  6. Install plugins on server
  7. Export local wp database and import to server with phpmyadmin
  8. Copy Github master branch file changes to server using script/service
  9. Activate wp plugins on server, change database config from local etc.
  10. Once uploaded refresh live site to see changes
  11. Keep local and server db in sync using wp migrate plugin
  12. Backup wp on server using plugin
  13. If issue, re-copy/rollback/re-deploy the previous github commit and restore a sql database from backup

Crazy People

Cloud host with ssh

  1. Setup entire site using http://wp-cli.org/
  2. Install git locally and on server
  3. Push changes from local to server and forgoet about local db sync
  4. Server backup script to aws and if issue just roll back and push local to server again and diff to explore cause

Am I missing anything? What is your opinion of the best workflow for sharing dev work, seamless client ownership and easy rollback and troubleshooting if broken.

Andrew Shook
Andrew Shook
31,709 Points

Tony Jessup, this sounds like a really good question. Could you elaborate more on what you mean by client ownership, rolling back and what kinds of problems you envisions trouble shooting.

Thx Andrew. Well for client ownership, once a website is live I would like the transfer of ownership to client to be as easy as possible. Easiest is just update the hosting payment. But what if it's being developed on your own server, github account, deploy account (i.e. beanstalkapp.com, ship.io) transferring all this to the client's host can be time-consuming. Which is probably why clients make commando mode changes in production.

As for rolling back, lets say you made a bad edit two weeks ago that broke a website layout in IE9 and your client's customer just discovered it. Your site is backed up daily and you have made 10 changes since then. How do you roll it back, determine which change broke it, fix it and re-deploy the easiest/quickest?

Regarding trouble-shooting, lets say are having some layout issues in your responsive site on certain mobile devices (HTC Hero, Samsung Galaxy S). You need to see if your different solutions fix the problem. Do you try each solution and upload every time? Or split each attempt into a different branch and see if it fixes the issues via browserstack.com? Once fixed merge the best branch and redeploy. Ideally testing on different devices/browsers/connections would be part of the deployment process.

Didn't mean for these to be so long but there you go. Just looking for opinions on the matter as to what people think is an over-engineered workflow and what is just right.

Granted, all websites/apps/projects are different. Lets just say a workflow that works for a website/app that can start with 2 developers and 2k daily visitors that wouldn't need to change if you had 10 developers and 200k daily visitors.

9 Answers

It's a woefully inadequate approach, because it doesn't solve the most important problem: moving content around.

The problem with every WP "workflow" is that it dismisses that thorny problem with a wave of the hand and a "oh, use WP's built in XML import/export function" or "oh, just use phpMyAdmin to export and import the database".

Both are lousy solutions, and akin to doing web development in 1994. This is a deal breaker for me and WordPress; I've finally got to the point where I've realized that WP simply isn't built for this sort of thing, and Automattic cares not much about solving it.

Jason Torrence
Jason Torrence
1,726 Points

Totally agree, although I still use WordPress for CMS capabilities because I can't get my head around something like Zend.

Zac Gordon
STAFF
Zac Gordon
Treehouse Guest Teacher

Pulling down to work locally is one approach, having a staging server is another big one.

I want to emphasize too that if updates happen to a live site, like with Ecommerce and community powered sites you can wipe out data if you push a local db that has become outdated since being pulled down. This is the one not so smooth part of transfering back and forth.

Thanks for the comment Zac. Agreed on the risk of pushing local database changes to a staging server would be smarter then ever pushing a local db to production (or syncing them with wp migrate pro). Better to pull down from production db if needed.

Zac Gordon
Zac Gordon
Treehouse Guest Teacher

I don't think WP Migrate Pro can actually merge DBs. In my understanding, this hasn't been successfully done yet in a production plugin, although the folks at WP Migrate are definitely help paving the way!

I would love to see a git of WordPress DB's!

Right it's more like copying not syncing/merging databases - that's just crazy talk. A git diff on a local and remote wp databases would be cool!

Tony & Zac,

In your opinions what would be the best back up plugin to use? Any help would be nice. I am cleaning up a mess that someone us started.

Benjamin,

I like BackUpWordPress which I believe Zac recommends as well.

Thank you Tony. Big help.

As if right on queue, the Coolest Guides on the Planet guys published a post today about Git workflow for Wordpress Local Dev

It's a good approach to just commit and push up the wp theme files or the files actually change the most. Really no need to have version control for the base wp install, plugins and other dependencies.

Makes for an easy deploy process: $ git push origin master

And an easy deploy revert process: $ git reset --hard HEAD^ (reset files to previous commit) $ git push origin master

James Gill agreed. What are you using instead of WP?

Michael, What do I use for what?

Sorry I was unclear haha. I meant, do you use another CMS instead of WordPress?

I feel pretty strongly that WP is not a CMS. It allows you to manage content in only the most limited sense.

But to be honest, despite a long-time love affair with WP, I find myself moving away from database-backed web solutions like this. This has more or less paralleled my learning of other web tools. WP is just too inflexible, too limited, and too hack-prone. And yes, I know that statement will inspire strong disagreement from WP folks.

Now if the database component were easily decoupled from the rest of WordPress, were much easier to make part of a real development workflow, and didn't rely on creaky, awkwardly-done PHP to make significant customization, I'd like it much better.