A WordPress Core Vagrantfile

3 thoughts on “A WordPress Core Vagrantfile”

  1. I’ve been working on a fun setup with Vagrant and WordPress (and Puppet) and trying to get it working. It semi-works now but not 100% where I want it.

    What I am going for is a WP site that is managed via GIT and through that automatically uses a different MySQL database based on the GIT branch that is checked out. Master would have a DB, 3.5-branch has it’s own DB. All of this is driven by the checked out branch in the .git/HEAD file. Since it dynamically pulls the DB name you can easily have a **single** WP codebase with all the themes/plugins shared and to go from testing WP 3.5.2 vs trunk you simply checkout a different branch in git.

    I’ve got that part working with 2 or 3 extra wp-config.php lines which can easily be stored in GIT since Puppet creates and sets the MySQL user passwords but haven’t been completely happy with the flow if someone just cloned the WP Vagrant repo and being able to move around in different branches.

    Any thoughts on this type of setup vs having multiple WP installs all in one directory? Trying to keep things super simple but at the same time very flexible/extendable.

    1. That’s a good question. I think there are a few ways to approach the testing of multiple WordPress versions quickly. I’m inclined to go toward a model where each install exists at the same time rather than switching back and forth. This allows side by side testing in a browser when looking for visual regressions. Would love to test out your current setup and see how it feels.

      1. I was going to suggest firing up another Vagrant VM. But obviously, that’s going to waste a *lot* of resources on the host.

        But yes, you could handle that pretty easily with some sort of (semi-)automated adjustment of virtual host config, and maybe some additional deployment steps to export WIP from a branch into a “running copy” seen by the appropriate vhost’s version of PHP.

Leave a Reply