Skip to content

Publishing Releases

Freddie Mixell edited this page Aug 30, 2019 · 2 revisions

When you're maintaining a plugin it's important to make sure you do so consistently. This guide will serve as a standard for maintaining the YIKES Plugins.

When working on a plugin for the first time you'll need to set it up in a few locations on your computer.

You should have your local development environment but you shouldn't version your code or push code from a dev environment to your SVN repository.

I recommend creating a directory at the document root called svn-launchpad. mkdir ~/svn-launchpad (Mac/Unix Like OS)

Next:

cd ~/svn-launchpad && git clone https://github.com/yikesinc/yikes-inc-easy-custom-product-tabs.git (In this example we're cloning the Custom Product Tabs plugin but same workflow for any plugin)

SVN Ignore

You'll see a .svnignore file in the git repository. This is where you put anything that you don't want in the actual plugin. This means items like node_modules , build tooling like Grunt, Gulp or Webpack configurations can all be left behind. This will make your plugin lighter for the end user and allow you to keep git and svn working together seamlessly.

From here you'll want to zip your plugin for use in your development environment. From inside the plugin run: zip -r ../yikes-inc-easy-custom-woocommerce-product-tabs.zip *

This code is just saying .. one directory up create a zipfile called yikes-inc-easy-custom-woocommerce-product-tabs.zip and take * everything and -r recursively include each file.

Go back to the document root. cd

Now we need to download our script which will allow us to deploy these svn changes to our WordPress repository and update our plugin.

git clone [email protected]:GaryJones/wordpress-plugin-svn-deploy.git ( This example uses SSH, you should too, but if you don't know how just google WordPress Plugin SVN Deploy Gary Jones and copy the https link. )

Move the SVN Deploy script into the svn launchpad so it can see all of your plugin repos. cd wordpress-plugin-svn-deploy/ && mv deploy.sh ~/svn-launchpad

Now your SVN launchpad is all set up to push new releases of your plugin. You're never going to do any coding from this section. This is where you're going to be pulling down master, tagging a release and pushing it back to Github as a release. Then you'll push it through to SVN and your release will be complete.

Changing the plugin code

Let develop a change the the plugin now.

Move that zip file out of your svn launchpad we don't want it to confuse the deploy script. cd ~/svn-launchpad && open . This will open your svn launchpad folder. Drag the zip file onto your desktop or wherever you'd like. This file still contains the git repository history so we're going to manually install it and then make changes to our code there.

Once we've made a change on a feature or bug branch we'll merge with master. You don't need to push a new version of your plugin each time you make a change but if you did want to push a change this is what you'd do.

Updating WordPress.org SVN Repo

Go to the plugins WordPress.org repo for Custom Product Tabs its: https://wordpress.org/plugins/yikes-inc-easy-custom-woocommerce-product-tabs/#developers

Click on development and you'll find a link to the SVN repository. Click it and you'll see what WordPress has as far as whats shipping with the plugin.

Make sure your plugin file is the same as the WordPress.org svn repo. In the case of Custom Product Tabs that is https://plugins.svn.wordpress.org/yikes-inc-easy-custom-woocommerce-product-tabs/ I'll check to make sure I have svn-launchpad/yikes-inc-easy-custom-woocommerce-product-tabs if not I'll rename the directory to match .org On the SVN repo check the trunk. Make sure you have all the files in your git repo, make sure any files that SVN doesn't have are included in the .svnignore if they're not already. This is how we lighten our load and remove unnecessary development files. Make sure when you made your changes you changed the version of the plugin. If using search and replace be careful to not overwrite that version in the change-log, manually inspect each place you're updating the version. Tag your release and send it back to Github. If you're at version 1.0.0 you would do git tag -a 1.0.0 -m "Message about how awesome this release is!" git push origin master --follow-tags (Now you'll have a zipped up release in Github) You've double checked everything and you're ready to send it to WordPress. Let's run our deploy script we downloaded earlier. sh deploy.sh Fill out the questions making sure to read very carefully. For most questions just hit enter but if the plugin main file isn't named after the folder you'll have to type that manually. For the question about the temp folder just hit enter that folder gets deleted in the end. Enter your WordPress username and password, and then watch as the script automagically releases your awesome change to the world. You did it you're a plugin master.

Continued Testing

Download the plugin from the WordPress.org repository and make sure that its still working. Activate it, play with it, make sure nothing weird is going on. you should already have the previous version installed in another dev environment ideally and also update the plugin when WordPress finds the update.