Chassis – When VVV is Too Much

It won't be everything to everyone, but it can be something for most people.

When I need to do WordPress core development, I use VVV. It’s great for multiple versions of WordPress, a copy of WordPress Meta, and it’s all done in one go.

But when I’m developing my own code, I want something a little lighter and simpler. I’ve been using Local for that for a while now. It involved a few weird tweaks but I was quite fond of it until the 2.0 upgrade. That’s because they broke the tool I needed most: Addon Volumes.

The current status is that it’s broken and the developer misjudged how many people used it. These things happen, but for me this was the primary reason I used it. So that meant it was time to look at my options again!


Made by the quirky and original Human Made, Chassis is a cross between VVV and Local.

Like VVV, it’s Open Source. Like Local, it’s fast. Like VVV, it’s command line. Like Local, you can map to your hard drive. And that last reason was why I wanted to use it.

Look. There are a lot of reasons to use Chassis. The fact that it’s a server, so you can test out things like Memcached and PHP versions and upgrades is a big one. The fact that it’s fast to install and setup is another. But at the end of the day, I need my dev environment to do the following things.

  1. Be ‘easy’ to rebuild
  2. Have access to WP-CLI
  3. Boot fast
  4. Have a GUI SQL editor
  5. Use my dev code, where I want it used from

My Development, My Way

The thing I hate about most dev environments is that they want you to put your code in their locations. MAMP, VVV, Local, and DesktopServer all prefer you to put your dev code in the folder for your dev site.

I don’t work that way. All my code for all my WP sites live in ~/Development/repositories/NAME or ~/Development/github/NAME or ~/Development/wordpress/plugins/NAME and this is a system that works for me. I have all my dev code in the Development folder, and I’m consistent about it.

Furthermore, when I use a local host install to test, I may use the same plugin on multiple sites. I try to reuse as much code as possible, after all.

This means my headache is always trying to some how symlink my development folders to my development site. With MAMP and Desktop Server I used rsync (and I was sad). With Local I used the broken add-on. With Chassis, it’s actually built in!

Build The House

Chassis touts that it wants to be invisible. In order to do that, they separate WordPress and your code, recommending you put your code in the /content/ folder. This is great, but as we mentioned, I want to have my code in another spot, so I need to map folders.

This can be done in the “Synced Folders” of the config.yaml file. I’ve added this:

# Synced Folders
# You can sync as many folders as you like. We sync the nginx and php log folders by default.
    logs/nginx: /var/log/nginx
    logs/php: /var/log/php
    /Users/ipstenu/Development/repositories/site1-genesis: /vagrant/content/themes/site1-genesis
    /Users/ipstenu/Development/repositories/site2-genesis: /vagrant/content/themes/site2-genesis
    /Users/ipstenu/Development/repositories/site2-underscores: /vagrant/content/themes/site2-underscores
    /Users/ipstenu/Development/repositories/site1-plugin: /vagrant/content/plugins/site1-plugin
    /Users/ipstenu/Development/repositories/site2-plugin: /vagrant/content/plugins/site2-plugin
    #/Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/content/mu-plugins
    /Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/wp/wp-content/mu-plugins

Run a reload and a provision of vagrant and it all worked. That’s right, it was all silently symlinked and had full access to all my code in all the right places… Except…

Mostly Ugly Plugins

You may notice this:

    #/Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/content/mu-plugins
    /Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/wp/wp-content/mu-plugins

The first one didn’t work. The second one did, but only when I added this to my local-config.php file:

define( 'WPMU_PLUGIN_DIR', '/vagrant/wp/wp-content/mu-plugins' );
define( 'WPMU_PLUGIN_URL', $_SERVER['HTTP_HOST'] . '/wp-content/mu-plugins' );

I’m still not sure if I broke it or if they did. What I do know is that I can rather easily build out my dev server, point it to my dev code, and everything’s working.

Conclusion: Should you use Chassis?

I firmly hold that all developers should be familiar with the shell. Maybe they’re not all golden goddesses, but they should know how to get around, list files, and Google the basic commands like links, rsync, move, copy, and delete. With that in mind, if you’re a developer (be it a code developer, a design developer, or anyone else who peeks under the cover at the code), you should give Chassis a try.

It’s open source, so you can learn from it if you’re so inclined. It’s command line, so you can script it if you’re so inclined. You can separate your plugins from the plugins of the extensions, like debugging, and you can write your own if you want.

Basically yes, you should use Chassis. It won’t be everything to everyone, but it can be something for most people.

One comment

  1. Thanks for the write up on Chassis. We’re glad you’re enjoying it. Nice workaround for the mu-plugins as well. I might try and replicate that during the week and see if I can figure out a workaround.

    I thought it’s probably worth mentioning that we’re also working on a UI for Chassis as well which you can findhere it’s still super new and very beta but we’re getting there!

Comments are closed.

%d bloggers like this: