I’ve been working a lot with Laravel lately and a really nice side effect of doing so has been using the very lean Laravel Valet for local development. It is super lean, super fast, and the more I use it, the less I want to be messing about with virtual machines.

What’s my beef with virtual machines?

Ok, I don’t actually have a beef with VMs. Or at least, I don’t have any more of a beef with VMs than what I have with most things (for those who know me.)

I’ve been developing on virtual machines for a while now. I started on VVV and more recently moved to Chassis.io and, honestly, it’s been a valuable experience but does make some aspects of the work more difficult. e.g; switching between projects to handle support related issues means I have to halt one box then up another which can sometimes take longer than the fix itself.

Oh and don’t get me started on resource usage.

VMs are still decent kit in my mind and will continue to play a role in my development work but for most projects I work on, I would seriously benefit from being able to quickly jump between them.

Enter Laravel Valet

Having worked with Laravel Valet on a few different projects now, I gotta say – I’m super impressed. New sites are practically instant, there is no DNS management required and it only uses, like, 7 MB of RAM…holy smokes! Turns out there is even a WordPress driver built into the system, so I guess there is at least one other person in the Laravel space also building on WordPress. Bully for me!

I don’t really see any point going through the basics of how to use it because the Laravel Valet documentation is (as always in the Laravel space) really nice and easy to follow.

What I do want to share, however, is my boilerplate.

WP Valet Boilerplate

I put together a boilerplate purely because I like torturing myself with distractions really like reducing the amount of thinking I have to do, particularly when firing up a new project.

So, I got to work on my own little boilerplate which brings a few good things to my table:

1. Array-based configuration

I’ve introduced the notion of a single PHP file that returns an array with a bunch of configurable items. This array is used to populate the local WordPress config, create and authenticate a user, install and manage plugins, configure WP Migrate DB Pro, configure SMTP, define log files, … and other things.

2. WordPress in a sub-directory

I just really dig having the WordPress core to be in a sub-directory, adjacent to my wp-content directory, when I work locally – it just feels so much cleaner and makes it much easier to change WordPress versions via Git or WP CLI. So, this boilerplate does that, too.

3. Remote image loading / proxying images from the live site

One of my biggest time sucks is FTP and media libraries. It drives me nuts – particularly when I bork my schedule and forget to do it in advance. For this reason, I always aim to proxy images from the live site unless they exist on my local disk as this means I rarely need to download media. I’ve previously been doing this with NGINX directives but, as far as I can tell (and may well be wrong), per-site NGINX config on Valet just isn’t easy.

Fortunately, Valet uses a PHP class-based driver system which can also support a per-project driver just by declaring a class named LocalValetDriver in the project root. By using a local driver, I’m able to check whether each requested URL is a file on disk and if it isn’t, load the same URI from a remote host via a PHP location header redirect. Love it.

For a look at some code on how to proxy images to a remote host on Valet, read this.

4. WP debug log outside of the wp-content directory

Nothing too grand here, but I hate log files just appearing an any willy-nilly directory. They belong in a log directory damn it, so that is where I’ve put them.

5. A ‘development’ log for dumping data to file instead of in the browser.

Not sure what else to say on this… *crickets*

6. A set of WP-CLI commands under wp valetbp for easy synchronisation with remote sites

I really, really dig WP CLI and I often use bash scripts to handle sync-related stuff. I thought it might be nice to set up a command instead, so I did. Details of the sub-commands can be found in the readme but it basically introduces a command to sync the database using WP Migrate DB Pro (buy it using this affiliate link, if you dare), change active states on plugins I only use locally, then log me back in. It’s kinda nice when things are automated.

A note on using it…

Now, I kinda really sorta maybe built this with myself in mind. So, for that reason, it’s probably pretty bias towards my own needs and wants and may not totally suit yours. Keep that in mind and feel more than free to fork it – who knows what I might copy from your fork…