# Best way to combine Composer+Wordpress & Roots+Node+Grunt workflows?

**URL:** https://discourse.roots.io/t/best-way-to-combine-composer-wordpress-roots-node-grunt-workflows/377
**Category:** archived 🗄
**Created:** 2013-09-18T14:36:18Z
**Posts:** 63

## Post 1 by @pixelnate — 2013-09-18T14:36:19Z

I have used Roots (through its many iterations) for the last couple of years as a base theme for my projects, but this latest iteration of Roots and the insistence (which I completely understand) for source managed workflows has me a bit stumped about how to organize my projects. OK, I have admittedly waited far to long to get on board with using VCS for my theme development, but I could never grok how to best make use of git when it came to working with WordPress. I did use git quite a lot when I was building little Rails apps, but it made sense because the entire project was MY code. With Wordpress, very little of it is code that I have anything to do with.

The screencasts for setting up your WordPress installation using Composer was a very good look into how you should be managing Wordpress installations, but it stopped short of illustrating how to themes fit into the picture. The Roots + Grunt screencast didn’t go into any detail about how that scheme fit into the info provided in the previous screencast. My question would be (or would start with) how should your project be organized if you are developing a ‘website’ (WordPress + theme) for somebody? Do you clone Roots into the ‘app/themes’ directory and include it in the git repo used for your WordPress installation (making sure to add the theme .gitignore items to your Composer+Wordpress .gitignore file)? Then once the theme is on the production server you run composer install, then go into the theme and run npm install? Is that all? Is there a better way to set up a project?

And what about deployment? Grunt has a Capistrano task (man, have I missed ‘cap deploy’), but can it be set up to deploy the entire project (Wordpress+RootsTheme)? Capistrano could certainly be set up to run the tasks (‘composer install’, ‘npm install’), but don’t you need to have them installed on the server? How are you guys dealing with that?

Any info would be greatly appreciated. As is usual, we are up against a deadline and these changes to Roots have happened while we were between projects - we need to get started on some new projects and don’t know the best way to start them. I could cobble together a half-assed workflow, but I would prefer to do things correctly.

Thanks,

Nate

---

## Post 2 by @Foxaii — 2013-09-18T15:07:03Z

The good news is we have a stack (it’s powering the Roots site) that uses everything you’ve covered including Capistrano for deployment and Vagrant for local development. The bad news is you’ll have to wait until next month for it, whilst we get the docs and screencast into place.

Scott put so much effort into the stack he had to go on holiday to Italy to recover; it’s definitely worth the wait and it won’t take much to transition the sites you’re already working on, when the time comes.

---

## Post 3 by @pixelnate — 2013-09-18T15:18:31Z

Sigh. I was hoping for a bit more insight, a few pointers perhaps, I don’t really need the hand-holding that a custom Vagrant image would provide. We’ll stick to Root-only managed workflow and FTP for now, and see what Scott has cooked up later. Thanks for the response, @Foxaii.

BTW, I love this forum software. What is it?

---

## Post 4 by @Foxaii — 2013-09-18T15:25:03Z

You’re welcome for the response; I’m sorry that we’re not really able to go into more detail at the moment. You may well change your mind about Vagrant when you get to see the stack…

