How to Use Subversion with the WordPress Plugin Directory

I decided to make this clear, plain English tutorial to completely explain how to use subversion with the WordPress plug-in directory check it out. If you don’t already have one you need, a wordpress.Org user account go to wordpress.Org, you can do forums, then click register fill it out.

It’s like any other registration process. Next, you need to request space in the WordPress plug-in directory, go to wordpress.Org, extend plugins, add you’ll, need to login and then put in the details of your plug-in. If you have not finished developing your plugin, you can leave this blank. Then click send post and it’s time to wait, your plug-in space will be approved by a real live breathing human being rather than by machine.

So it can take a couple of days. That’s why we did this step first, before moving on, while you’re waiting for your spot in the plug-in directory, you need to get a subversion client installed on your machine. This tutorial is done on Windows, so we’ll use tortoise SVN if you’re on a Mac. I understand SC plug-in is similar and quite a good solution. Next pick a directory on your local machine for all projects, you want subversion to track, I’m in a Documents folder in a projects folder, which, incidentally, I know, is automatically backed up twice a day.

I created a directory called WordPress plugins public. Let me point out a mistake. My friend made, so you can avoid it on your local machine. You may have a complete web server installation, including Apache, PHP and so forth. Then you have a wordpress installation where you are testing and developing your new swank plugin. It’s important for you to realize this copy of your plugin is completely separate from the copy that needs to be managed in the subversion directory.

We just got done making more on this later. Eventually, your request for a spot in the plug-in directory will be approved and you’ll receive an email like this. The most important part is at the top. It’s a URL to your SVN repository you’ll need this link for our next step, where we start tracking your project with your subversion client. Let’s return to the folder we made for subversion to store local copies of your development projects inside here.

Let’s create a new folder for your plugin, I usually name the folder after the endpoint of the plugin directories, URL to start tracking your project. We need to hook up your local development folder with the directory created on the subversion server. Right-Click, your local project folder and choose SVN check out the first field. Url of repository should be the URL you received in your approval, email from wordpress.

Org. This is the location of your project on their subversion. Server checkout directory is the folder on your local machine subversion uses to track your project because you started the checkout process by right-clicking that folder in the first place. This should be set correctly. Leave the other settings as shown and click. Ok, your subversion client begins pulling all of the files as they currently stand on the subversion server.

For my plugin there are several files already there. That’s why you see so much activity for a new plugin. You won’t see much activity here at all. Click. Ok, then open the local folder for your project now you’ll see an invisible folder called SVN and branches tags and trunk will discuss these next in your subversion project. Folders trunk is where the latest development should be stored. So in your development environment get done with changes to your plugin.

At this point, any updates to your readme text file also need to be finished, then select it all copy it and paste it into trunk. After you copy your changed files to trunk, you need to update the subversion server right. Click, your local subversion project, folder and choose SVN commit leave yourself a message about this commit if you need to and review the changed files below these two files have changed and will be sent to the subversion.

Server click. Ok, as the files are updated on the subversion server you’ll be updated. Here, click! Ok! When you’re done once you’re ready for the public to use your plugin, you need to tag a version to set aside and leave alone in your local subversion project. Folder right click on trunk and choose SVN branch tag in the to path field. After the name of your plugins folder, add a forward slash the word tags, another forward.

Slash and a version number for this release. Add a message for this tagging. If you need it and leave these other settings alone, then click OK. Subversion is now creating a copy of what’s found in trunk on the subversion server. It’s creating that copy in a subdirectory called tags and another subdirectory called zero point. Nine point: nine: when subversion finishes creating this newly tagged copy, you may receive a notice about your working copy on a previous path.

You can safely ignore this notice that newly tagged version was created on the subversion server. We need to pull those changes down to our locally managed subversion project folder, now right-click the project folder again and choose SVN update this pulls any changes from the subversion server that are not reflected in the local copy of your project. Your final step to let the public use your newly tagged version is to update the readme text file in the projects trunk folder.

This is because the WordPress plug-in directory looks specifically inside trunk at the readme text file for the stable tag it uses that information to decide what the most current version is for the public. We just tagged a zero nine nine version of content scheduler, so we changed that Keir save the file, and now we need to right-click on the local subversion project. Folder again and choose SVN commit it’s important to understand the rest of the readme text.

File found in trunk is ignored. You may know the plug-in directory uses the readme text file to build your projects page in the directory, but it uses the readme text file from the stable tagged version: here’s zero nine eight. It will look in tags, zero, nine, eight and use that readme text file to build your projects, information throughout the life of your plugin. The cycle continues in your development environment.

You make changes to your plug-in test it and also keep the readme text file up to date with any change. Log information FAQ s and so forth when you’re ready to commit copier, changed files and paste them into trunk, and your local subversion project folder make sure the readme text file in trunk still indicates the correct, stable tag version you want the public to use. At any point, right-click your local subversion project folder and choose SVN, commit to move your changes in trunk over to the subversion server again.

As long as the readme text file in your trunk folder indicates the correct current version. Nothing will change for the public once you feel. Your new developments in trunk are ready for the public. It’s time to tag a new version, remember just as before, visit trunk, right-click, SVN branch tag and follow the directions as before in the article


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s