I work with WordPres a lot. It takes up a solid 12 hours of my day pretty much each day (minus weekends, because, you know, burnout).
I’m also fairly vocal about not being the greatest fan of it. It’s aged, does things weirdly, but it works. Reliably. Shout out to the thousands of people working on it. It’s actually amazing how much coordination goes on behind the scenes so only versions make it to release that won’t brick the portion of the internet everyone’s using. There should be a documentary about this.
But I digress... Occasionally though I do run into edge cases that I need to have fixed before I can continue to do my work with it. Those edge cases aren’t important for others, so the issues usually just sit tight for years. The repeated question I get asked is “well if you need it, why don’t you write the code?”, and while that question has its own problems when someone who’s not a developer gets that, in my case it was a perfectly valid question.
To which I used to say “because I’m not willing to touch svn”. Not even with git-svn. Just... no.
I’m still not going to poke svn with a stick. However, apparently, what you’re going to read about has been around for a while, but here's how to use a git-only development process for WordPress.
The assumption is that there is a trac ticket and you want to attach a
.diff file. Sadly sending pull requests is still not a thing so we’re stuck with the file upload method.
We want a
.diff file which contains our fixes for a trac ticket, including tests.
We also want to write tests, and run them with
qunit, whichever your fix needs.
Step 1 - grab the git version
Grab WordPress from its own git repo. Yes, there’s a GitHub repository, but that’s not the one we need. The one we need is this, as per this article from 2014 about the git mirrors on Make WordPress blog:
$ git clone git://develop.git.wordpress.org/ ~/Sites/wpgit
This will clone the right git version into your user’s
Sites/wpgit directory (assuming you’re on a linux / mac / using the Windows Linux Subsystem).
Step 2 - set up for testing
We will need a few things
- nodejs (I’m using 8.9.4)
- phpunit 6.5. Yes, the latest is 7.something, but WP’s tests break with phpunit 7, so downgrade to 6.5. I used the
pharway of installing it that’s described in their documentation
- you need a new database that’s specific for testing. It will get used, and deleted a lot. I suggest creating a new one
- copy the
wp-tests-config.php, and configure the database access details, and grab new salts
- run an
npm installto get all the libraries you’ll need for the tests (grunt, uglifyjs, etc...)
Step 3 - do the work
Once you’re on latest master, check out a new branch for your own work:
$ git fetch origin $ git checkout master $ git pull origin master $ git checkout -b feature/21112
Then you’re ready to do the work. Organise them into commits, commit them, do as you normally would with git.
Step 4 - test it!
After you’ve done the work, and wrote the tests, you can run them with
$ grunt phpunit
A few tests will fail (database not the right setup, imagemagick not installed, etc), but as long as YOUR test didn’t fail, and they got run, you’re good.
Step 5 - grab the
We need a
.diff file that contains the changes between the
master branch and ours.
$ git diff master... --no-prefix > some-feature.123.diff
This will save the git generated difference in a file called
some-feature.123.diff. Which is the file you want to upload to the trac ticket.
And done, that’s it. I did not have to touch svn. At all! So much win.
Original props go to scribu, whose article about the same issue was super helpful. I’ve decided to write this, because scribu’s article is 6 years old, and it was missing a few bits.