For months I’ve been searching for an easier way to publish my code on Github to the WordPress.org repository without typing in SVN commands and finally I’ve found it.

I just wanted to point out that Git is my primary version control system and the wordpress.org svn repository is used only as a distribution mechanism. As far as I’m concerned I never want to type another SVN command, if SVN must be used then I would rather automate that whole side of things.

There is an interesting blog post that goes over the differences between using Git as your primary or secondary version control system and also documents a non automated way of keeping your GIt and SVN repositories in sync (even the commit history).

By this time you probably just want to see the deployment script…

The wporg-deploy.sh script can be viewed over on the Github repository for WPide, a plugin I’m actively developing (a WordPress code editor).

The script is simple to configure with just a few variables towards the top of the script that you will need to update with your own info:

# main config
PLUGINSLUG="wpide" # this is used to create the tmp directory so don't use spaces etc
MAINFILE="WPide.php" # this should be the name of your main php file in the wordpress plugin

# svn config
SVNURL="http://plugins.svn.wordpress.org/wpide/" # URL to the remote SVN repo on wordpress.org, with no trailing slash
SVNUSER="WPsites" # your svn username
SVNIGNORE="
backups
.DS_Store" #other files you you don't need to publish to the WP.org repo

Once you have a copy of the deployment script in the root of your plugin (in your git repo), that you’ve configured with your details, you can publish your plugin to the WordPress SVN repo just by executing the wporg-deply.sh script.

Your workflow then goes like this:

1) You make changes to your plugin in your local Git repository

2) Once those changes are ready for release (on the master branch of your local repo) make your final commit to update the version tags in your readme.txt file + main plugin file and update the changelog in the readme.txt file

3) Final step is to execute the ./wporg-deploy.sh script to publish the plugin to the WordPress repo over SVN

The script takes care of tagging the release on your local Git repo, pushing that tag to your origin (Github in most cases) as well as tagging the release on the WordPress SVN repo and uploading everything.

That’s it, you use Git as your version control system and you run the script to publish the plugin to the WordPress plugin directory, no more SVN commands!

I didn’t write this script. I found it on Github https://github.com/thenbrent/multisite-user-management/blob/master/deploy.sh after months of looking for an easier way to publish my plugins to the WordPress SVN repo.

The initial version of WPide is on the WordPress plugin directory.
The bigger, better version of WPide is over on Github (V2dev branch).

