Monthly Archives: July 2015

Laravel Homestead on HyperV

Update: 2015-11-11 – I’ve finished porting over the PHP 7 branches of settler and homestead. If you want to use PHP 7, follow the instructions on the standard Laravel docs site and here, except use johnpbloch/homestead-7 as your box instead of laravel/homestead-7.

Somebody sent me an email this morning asking me a quick question regarding my recent work getting Homestead running on HyperV 1.

Hello my friend,

I see repository on github about hyperv configuration to vagrant up. What are the commands to start the new machine on HyperV?


I really can’t see any good reason not to share the info with the rest of the world too, so I figured I’d put it in a blog post for the edification of everybody. Continue reading


  1. HyperV is a native virtualization hypervisor for Windows Operating systems. It uses SMB shares by default for mounted directories, which are way faster than VBox shared directories. In general, it blows virtualbox out of the water in terms of performance.

    At some point, I’ll need to write about even using it with Vagrant at all.

Upcoming changes to my WordPress fork

As you’re likely to know, I maintain a fork of WordPress that adds composer support. I won’t really go into any of the background or reasoning behind the origins of this fork, although that would probably be a good topic for a future blog post.

wp-composerI’m mainly just announcing some changes that are coming down the pipeline for the fork. If you follow me on twitter, you may have already seen much of this, so you probably have an idea of most of what I’m going to say.

I’m planning on re-forking WordPress into a new repository (probably named wordpress-core with the same change to the composer package) and turning johnpbloch/wordpress into a meta package that requires both the core package and the core installer package. This will allow me to keep the fork clean of any implementation details, including assumptions about how and where the user wishes to install WordPress itself.

So what does this mean for the composer package if you’re already using it? Nothing, hopefully. The only difference will be that the core files will get moved into a sub-package.

I want to explain my reasons for this change a little bit.

First of all, why am I fixing something that doesn’t appear to be broken? Well, because it’s too brittle, which is sometimes just as bad as broken. When I set this up, I threw together a bash script to keep it up to date. This script runs every 15 minutes on my server. It is fairly complex and difficult to extend or fix. I also want to rewrite it to be much more targeted in its work.

I would like to change the repository to be a real fork of the upstream mirror at git:// This will allow me to simply use git’s built-in remotes functionality to fetch upstream changes without losing contributor information, etc. Some people have gotten the wrong idea in the past regarding my motivations for maintaining a fork of WordPress and even accused me of doing it primarily to improve my contributor graph on github 1. While it’s true that haters are going to hate, I’d rather distance myself from even appearing that way, even if I had a good reason for not doing a true fork the first time around. Now that I know my issues with doing a fork from the official source have been resolved, I’m happy to make that change.

Finally, I just don’t think it makes a whole lot of sense to tie my installer to the core package. Not everybody will need it for their installation profile and/or workflow, so it makes no sense to require it across the board.


  1. This is, of course, not true. I don’t even pay attention to my contributions graph. The vast majority of my work is done in private repos for work. I’ve never considered those graphs to be a worthwhile metric for that reason. Without my WordPress fork my public contributions graph would most likely be in the low hundreds while my private graph would still be in the thousands.