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.
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âŚ
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.
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âŚ
@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:
Run the deployment process locally and transfer the build files to the production server.
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
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.
[/quote]
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
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/). 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.
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.