With the initial development of WPide I just wanted to replace the convenient but somewhat difficult to work with built-in theme and plugin editor with the Ajax.org Cloud9 Editor (http://ace.ajax.org/). I wanted to have line numbers, syntax highlighting, code completion for WordPress functions and backups of files just incase things go wrong.

Version 1 of WPide which is currently on the WordPress plugin directory achieves that, but it’s by no means perfect.

Over the last month I noticed a blog post or two talking about the WordPress theme/plugin editor needing improvements and even that the editor should be removed.That, combined with a real need for tabbed editing (no one is happy editing one file at a time) and some extra contributors to the project spurred me on to create version 2 of WPide. Main features being tabbed editing, using ajax for the saving/opening of files and remove the reliance on the built in editor (just in case it is removed in future). So now WPide has it’s own menu item in the admin sidebar and it’s own file manager that opens up access to the whole of the wp-content folder.

Although good progress has been made on V2, it’s still not ready for release in the WordPress repository (see Github for outstanding issues).  Although it’s not rocket science to download the development code from Github to try out the new version, it’s still 10x harder than installing a plugin from the WordPress repository. That’s especially true if the plugin is larger than your web hosts’ maximum file upload size so has to be done through SSH/SFTP.

Then yesterday on Twitter SanchoTheFat alerted me to an awesome PHP library called TGM Plugin Activation. When included in your plugin/theme, this library can be used to suggest or require additional plugins. Upon activation of your plugin/theme the user will be shown an alert with full details.

I have used theTGM Plugin Activation library in the WordPress repository hosted version of our plugin. Everyone now has an easy way to check out the new version of the plugin before release without having to even know github exists.

Clicking on either the alert from the TGM library or clicking the link on the WPide row of the plugin list will start the install process of WPide V2 (the development version, cutting edge, bugs and all).

So what’s cool about the TGM library?

For theme creators it means you can easily setup plugin dependencies. If your theme uses Contact Form 7 that requirement can be easily defined from within your theme. When the theme is activated the user will be alerted to the plugins required and given an easy way to install all plugins without them having to know where to find them and what version to use. The plugins don’t even need to be hosted in the WordPress repository! Plugin dependencies can be pulled from Github or any other URL.

Plans for WPide

I plan to get the outstanding issues with V2 ticked off in the next couple of weeks and get that version available on the WordPress plugin repository. Turns out the time I just put into adding the TGM library could have been enough to simply get V2 ready for release! That wasn’t because the TGM library is hard to implement, the challenges came from potentially running two versions of WPide on the same WordPress install, publishing the plugin to the SVN repository over at WordPress and then having to republish another version over to WordPress when things didn’t work quite as well as I had hoped.

The file manager needs more work as it currently doesn’t allow you to create new directories or files, only browse through existing items.

Once V2 is live I have another development branch on my local repository that includes some proof of concept code to push CSS changes from the IDE to the live website you have open in another browser tab. I also plan to try have this working in the opposite direction, so changes done on your live webpage using Firebug/inspector can automatically be fed into your open WPide instance to be saved. Sort of a live editor if you like. So you have one browser window open which is the WPide and in another window you have your live website; the CSS changes you make in the IDE will be shown in the live webpage (although it’s not actually live, you are just doing the same local/temporary updates just like with Firebug). Then when you are ready, all your changes can be saved and made live by clicking save in the IDE. Same could be done with JS files, .less, maybe even PHP.

As the editor uses the Ajax.org Cloud9 Editor (http://ace.ajax.org/) the syntax checking and highlighting isn’t that great for PHP. The Cloud9 editor is primarily a JavaScript editor so not as much development has gone into the PHP mode. Therefore a worker needs creating for PHP and I’m sure the PHP mode has room for improvements.

Code auto complete also needs improvement. I would like to see some separation between PHP autocompletes and WordPress function autocompletes. On the WordPress function autocomplete I would also like to show arguments to function calls and links through to the codex for further assistance on function calls, actions etc.

Right now you can potentially break a site by uploading a PHP file with syntax errors. In future syntax needs to be checked in PHP files before they are saved to disk to stop this EVER happening. In future maybe a WordPress worker needs to be created so that we can encourage developers to code to the WordPress standards, inline documentation etc.

All comments and contributions gratefully received!

]]> http://www.wpsites.co.uk/518-wpide-and-how-i-used-the-tgm-plugin-activation-class.php/feed 1 http://www.wpsites.co.uk/468-gravity-forms-adding-uk-specific-address-field.php http://www.wpsites.co.uk/468-gravity-forms-adding-uk-specific-address-field.php#comments Fri, 11 Nov 2011 00:00:05 +0000 Simon http://www.wpsites.co.uk/?p=468 Continue reading →]]> I haven’t used Gravity Forms much, as Contact Form 7 is our form plugin of choice, but today a client wanted to have the address changed on one of his Gravity forms. Just State changing to county and zip removing from the post code section.

On Gravity Forms the individual address fields are not that easy to change since the whole address field set is a single object, with a couple of options such as hiding address line 2. To change the address fields you need to put together some PHP to hook deep within the Gravity Form code and alter the output.

Here is the code that you will need to place in your themes functions.php file:

