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.
I’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://core.git.wordpress.org/. 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.
- 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. ↩