Chassis

This is the new fangled development environtment base using Vagrant + WordPress

Prerequisites

Before using Chassis, this is how your system should be set up:

• Install Vagrant

• Install vagrant-hostsupdater to access via vagrant.local:

    vagrant plugin install vagrant-hostsupdater
  

  Note for Windows users: You'll need to set C:\Windows\system32\drivers\etc\hosts to be writable by your user. Simply head to the properties and add your user with full control under security.

  Alternatively, add vagrant.local to your hosts file with 192.168.33.10 as the IP address.

Using

# Clone this repo
git clone --recursive git@github.com:Chassis/Chassis.git myproject
# If you forget --recursive:
# git submodule update --init

cd myproject

# Clone the content/ directory!
# git clone git@github.com:yourcompany/yourproject.git content

# Use https://github.com/Chassis/Supercharger as a base, and follow the
# instructions there.

# Boot up a VM
vagrant up

Make sure you copy local-config-sample.php to local-config.php

Working with the VM

# Start the VM
vagrant up

# SSH in to the VM
vagrant ssh

# Reprovisioning (e.g. after updating this repository)
vagrant provision

# Reprovisioning without a full apt-get update
vagrant provision --provision-with puppet

# Updating your hosts file (If there is no IP for vagrant.local)
vagrant up

# Suspending (sleeping) the VM
# Note that this doesn't remove the hosts entry
vagrant suspend

# Halting (shutting down) the VM
vagrant halt

# Destroying the VM (if your VM is completely broken)
vagrant destroy

Configuration

Chassis contains a flexible configuration setup, allowing you flexibility in overriding the defaults. Chassis follows the following loading procedure:

• content/config.local.yaml (project-specific overrides)
• content/config.yaml (project-specific defaults)
• config.local.yaml (global overrides)
• config.yaml (global defaults)

Multisite

Chassis has full support for running WordPress in multisite mode. Here's what you need to do to enable it:

1. Add multisite: Yes to your config.local.yaml or project configuration.

2. Provision your VM!

   (Note: due to a bug, you need to destroy and recreate an already-provisioned VM. We're working on fixing this.)

That's it!

Adding "Real" Domains

We've realized internally that using vagrant.local doesn't always cut it for development, as you may need to use a different domain for testing. Thankfully we can fake it 'til we make it by overriding the default configuration.

1. Add your hosts to your YAML configuration. We recommend using your project-specific configuration (content/config.yaml), since it's part of the site's configuration.

   hosts:
       - vagrant.local
       - example.chassis.com.au

   (The first host in the list will be used as the machine's name. We recommend leaving this as vagrant.local for the most part.)

2. Reboot your VM (vagrant reload)

MySQL Database

Your database can be configured completely via the YAML configuration. This is where the YAML hierarchy is most useful:

• config.yaml contains the default (User wordpress, password vagrantpassword)
• config.local.yaml can contain your "real" database details. These can be generated by a deployment script, such as Capistrano.

Updating

# Pull and rebase (in case you have project-specific commits)
git pull --rebase

## Update submodules (Puppet modules and WP)
git submodule update --init

Update Your Submodules

Sometimes we have to change the submodules because a repository isn't being regularly maintained. e.g. Use Puppet Labs's apt module. When this happens you'll probably get confused by submodules so here are the commands you need to run to get your submodules up to date again.

git submodule sync
cd puppet/modules/apt
git checkout master
git pull

# Ensure your VM is up-to-date
vagrant provision