add_filter("gform_address_types", "uk_address", 10, 2);
function uk_address($address_types, $form_id){
$address_types["uk"] = array(
"label" => "UK",
"country" => "United Kingdom",
"zip_label" => "Postcode",
"state_label" => "County",
"states" => array("Aberdeenshire"=>"Aberdeenshire","Angus/Forfarshire"=>"Angus/Forfarshire","Argyllshire"=>"Argyllshire","Ayrshire"=>"Ayrshire","Banffshire"=>"Banffshire","Bedfordshire"=>"Bedfordshire","Berkshire"=>"Berkshire",
"Berwickshire"=>"Berwickshire","Blaenau Gwent"=>"Blaenau Gwent","Bridgend"=>"Bridgend","Buckinghamshire"=>"Buckinghamshire","Buteshire"=>"Buteshire","Caerphilly"=>"Caerphilly","Caithness"=>"Caithness",
"Cambridgeshire"=>"Cambridgeshire","Cardiff"=>"Cardiff","Carmarthenshire"=>"Carmarthenshire","Ceredigion"=>"Ceredigion","Cheshire"=>"Cheshire","Clackmannanshire"=>"Clackmannanshire",
"Conwy"=>"Conwy","Cornwall"=>"Cornwall","Cromartyshire"=>"Cromartyshire","Cumberland"=>"Cumberland","Denbighshire"=>"Denbighshire","Derbyshire"=>"Derbyshire","Devon"=>"Devon","Dorset"=>"Dorset",
"Dumfriesshire"=>"Dumfriesshire","Dunbartonshire/Dumbartonshire"=>"Dunbartonshire/Dumbartonshire","Durham"=>"Durham","East Lothian/Haddingtonshire"=>"East Lothian/Haddingtonshire","Essex"=>"Essex","Fife"=>"Fife",
"Flintshire"=>"Flintshire","Gloucestershire"=>"Gloucestershire","Gwynedd"=>"Gwynedd","Hampshire"=>"Hampshire","Herefordshire"=>"Herefordshire","Hertfordshire"=>"Hertfordshire","Huntingdonshire"=>"Huntingdonshire",
"Inverness-shire"=>"Inverness-shire","Isle of Anglesey"=>"Isle of Anglesey","Kent"=>"Kent","Kincardineshire"=>"Kincardineshire","Kinross-shire"=>"Kinross-shire","Kirkcudbrightshire"=>"Kirkcudbrightshire",
"Lanarkshire"=>"Lanarkshire","Lancashire"=>"Lancashire","Leicestershire"=>"Leicestershire","Lincolnshire"=>"Lincolnshire","Merthyr Tydfil"=>"Merthyr Tydfil","Middlesex"=>"Middlesex",
"Midlothian/Edinburghshire"=>"Midlothian/Edinburghshire","Monmouthshire"=>"Monmouthshire","Morayshire"=>"Morayshire","Nairnshire"=>"Nairnshire","Neath Port Talbot"=>"Neath Port Talbot",
"Newport"=>"Newport","Norfolk"=>"Norfolk","Northamptonshire"=>"Northamptonshire","Northumberland"=>"Northumberland","Nottinghamshire"=>"Nottinghamshire","Orkney"=>"Orkney",
"Oxfordshire"=>"Oxfordshire","Peeblesshire"=>"Peeblesshire","Pembrokeshire"=>"Pembrokeshire","Perthshire"=>"Perthshire","Powys"=>"Powys","Renfrewshire"=>"Renfrewshire",
"Rhondda Cynon Taff"=>"Rhondda Cynon Taff","Ross-shire"=>"Ross-shire","Roxburghshire"=>"Roxburghshire","Rutland"=>"Rutland","Selkirkshire"=>"Selkirkshire","Shetland"=>"Shetland","Shropshire"=>"Shropshire",
"Somerset"=>"Somerset","Staffordshire"=>"Staffordshire","Stirlingshire"=>"Stirlingshire","Suffolk"=>"Suffolk","Surrey"=>"Surrey","Sussex"=>"Sussex","Sutherland"=>"Sutherland","Swansea"=>"Swansea","Torfaen"=>"Torfaen",
"Vale of Glamorgan"=>"Vale of Glamorgan","Warwickshire"=>"Warwickshire","West Lothian/Linlithgowshire"=>"West Lothian/Linlithgowshire","Westmorland"=>"Westmorland",
"Wigtownshire"=>"Wigtownshire","Wiltshire"=>"Wiltshire","Worcestershire"=>"Worcestershire","Wrexham"=>"Wrexham","Yorkshire"=>"Yorkshire")
);
return $address_types;
}

Once that code is in place you will then have an additional address type called UK (default options are International, United States and Canadian).

Before

After

To create the plugin I had to find a short code which I could then attempt to replace with a graphic and since Spots from Interconnect IT is one of my favourite plugins right now I thought I would use that. So I have created a plugin that will replace any “icitspot” short codes with a small graphic. This plugin isn’t meant for release, it was made quickly this morning (when I say quickly I mean the whole morning) and  isn’t thoroughly tested. Hopefully it may help someone who is trying to achieve similar things with their own plugin short codes.

Quick rundown on how the plugin works

The plugins main php file uses just two filters (mce_external_plugins, tiny_mce_before_init) to add our TinyMCE plugin and an extra CSS file for styling.

Most of the code that does the bulk of the work is inside tinymce-plugin/icitspots/editor_plugin.js which is in effect a TinyMCE plugin.

I borrowed some code and structure from \wp-includes\js\tinymce\plugins\wpgallery\editor_plugin.dev so if you want to add buttons and click events to this then take a look at that file for guidance.

You can download the plugin files here.

Hopefully this will be of use to someone. I’d like to think the code is pretty straight forward. Send us a comment if you have any questions or observations.

Now and then we do have a eureka or a huh? moment that we want to share.  And we’ve enjoyed a recent plethora of WordPress meet-ups that have inspired both questions and answers that deserve further research and discussion.  Over the last month we’ve managed to attend the inaugural WordPress Birmingham (don’t forget the UK) meetup, South Yorkshire WordPress User Group and Liverpool WordPress Interest Group (SWIG) – almost a clean sweep of the North West WordPress user groups and a diverse mixture of attendees, agendas and accents.  Thanks to the organisers and users of those groups we may finally have the push we need to become more social and do a little sharing…

So welcome to our blog where we may talk about WordPress development, hosting and anything else that gives us pause for thought..