My biggest irritation with the WordPress ecosystem today is its use of Subversion for version control. When WordPress was conceived back in 2003, git wasn’t even a glimmer in anyone’s eye; git was just getting started in 2005 and didn’t really become the version control software of choice until the past 4 or 5 years. However, that is the period where WordPress has experienced its biggest explosion of growth. As such, new developers to the scene (such as myself) prefer to develop using git but are forced to use SVN for wordpress.org activities (such as core contribution and hosting plugins and themes on the official repositories).
Don’t get me wrong: I’m not blaming the WordPress team for sticking with SVN – their entire ecosystem is built around Subversion and switching over is no small feat. It’s just a case of bad timing. So since we’re forced into using Subversion for publishing plugins and themes, there’s a few little tools that mean you don’t even have to understand SVN at all to publish your code on wordpress.org.
Enter deployment scripts. There have been several versions of these floating around since Github became popular and people started developing their plugins and themes there. The one that I have to come to know and love is by Paul Clark (which in turn was forked from other scripts that preceded it).
First of all, you create a new file in the root of your codebase called deploy.sh, give it 755 permissions and add it to your .gitignore file:
In that file, you’ll paste the contents of Paul’s deployment script. Then you just need to edit the constants PLUGINSLUG (if different from the name of your working directory), MAINFILE and SVNUSER in the config section. That’s all the setup you need to do.
Then, you develop in git as per normal. When you’ve made all your commits and you’re ready to tag your new release and send it to both GitHub and wordpress.org, you run deploy.sh:
This starts the deployment process. First, it checks that the version number is consistent between your main plugin file and your readme file before asking you to provide a commit message. Then it tags the release and pushes it to GitHub.
Next, it creates a local copy of your SVN repository from wordpress.org. Then it places your latest commits into trunk and creates a new tag and also copies your codebase there. It then commits those changes back to wordpress.org, deletes the temporary SVN folder and finishes. All in all, the output might look something like this:
Now you can look at both your GitHub repository and wordpress.org and you should see both locations reflecting your newest version. There are other scripts which even convert README.MD to readme.txt (like Scribu’s) which I might build into this script as I think that’s a handy feature. What other features do you have in your deployment script?