The forum software is called [Discourse](http://www.discourse.org/).

---

## Post 5 by @jmjf — 2013-09-20T14:08:00Z

I can’t answer most of your questions, but the following may be helpful.

I’m not up on Composer yet, but git does pay attention to .gitignore in subdirectories. So unless Composer requires it, you shouldn’t need to move .gitignore for git’s sake.

When you clone Roots, if you leave the git directory in place, I think git will treat it as a separate repo and exclude it from the site repo (at least, that’s what I think I’m seeing in some tests I’ve done). So if you want to merge the theme into with your site repo and manage all changes in the site repo, you’d need to delete the git directory.

My understanding is that the node modules are for development-side only (to run grunt). I don’t think you need to npm install on your production server–unless you’re doing development in production, which falls into the same category as “editing files on a live server” (see … Okay… I can’t post a link to the Roots Discourse now? Fine. Quoting Foxaii. “Editing files directly on a live server should be a last resort, followed by weeping in a darkened corner, with a large bottle of whisky, and Paranoid Android by Radiohead on repeat.”).

That might help your workflow get back 1/32 of it’s ass so it will be a 17/32-assed workflow. :smile:

---

## Post 6 by @pixelnate — 2013-09-20T14:47:24Z

Thanks for the input, @jmjf. For now, I am just managing my Roots modifications which I’ll use either FTP to Capistrano (which I have never used with PHP, but there is no reason why it wouldn’t work) to deploy. I could have sworn I had read something recently that mentioned using git for deployment, but I’ll have to do a little digging to find out if that is indeed true.

Now that I have come to terms with the changes in Roots, and understand the ins and outs of how to use it better in development, I don’t have the same concerns. I see now that Composer is just being used to manage building up an installation of WordPress that is set up as you want it - when source-managed it can serve as a basis for all the sites we build. Except when your needs are different from one site to the next. A brochure site won’t, necessarily, have the same plugins as an e-commerce site, so in that case having a basic install of WP won’t really be as useful as it might be otherwise. And all of our sites are a bit different than the others, so that isn’t exactly how we would use it anyway.

The way I now see a Composer-managed WP project would be to set up WP using the info in the Composer+WP tutorial, then either clone (with git-and strip the gitness out) or wget (and unzip) the Roots theme into the ‘app/themes’ directory, then manage the whole project in a single git repo. Like you said, Grunt and Node are just being used in the development of the theme so we don’t need to worry about deploying them. The only part of this kind of workflow would be running a ‘composer install’ on the dev and production servers. I am not sure our hosting account would allow for us to install Composer on the server. Well, some of the accounts anyway. We have a VPS for a couple of our clients, but most are in a shared hosting environment (Rackspace CloudSites). If would put all of our new projects on a VPS it wouldn’t be a problem, though.

However, I am not going to go whole-hog on that just yet. I’ll be waiting to see what Scott has put together once he gets back from his vacation in Italy. Like I mentioned earlier I don’t need to run a Vagrant VM just to get my ‘dev’ on, but there might be some secret sauce that he’s using that makes it taste better. We’ll know in October…

---

## Post 7 by @jmjf — 2013-09-20T16:41:35Z

See `http://discourse.roots.io/t/questions-about-grunt/336/30` and the one after it for info on git deploy.

(Hah! Smarter than you, Discourse. :smile:)

---

## Post 8 by @swalkinshaw — 2013-09-29T17:51:51Z

@pixelnate you’re correct about how you’d structure a WP site repo. You’re also correct that I didn’t really mention how themes fit into the Composer model, but that was mostly because it wasn’t Composer related. This will all come together in a future blog post/screencast about how we do our new modern WP stack.

It’s important to realize that once you’re using Composer to manage WP and 3rd party plugins, a WP site is basically just the theme and any internal plugins (which imo should be a lot since you don’t want a lot business logic in the theme itself).

In general, nothing should be committed to version control that is the output of a development or deployment process. That means you shouldn’t commit compiled/concatenated JS/CSS. You also shouldn’t include anything that’s managed by a dependency/package manager.

The obvious question that you’ve asked is then HOW do you actually deploy a project setup like this. There’s really only 2 ways:

1. Run the deployment process locally and transfer the build files to the production server.
2. Run the deployment process on the server.

I prefer #2 so that means you do need Grunt, Node, and Composer installed on the server. Some people don’t like that since they like to keep their production server as clean/minimal as possible. I think I thought that way too at first but quickly got over it. Maybe it’s because I’m used to Rails where asset compilation happens on the server too.

This might sound bad but no one should ever use shared hosting (except maybe for their first site). There really isn’t much of a point anymore when you could get a Digital Ocean server for $5/month and have complete control over it for example. Yeah you need to setup some stuff on your own but it’s pretty trivial. And I think you have a responsibility for some things like if you’re charging a client for hosting. Anyway, shared hosting severely limits almost anything you can do.

---

## Post 9 by @talves — 2013-10-04T21:31:04Z

I know this is a little late to the party, but I will try to make a contribution since I am trying to address some of these questions myself. When reviewing, remember that I work on windows without XAMP install. (yes composer does run on windows; tongue in cheek).

I created a [Composer-Wordpress-Skeleton](https://github.com/ADARTA/Composer-Wordpress-Skeleton) repo to be able to build my base wordpress install with roots as a theme. The default has only wordpress, then the example composer-roots.json has the roots theme installed. This does not clone roots, but installs it into the project ready for add to a new repo along with the project.

This may not be what you were looking for, but a start to a first initial cut. I was hoping to be able to run a npm install script after the load, but have not gotten that far yet. Maybe someone could help out with that piece.

---

## Post 10 by @pixelnate — 2013-10-21T13:11:13Z

Thanks for the replies @swalkinshaw, @jmjf and @talves. That is all good info. ~~I have one more question regarding deployment of the Roots theme: How do you get the LESS rendered for the browser? Once you get the files to the server, install Node, et. al. how do you get LESS rendered? Less.js isn’t in the Roots theme and you aren’t running ‘grunt watch’ on a production server so I am confused how that happens.~~

EDIT: Just realized that all of that is handled with the grunt file.

Let’s change the one more question to this: This whole Composer, Node, Grunt = Roots is great for building themes, but when using it for ‘site’ development, how do you keep your databases synced up? Let’s say I have put together the first large chunk of a site locally and I need to get that onto the server so that the client can see it. To install WordPress we do the Composer dance, then to get the theme installed you ssh into the server and git clone, grunt install - how do you guys normally move your DB over? Dump locally and import to the production DB every time you make changes?

If you are posting changes to the site two or three times a week, that can get really tedious. I appreciate all the work that went into making the theme more programmer friendly, but as a ‘green field’ developer it seems like Roots is so much more complicated to develop with. It makes me miss the old Roots, when the accent color was blue.

How do other people keep their DBs in sync when building client sites? I am really curious how this works for other people.

---

## Post 11 by @talves — 2013-10-22T19:58:41Z

@pixelnate I have been lucky to have my sites forward facing and the DB’s exposed remotely for development. I use the DB remote connection (local site) and when moved to the server, turn off remote access and done. Moving a site from dev to production is easy enough. Backup and then restore the DB. Updating a site that is live has always been an issue. I would love to hear what others do. Tracking changes in the DB with a SQL script for a large project proved successful, but cumbersome at the least. No easy answer or magic on this one :frowning:

---

## Post 12 by @jmjf — 2013-10-25T16:01:51Z

> [@swalkinshaw](#):
>
> This might sound bad but no one should ever use shared hosting (except maybe for their first site). There really isn’t much of a point anymore when you could get a Digital Ocean server for $5/month and have complete control over it for example.

It has taken me a while to figure out why this bothered me, because I agree, but…

I’ve seen a lot of clients who don’t have the resources to managed a VPS or the inclination to pay someone to do it. They choose shared hosting because it’s $1.00 per month less or $0.05 per month less, or it’s what they’ve always used and their comfortable with it and it’s easy, please don’t make me learn something new… you want me to run a Linux box? In these cases, you either let the job walk or you find a way to work without installing the infrastructure.

I think that’s the advantage Capistrano, Ansible, and similar SSH-based install packages offer. (Ansible does require Python, but most shared hosts offer Python.) For these packages, you need to set up the repo so WordPress and the deploy infrastructure are in separate repos or your deploy process has to clean up the infrastructure on the host, meaning the host is out of sync with the repo.

The upside is SSH-based packages work with Digital Ocean, EC2, Linode, and others too. The main downside is they’re targeted at Linux based hosts. If you run into a client who’s using Windows-based hosting… well, I’d probably walk away from that one anyway (and I develop on Windows).

---

## Post 13 by @pixelnate — 2013-10-30T14:07:52Z

Blockquote[quote=“Foxaii, post:2, topic:377, full:true”]  
The good news is we have a stack (it’s powering the Roots site) that uses everything you’ve covered including Capistrano for deployment and Vagrant for local development. The bad news is you’ll have to wait until next month for it, whilst we get the docs and screencast into place.

Scott put so much effort into the stack he had to go on holiday to Italy to recover; it’s definitely worth the wait and it won’t take much to transition the sites you’re already working on, when the time comes.  
[/quote]

October is just about over. Are you guys any closer to releasing that screencast/article?

---

## Post 14 by @swalkinshaw — 2013-10-30T19:26:15Z

A little but not much. Life gets in the way too often :frowning:

There’s a few more things to work out but we might just release what’s actually done first. This isn’t a cop out it’s just that the end result will probably be better if we let people use what we have earlier on to get feedback. Impossible to perfect it all considering everyone will use it differently.

I’m currently working on a 12 part blog post series about making WP into a Twelve-Factor app (see [http://12factor.net/](http://12factor.net/)). This will introduce a lot of the concepts for the new stack tools.

---

## Post 15 by @swalkinshaw — 2013-10-30T19:27:58Z

I completely understand this. My not always practical answer is to try and get in a position where you can pick your clients or dictate some hosting options for them (if you want). Of course that’s not always possible in the real work. However, when I said people shouldn’t use shared hosting that was mostly aimed at people who directly control sites themselves.

---

## Post 16 by @intelligence — 2013-11-04T21:35:33Z

I’m still trying to wrap my head about all these things (trying to get as much as possible before I jump into my next project so I know what will fit me best).

At this point I’m not quite sure what should be in my git repo and what shouldn’t and why it shouldn’t be there. To me the simplest way must be syncing the whole project (short of media assets and wp-config, as sensitive information shouldn’t be in a repo).

This will allow me to simply push all changes from my local enivorment to a test bed and then further onto live production. Ideally the DB will be pushed and synced (and urls replaced), to minimize the amount of manual handling.

If a new WP version is released during development, I can just get the new version and merge it with my local development and see if it’s a good fit, before moving on.

This to me seem simple enough, but I’m sure I’m not getting the whole purpose of getting in to Composer, but maybe you could enlighten me…

> [@swalkinshaw](#):
>
> 1. Run the deployment process locally and transfer the build files to  
> the production server.
> 2. Run the deployment process on the server.
> 
> I prefer #2

Could you maybe elaborate why you prefer #2?  
  
Thanks alot, I’ve been learning a lot of new stuff that I will surely implent with my coming projects.

---

## Post 17 by @swalkinshaw — 2013-11-05T19:39:56Z

#2 wasn’t explained well. By “deployment process” I really meant the “compiling” process, like compiling assets.

I’m not entirely convinced anymore about #2. My original reasoning was just because it’s what I was used to with Ruby on Rails and Capistrano. There’s definitely some downsides like taking time to compile everything on the server (using CPU etc) and that production needs unnecessary dependencies like Node.js or Ruby (for a PHP app).

It’s also an easy way to make sure you don’t include compiled files in your repo if you’re only generating them on the server, but there’s ways to do that locally as well.

So basically I’m still on the fence about it. It has some arguments on both sides but I’m at least not as opinionated about it as before.

---

## Post 18 by @kalenjohnson — 2013-11-05T21:15:13Z

I think the missing link for a lot of people is Capistrano. Setting up Capistrano to handle deploys to your dev/staging/production servers should take care of setting up WP, dumping the DB, search-replace, and basically everything else.

I’m not an expert on it, I just started researching it last night, but it seems like that is the last key to getting things as automated as possible.

---

## Post 19 by @swalkinshaw — 2013-11-05T21:51:05Z

Agreed! I’m trying to get a screencast out in the next 1-2 weeks covering strictly Capistrano and common use cases.

---

## Post 20 by @BCRoots — 2013-11-05T21:56:51Z

Thanks for the update. I’ve been keeping an eye peeled for the screencast throughout October! Mainly with the hopes that the DB migration portion is covered.

---

## Post 21 by @jmjf — 2013-11-05T23:20:12Z

Mark Jaquith has a couple of videos on WPTV that give a high level overview. He also has WP-Stack on Github as a model Capistrano deploy for WP. It’s enough to get started and get a feel for what works and what you need to build yourself.

I’m a bit concerned by his position that the media assets don’t need to be versioned. If the customer changes their logo and overhauls their site and the new logo is a different size, it seems like rollback without the ability to rollback the media would create appearance issues.

There are other solutions as well. One of the guys from the VVV team has Salty-WordPress, which uses SaltStack to set up something like a VVV vagrant. I looked at SaltStack long enough to determine it could be used for software deployment.

There’s also Ansible, which can do server provisioning and software deploys and requires nothing but Python and SSH on the target server. (I’m exploring Ansible more because I don’t know Ruby and YAML is easy to write–among other features.)

---

## Post 22 by @intelligence — 2013-11-06T13:38:24Z

I’m a but curios about this aswell.  
From what I gathered I should be working like this:

- Develop locally and commit to develop branch on remote repo (bitbucket in my case).

- Pull the dev branch to my online dev enviroment, which I intend to use to  
keep the client up to date with the current status.

- When project is nearly done, merge develop with another branch, called stage branch this branch is then pulled into the stage enviroment. Stage is on the clients server. In this scenario the client will start to replace my dummy content with the real deal, this is the first time the client’s allowed to login and make those changes themselves.

Now here is where I think it becomes tricky. Because ideally I will let the client work with the stage enviroment before it’s moved onto production. Thus I’d like to pull the db from the stage to my local setup regularly so that I have live media and text content so that my dev enviroment is as close to the real stuff as possible. But since I won’t be version controlling the media, this won’t work. So how should I do it?

---

## Post 23 by @jmjf — 2013-11-06T15:17:37Z

I think for stage to development, you could just copy the database (dump, copy dump, load, use a search and replace script to fix links). Here’s one solution [http://interconnectit.com/products/search-and-replace-for-wordpress-databases/](http://interconnectit.com/products/search-and-replace-for-wordpress-databases/) that I’ve tried. There are others I haven’t tried. WP-Stack seems to script production to stage minus the search and replace (see `namespace :db` in lib/tasks.rb). You could use the same process for stage to development. (Yes, it’s Ruby, but the important parts are shell commands.)

The bigger challenge is moving to production. Ideally, all changes should be done with SQL scripts so they’re repeatable, controllable, and versionable. (Certainly true if you’re talking 12-factor.) At initial load, that isn’t a big deal (production database is empty). The second load, though, you have to find what changed and script the changes. (I’m still trying to sort out how you make that work without a lot of manual intervention. There are some database compare tools out there that should help, but I haven’t found the ideal answer.)

Also, would you really let clients develop in staging? I thought staging was supposed to be user acceptance testing, which should mean no changes to staging that don’t go through development and unit testing first. You might have an exception case for a blog segment of the site, but the non-blog site should be controlled. If clients are creating content, shouldn’t that should be in another development environment with changes versioned into a script and pushed to UAT-staging?

As far as media, I think it’s completely possible for media to break a site or at least make it look horrible. If you can’t rollback to the previous version of media, you’re stuck. I think you have to version media somehow. Maybe not git. Maybe the deployment preparation process identifies changed files and puts them somewhere the deploy process can find it (and can backup the corresponding files), but some kind of packaging and versioning so you can revert in a crisis.

---

## Post 24 by @intelligence — 2013-11-06T18:35:22Z

> [@jmjf](#):
>
> Also, would you really let clients develop in staging? I thought staging was supposed to be user acceptance testing, which should mean no changes to staging that don’t go through development and unit testing first. You might have an exception case for a blog segment of the site, but the non-blog site should be controlled. If clients are creating content, shouldn’t that should be in another development environment with changes versioned into a script and pushed to UAT-staging?

Hm, not sure. I’m new to all this.  
But would it be better to bring in the client at production? I rather let them add all their content, rather than having me organize that for them. It’s also a good way for them to learn using Wordpress.

I guess you could move up to production and protect the site with htpasswd while they’re add their content. But then you won’t be able to have a placeholder site at the same time (if adding content takes along time, that’s not so good).

---

## Post 25 by @jmjf — 2013-11-06T19:40:08Z

> [@intelligence](#):
>
> But would it be better to bring in the client at production?

The situation I’m envisioning is four environments. Vagrant for the web developer, Vagrant or [content-dev.xyz.com](http://content-dev.xyz.com) for clients developing content, [staging.xyz.com](http://staging.xyz.com) for user acceptance testing, [xyz.com](http://xyz.com) for production. The client-dev site can be a vhost on the same site as staging if needed. The trick to making that works is some kind of tool to package the database changes and clean up revisions, or work in progress before moving to staging and production. (This is one of those areas I want to research more, but haven’t gotten to yet.)

Many sites I see in the gallery look like they have rarely changing content. In this case, there’s no reason the client couldn’t provide the copy and the developer install that copy in the site (create posts/pages). If there’s a blog/news component or other dynamic aspect, it’s possible to identify and isolate that data and manage it appropriately. If the client wants to edit copy directly, see paragraph above.

The client selling point is control and security. See [HMV’s Twitter debacle] ([Inside HMV’s Twitter Disaster: What went wrong (and how to keep your company safe)](http://www.linkedin.com/today/post/article/20130214190038-2967511-inside-hmv-s-twitter-disaster-what-went-wrong-and-how-to-keep-your-company-safe)) and imagine someone doing something similar on the client’s site. That isn’t an issue if you’re dealing with a sole-proprietor client, but if the client organization has several employees and someone other than the owner/CEO is doing most of the site management, the owner/CEO or his highly trusted designee should check content before it goes into production and should want content migration to happen in a way that it can’t be changed after s/he approves it.

The same rationale raises the question, do you really want people to be able to comment on your pages and posts?

EDIT: Yes, WP has a contributor/approver system. I’m still not sure I would want to see edits happen in production if I could find an efficient way to extract the data and move a script instead. Some long-winded, non-copywriter decides to rewrite a finely tuned 50-word paragraph into a 750-word babble that breaks the flow of the site and SEO. (My real job is in a very risk-aware organization where nothing goes into production without careful controls, so I tend to be paranoid about this kind of stuff.)

---

## Post 26 by @swalkinshaw — 2013-11-06T21:17:22Z

WP-Stack was great when it first came out but it’s a bit behind the times. The way he uses Capistrano isn’t great and it’s also using the old v2 version. Capistrano v3 is much simpler, faster, and better. There’s also nothing Rails specific in the core Gem anymore which is great.

The “stack” that we’re working on is Chef based but I’ve also been thinking of switching it to Ansible. It’s much simpler and easier to use especially if you don’t have Ruby experience.

---

## Post 27 by @jmjf — 2013-11-06T21:57:46Z

My main interest in WP-Stack (after the Ruby nightmare @\_@) was sorting out what it did so I could replicate it in something else.

I know enough about Ansible to be dangerous. I’m building a set of roles to prepare a WP-ready web server on Debian based on VVV in my evening research time. Parts of that could probably be easily modified to align with your Chef.

My real job gives me vacation, and I have most of it scheduled in December, so I should have some time on my hands that I can throw toward helping out with an Ansible experiment if you’re interested.

---

## Post 28 by @swalkinshaw — 2013-11-06T23:41:00Z

That could work. Not exactly sure what the plan is right now since the Chef stuff is basically done. Might be a future project to switch over.

---

## Post 29 by @ajmalafif — 2013-11-07T01:17:51Z

This has to be my favorite topic in Roots by far. Learning so much just in 1 topic it’s crazy! Not to mention the awesomeness of Roots itself.

And then I have to mention Bootstrap. WordPress. On and on and on. OSS is too awesome.

I’m nowhere near you guys with this workflow and it’s been great to learn a lot from this topic. Can’t wait for @swalkinshaw updates about Caps. I can’t do much to contribute but I do use [Pagodabox.com](http://Pagodabox.com) for most of my clients. If there’s anyone using that (or interested) I can write and share my QuickStart recipe and some stuffs I learn the hard way working with PB. I’ll say those who use WPengine and love the git-based workflow might consider PagodaBox as one of the alternatives for their tools.

---

## Post 30 by @MintyBear — 2013-11-10T23:05:44Z

Can’t wait to see the wp-stack but just what I’m using at the moment:  
wp-migrate-db-pro plugin to move the database around  
Using grunt ftpush to deploy the project (only the appropriate folders) to my server, this stores the changes a bit like git so it only pushes up new changes.

Probably not the most optimum setup but it works pretty well. Going to look into ansible now though.

---

## Post 31 by @mauro — 2013-11-27T15:20:08Z

@swalkinshaw Hi Scott, I was wondering how the new screencast is comming along. I have a new website pending and would love to use what you can teach us for the new deployment.

Thanks again for all your work,

Mauro

---

## Post 32 by @swalkinshaw — 2013-11-27T16:58:31Z

By the end of this week I promise (weekend)! Finally have a good 4-5 days of more time to finish it.

---

## Post 33 by @swalkinshaw — 2013-12-02T04:36:12Z

For those waiting on the screencast, I’m 90% done and it looks like I’ll break my promise a bit but the screencast should be up in the next day or two. Unfortunately it’s always the editing and final publishing that take the longest :frowning:

---

## Post 34 by @swalkinshaw — 2013-12-09T18:28:18Z

Screencast is finally out! [http://roots.io/screencasts/deploying-wordpress-with-capistrano/](http://roots.io/screencasts/deploying-wordpress-with-capistrano/)

Sorry for the long wait but making these screencasts is actually pretty time consuming! I’ll probably start a separate thread for feedback/questions about it.

---

## Post 35 by @ajmalafif — 2013-12-10T05:11:58Z

Awesome stuffs gonna get it when I get back home! Can’t wait!

---

## Post 36 by @swalkinshaw — 2013-12-10T15:55:24Z

I’ve made a thread dedicated to the screencast/general Capistrano talk here: [Deploying WordPress with Capistrano screencast](http://discourse.roots.io/t/deploying-wordpress-with-capistrano-screencast/863)

---

## Post 37 by @merchantguru — 2013-12-10T18:29:51Z

Keeping databases in sync in my opinion is one of the more difficult challenges to solve, yet least talked about on forums about deployment. After a ton of different approaches, here’s what I recommend:

1. **[WP Migrate DB Pro](https://deliciousbrains.com/wp-migrate-db-pro/)** If you’re a WP developer, it’s one of the best ways to spend $99. It is SO easy to push and pull databases between local, dev, prod, etc., including updating URLs that have been serialized in widgets. You can push the entire db, or select which tables. This helps if you simply update the wp\_options table or wp\_posts/wp\_postmeta. The only downside is that currently you need to run it through a browser in the WP admin, but they are potentially working on a command line solution. They also have a beta add-on for keeping media files in sync, due out in the main plugin soon.

2. The next best option is to set up **[wp-cli](http://wp-cli.org/)**. This allows you to run WordPress commands via the command line, and you can hook in and create your own. It has a built in search-replace function to update URLs & serialized data (it actually used the [interconnectit search-and-replace](http://interconnectit.com/products/search-and-replace-for-wordpress-databases/) mentioned elsewhere here). What I do to prepare the database is to use the search-replace function to update the URLs, export it via wp-cli, and then take that dump.sql and import it into the target database somehow. Easiest is via phpMyAdmin or Sequel Pro. OR, I have also written simple scripts that SCP the dump to the server and then import it via mysql command line.

3. Use **[interconnectit search-and-replace](http://interconnectit.com/products/search-and-replace-for-wordpress-databases/)** in your project. This has a browser base or CLI option. I’ve used the CLI as a part of a custom deploy bash script.

4. Use **WP Engine**. They have a push button production to/from staging setup which also allows for full or table-based db migration. Downside is that you still need to do one of the other options above for deployment to/from local. And, if you want to do any of the great Capistrano kind of stuff mentioned in this post, you are out of luck with WP Engine since they do not allow SSH access.

---

## Post 38 by @treb0r — 2013-12-10T20:54:27Z

Hey merchantguru,

Wish I read this post before i posted to the capistrano screencast thread.

I too am looking to solve the database issue.

Option 2 sounds like the best plan, although i just use sed for find and replace, works a treat.

---

## Post 39 by @nball — 2013-12-13T21:54:04Z

For all the love (or addiction) I have for Railsless Capistrano it always seemed wrong. Better to stand on the shoulders of giants: [http://tech.toptable.co.uk/blog/2013/08/08/grunt-your-deployments-too/](http://tech.toptable.co.uk/blog/2013/08/08/grunt-your-deployments-too/)

I realize I’m super late to the game on this but just thought you’d find it interesting. I’ll be giving this a whirl in an upcoming Roots site.

---

## Post 40 by @swalkinshaw — 2013-12-13T22:26:22Z

Keep in mind that Capistrano v3 was rewritten and no longer has anything Rails specific in it. You actually need to require Rails gems for it if you want. v3 is generally must better, simpler, and faster.

---

## Post 41 by @merchantguru — 2014-01-27T05:21:31Z

Sed works to find and replace URLs that aren’t serialized, but widgets and plugins often serialize their entries, so it’s possible you’ll miss some serialized URLs if you just use sed.

---

## Post 42 by @treb0r — 2014-02-01T13:26:39Z

Er, yes. Just learned that the hard way. Thanks :wink:

---

## Post 43 by @merchantguru — 2014-02-01T16:08:45Z

I’m telling ya, once you get wp-cli installed (It’s included in [VVV](https://github.com/Varying-Vagrant-Vagrants/VVV), along with grunt, Node, Composer), it’s a handy tool. To search/replace with whatever URL is already in the db, here’s what I use. It finds the existing URL and replaces it across all tables.

```
wp search-replace `wp option get home` http://local.domain.com
```

Equivalent to:

```
wp search-replace http://www.domain.com http://local.domain.com
```

But I’ll still say the easiest way to migrate dbs is to use WP Migrate DB Pro. Once you get it set up, you can push/pull databases all over the place with a click of a button, so you can really iterate rapidly between environments.

---

## Post 44 by @treb0r — 2014-02-01T17:43:42Z

Yes, agreed. I’m using WP Migrate Pro right now. Still not had chance to play with wp-cli but I have it installed.

---

## Post 45 by @mjc — 2014-02-12T11:03:48Z

jplew has a promising [script based solution](https://github.com/jplew/SyncDB) for syncing the WP database and uploads/assets.

I’m just starting a new WP project with Roots (delighted when I found it) and am planning to do git deployment for the first time so I’m quite a noob at all this, but it feels good to be doing things like a Grown Up. At the moment jplew’s script is my first choice for tackling the DB/assets dev/prod sync question.

---

## Post 46 by @intelligence — 2014-02-16T11:55:08Z

This might be an option:

> **[wp-sync-db/wp-sync-db](https://github.com/wp-sync-db/wp-sync-db)**
>
> A WordPress plugin that lets you push, pull, and sync database tables between WordPress installations. - wp-sync-db/wp-sync-db

Haven’t used it yet, stumbled upon it a while ago.  
Should be the same as Migrate DB Pro, but free.

---

## Post 47 by @merchantguru — 2014-03-20T16:35:09Z

@mjc, thanks for pointing out [SyncDB](https://github.com/jplew/SyncDB). That script is essentially a much better way of doing what I’ve hacked together with bash scripts + Search-Replace-DB. Assuming it works, it has the potential to finally complete my automated, fully-CLI workflow for syncing whole WordPress websites. I might even be able to use that for my Magento syncs.

---

## Post 48 by @ttss — 2014-07-27T19:27:21Z

@treb0r all fine with wp db migrate pro? we’re considering to get the 100 license in order to solve once for all the serialization problem. What about integrating wp db migrate pro with composer, is it the same plugin code which you install from wp packagist? If not, how to integrate the pro version in composer? Thanks

---

## Post 49 by @treb0r — 2015-02-23T13:55:48Z

Er, sorry for the extremely late reply, missed this before.

Just for the record, I’m still using WP Migrate DB Pro and it works fantastically well with Bedrock.

I did toy with the idea of adding a Capistrano task to handle DB migrations but I’ve found that it makes a lot of sense to handle the DB separately. Sometimes you just need to update the theme files or the plugins and you don’t need to touch the database.

I’m using the wp-cli add-on for WP Migrate DB pro to schedule nightly backups of all of my client sites back to stage. Works great, can’t recommend it enough.

The media files add-on is also really useful.

---

## Post 50 by @thiagodebastos — 2015-03-19T14:28:58Z

@treb0r  
Not sure if this helps but I use wpcli and some aliases:

```
dbpullP='be cap production wpcli:db:pull'
dbpullS='be cap staging wpcli:db:pull'
dbpushP='be cap production wpcli:db:push'
dbpushS='be cap staging wpcli:db:push'
```

I’m newish to all of this, why would I need to do more than this? Is it for purposes of automation when you have to manage lots of sites?

**edit** : the `be` is for `bundle exec`

---

## Post 51 by @treb0r — 2015-03-20T00:37:57Z

It’s just nice to have the flexibility I guess.

Each to his own, but I do really find that this plugin is indispensable when dealing with multiple copies of the same site.

---

## Post 52 by @dgbrt — 2015-04-29T18:49:21Z

Hi there, can you confirm that the media files addon works with bedrock? I had wanted to buy a license but didn’t go through as I read somewhere in their doc that it wasn’t compatible with Wordpress core in its own folder (as it is in bedrock). Thanks

---

## Post 53 by @treb0r — 2015-04-29T19:33:22Z

Yes, I can confirm that the media files add-on works great with bedrock.

I’ve been using WP Migrate DB Pro since just after it came out. I have ~50 WP installs active and using it and all of them are built on Bedrock.

I’ve said this before elsewhere on here, but after experimenting with automating DB migrations as part of the deploy process I have come to realise that it makes a lot of sense to handle them separately.

When you get used to using the plugin every day, the license fee starts to feel like a bargain ;-).

---

## Post 54 by @JulienMelissas — 2015-04-30T01:28:02Z

> [@treb0r](#):
>
> When you get used to using the plugin every day, the license fee starts to feel like a bargain

+100 to this - it’s an amazing tool to have

---

## Post 55 by @merchantguru — 2015-04-30T04:40:58Z

> [@ttss](#):
>
> What about integrating wp db migrate pro with composer

New tutorial on this, via @brandon:

> **[Installing WP Migrate DB Pro (commercial plugin) via Composer](https://deliciousbrains.com/wp-migrate-db-pro/doc/installing-via-composer/)**
>
> All of our premium plugins and addons can be installed using Composer, similar to how our free plugins can be installed using WordPress Packagist. Generate API Credentials Visit My Account…

---

## Post 56 by @merchantguru — 2015-04-30T04:47:45Z

> [@treb0r](#):
>
> using the wp-cli add-on for WP Migrate DB pro to schedule nightly backups

Great idea. Would love to hear more about how you do that. Do you run those via cron? Does that work well as your main backup/restore solution? I already use it as my main db migration tool… wondering how it may serve as backup strategy, too.

---

## Post 57 by @treb0r — 2015-04-30T11:24:16Z

Yes, with cron. Once you have the migration profiles set up in the GUI you can call them using wp-cli.

I’m not actually doing the nightly backups to the staging server(s) at the moment, I think the best way is to have a fourth host just for backups for each live site. We use staging for showing off new features to the client and the backup was getting in the way. I also find that attended backups give me more peace of mind.

All in all, the Sage / Bedrock / WP Migrate DB Pro setup has just totally revolutionised the way I work and I’m extremely grateful to all concerned. I’ve been building websites for a living since 1994 (showing my age!) and this is the first time I’ve felt really confident not just in the building but also in the ongoing maintenance of the client sites.

I know some people who find the rapid pace of change around here off putting, but I’ve embraced it which really keeps me on my toes. Every new evolution brings something amazing to the party. I only just started using Bedrock-Ansible and it has blown my mind :wink:

---

## Post 58 by @treb0r — 2015-04-30T14:15:47Z

…and by the way, yes, you can use WP Migrate DB pro for backups / restores just as easily as you can use it for migrations. You can even just restore specific tables if necessary.

---

## Post 59 by @treb0r — 2015-05-01T14:29:30Z

A timely article about scheduling DB backups with WP Migrate DB Pro and Cron: [https://deliciousbrains.com/wp-migrate-db-pro/doc/scheduling-migrations-backups-cli-addon/](https://deliciousbrains.com/wp-migrate-db-pro/doc/scheduling-migrations-backups-cli-addon/)

---

## Post 60 by @merchantguru — 2015-05-01T18:05:08Z

Ha! I was just about to post that article here, too. They are considering an add-on to allow scheduling migrations and backups via the UI. Anyone interested in that should email them so they decide to do it.

So, do I understand correctly that you have a backup server, and you push the migrations there? Does that mean you need to set up working versions of each of your sites there? That seems like a lot of work for a backup solution, but maybe not. Thoughts?

---

## Post 61 by @treb0r — 2015-05-01T20:39:29Z

I have backup VMs for two of the sites that I look after. In the age of cheap DO droplets I think it makes sense to always use a separate VM for each of the stages for each site (dev, stage, production, backup). Particularly if you’re getting paid to look after the site (I always get the client to pay for the production VM directly, I pay for the rest).

Given the power of Capistrano, Composer and now Ansible, it’s almost completely effortless to set up working versions of the sites on the backup VMs so why not? It’s a great way to make sure the backups are good too. This strategy frees up the staging VM for presenting new stuff to the client when required while still retaining a nightly synced backup of the production site. Works for me.

---

## Post 62 by @merchantguru — 2015-05-22T20:39:46Z

I like that concept, and you’re right, for $5 with Digital Ocean, you can have a working replica you can revert to. Thanks for detailing that for me.

---

## Post 63 by @ben — 2022-02-26T03:20:01Z