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

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.




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.


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?

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.

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:

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…

See and the one after it for info on git deploy.

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

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

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

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.

@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:

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

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.

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

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 This will introduce a lot of the concepts for the new stack tools.

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.

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…

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.

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

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.

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


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.