I’ve submitted a few patches for WordPress core on Trac (one of which has been used) but every time I think about doing it I cringe because my setup for doing so is incredibly tedious.
Can someone please detail out the steps needed to submit a patch for core, and then the best way to streamline the process so it’s not so tedious? I work Mac OS X and PhpStorm currently but I’m thinking a shell script might be easiest? Or maybe a PHP Script that does all the rote work?
One of the issues is I don’t fully understand what I need to be starting with. Do I start with trunk? Do I have to download a new copy and add to/edit that copy with my code every time I want to create a patch?
Again, while I have done it working with SVN and patching is really outside my current skillset and I want to change that. Hoping you WordPress patching experts can come to my rescue. Thanks in advance.
After @hakre’s answer I figure I should add more to the question:
- Can I create patches from older version or must I use trunk?
- If I’m working on a project using the released version (3.0.1) can I modify it and create a patch for core or do I have to download and set up a pristine and new copy of trunk and newly make my modifications there?
- Can I do with shell scripts so I can encode the login into the script and just run the script to recreate everything I need and/or to create the patch?
- And what are the pitfalls?
All of these questions seem to be assumed by those who know how WordPress’s SVN works and as such are always glossed over in any discussion.
The easiest way to create a patch is described here:
Can I create patches from older
version or must I use trunk?
You should create the patch against the same version you want it applied against.
In other words, don’t expect a patch created against WP 3.0.1 to apply cleanly on WP 3.1-alpha.
If I’m working on a project using the released version (3.0.1) can I modify it and create a patch for core or do I have to download and set up a pristine and new copy of trunk and newly make my modifications there?
You don’t have to set up a new installation for each new patch. You can just use svn revert to get back to a pristine copy.
Also, the database doesn’t have to be clean each time. Actually, it’s better if you have some modifications, to simulate a live environment.