Graft is the official virtual machine for Theme Juice, a powerful way to develop WordPress sites locally on your machine. Theme Juice is a cross-platform desktop application built on top of our open source command line utility, tj, that enables you to create, manage and deploy local WordPress development projects at the click of a button.

Graft VM is a high-quality LAMP development environment, configured specifically for WordPress development, that comes pre-packaged and pre-provisioned, so that you can get up and running as quickly as possible.

Vagrant is a "tool for building and distributing development environments". It works with virtualization software such as VirtualBox to provide a virtual machine that is sandboxed away from your local environment. It can be shutdown, destroyed and recreated at anytime, so feel free to break things!

Before you run vagrant up, please ensure you have the following software installed:

• Vagrant (>= 1.8)
• VirtualBox (>= 5.0)

Along with these Vagrant plugins:

• vagrant-triggers (>= 0.5.3)
• landrush (>= 0.18.0)

You can install the plugins with vagrant plugin install <plugin> if you do not already have them installed. To view your currently installed plugins, run vagrant plugin list from any directory.

You can either use tj to set up your development environment, or you can run the commands below from whatever directory you want the VM to be installed into:

git clone https://github.com/themejuice/graft .
vagrant up

• Ubuntu 14.04 LTS (Trusty Tahr)
• PHP 5.6
• MySQL 5.6
• Apache
• WP-CLI
• Composer
• Node 6.3
• NPM
• RVM
• Ruby 2.3
• Bundler
• Mailcatcher
• Memcached
• Xdebug
• phpMyAdmin (Dashboard)
• phpMemcachedAdmin (Dashboard)
• Webgrind (Dashboard)
• GD/Imagick
• SQLite
• cURL
• Git
• Vim
• Mcrypt

You can view things such as a PHP phpinfo() dump, phpMemcachedAdmin, phpMyAdmin, Webgrind and more through the main dashboard:

http://graft.dev

You may customize your PHP, MySql and Apache configurations by modifying their corresponding 'overrides' file within config/. The changes will be synced to the virtual machine on the next vagrant provision.

You may disable Mailcatcher and/or Xdebug from within the Vagrantfile via the Chef provisioning block. When changed, you will need to reprovision the VM by running vagrant provision.

The Chef provisioning block looks something like this:

config.vm.provision :chef_solo do |chef|
  # ...
  chef.json = {
    # ...
    xdebug: {
      enabled: false
    },
    # ...
    mailcatcher: {
      enabled: true
    },
    # ...
  }
end

There are an array of options given within the Vagrantfile such as PHP, Ruby, MySQL and Node versions, but none of these are guaranteed to work if modified from their current state. Those options are provided as-is and are not officially supported when changed; they are simply used for provisioning the box.

• Hostname: localhost
• Username: root
• Password: root

• Hostname: 192.168.13.37
• Username: vagrant
• Password: vagrant

Within config/php-config/overrides.ini, you'll see a section devoted to Xdebug. By default, it will be commented out. If you'd like to use it, simply activate Xdebug within your Vagrantfile (shown above), and uncomment the Xdebug settings within the overrides.ini file.

If you're not going to use it, I'd recommend that you disable Xdebug, as well disable the xdebug.profiler-related settings:

xdebug.profiler_enable = 0

Doing so should dramatically increase your virtual machine's performance. Be sure to run vagrant provision to put any changes/modifications you make into effect.

Ensure that Mailcatcher is enabled within your Vagrantfile, then visit:

http://graft.dev:1080

By default, if the vagrant-triggers plugin is installed, a script will run on halt and suspend that backs up each database to a project.sql file within the /database/backup/ directory. These will then be imported automatically on each vagrant up, even if your VM has recently been destroy'd.

This is done so that you have the freedom to run vagrant destroy without losing all that precious data stored within your databases. Just remember that the database is not backed up on destroy, so be sure to run vagrant halt before a destroy if you want to back everything up.

When a .conf file within config/apache-config/sites/ contains a virtual host with a *:443 port number, a self-signed SSL certificate will automatically be generated on the next provision. For example, a virtual host that looks like this,

<VirtualHost *:80>
  DocumentRoot /srv/www/tj-example
  ServerName example.dev
</VirtualHost>

<VirtualHost *:443>
  DocumentRoot /srv/www/tj-example
  ServerName example.dev
  SSLEngine on
  SSLCertificateFile "/etc/ssl/certs/example.dev.pem"
  SSLCertificateKeyFile "/etc/ssl/private/example.dev.key"
</VirtualHost>

will automatically get a generated certificate when provisioned. Once a site has a certificate, another one will not be generated until the old one is removed.

Since it's a little unintuitive, I'll link you off to this great tutorial on accepting a self-signed cert.

You may need to restart your browser to see this change take effect.

Know how? Create a pull request!

Know how? Create a pull request!

• Let us know! Don't hesitate to open a new issue on GitHub if you run into trouble or have any tips that you think we should know.

If you decide to take part in Graft's development, change the Vagrant box to ubuntu/trusty64,

Vagrant.configure "2" do |config|
  # config.vm.box = "themejuice/graft"
  # config.vm.box_version = "2.0.2"
  config.vm.box = "ubuntu/trusty64"

  # ...
end

that way we can be sure that we run the provisioners on a fresh box before building a new Atlas release. After provisioning the new release, SSH into the virtual machine and run the following commands to clean up:

# Clean up apt's cache
sudo apt-get clean

# Zero out the drive
sudo dd if=/dev/zero of=/EMPTY bs=1M
sudo rm -f /EMPTY

# Remove everything from /tmp
sudo rm -rf /tmp/*

# Remove any of your public keys
sudo vi ~/.ssh/authorized_keys

# Stop services and remove their PIDs
sudo service apache2 stop
sudo service mysql-default stop
sudo service memcached stop
sudo service mailcatcher stop
sudo rm /run/mailcatcher.pid

# Clear bash history and exit
cat /dev/null > ~/.bash_history && history -c && exit

We're using Berkshelf to vendor our cookbooks. You can see our configuration within the Berksfile. Before shipping a new build for the Vagrant box and uploading to Atlas, be sure to run berks vendor, so that the end-user can does not need to have Berkshelf or the ChefDK installed on their machine. Vagrant will use the cookbooks inside of the berks-cookbooks directory automatically when provisioning with Chef Solo.