This article is about my legacy publishing process for development WordPress plugins and themes. It is my workflow and it is far from perfect. It will evolve over time and I am in the midst of making several big changes using new tools to assist in the process. To get some background on the process you may want to follow along with the WordPress Workflow and WordPress Development Kit threads on my blog.
My WordPress development is fully contained in a VirtualBox running CentOS 6.5 with a full GUI interface. I am working on building an distributing some Vagrant boxes that will help others replicate the process. My base CentOS 6.5 GUI box is online but is not a full setup… yet. You can read about Vagrant in the WordPress Workflow thread.
My plugin development environment consists of a standard WordPress production build (3.8.1 today) with the typical wp-content/plugins subdirectory. On my development system I work directly inside of these directories. It provides instant access to the modified code without running a repetitive series of push/pull commands to move stuff into a “ready to review” state. I find this configuration to be far more efficient and rely on semi-intelligent scripts to help me “weed out” the development environment when building the production-ready kits. As a last step before production I have a test box on a remote server where I install the production releases as a clean last-minute sanity check. This will migrate to a Vagrant-based “clean production simulator” to provide more robust testing.
How does my “inline production” setup look?
The Build Scripts
The top-level build scripts go in my ./wp-content/plugins directory. That is not exactly accurate. I should say that symbolically linked file pointers (symlinks for Linux geeks… or shortcuts in Windows lingo) go in that directory. This includes the makezip, update_wrepo, exclude and common files that are part of the legacy/publisher section of the new WP Dev Kit I’ve published on Bitbucket.
Within each plugin subdirectory I create an assets subdirectory. This is where my “build and production helpers” go. My scripts specifically avoid this directory when packaging the “for consumption” products. Within this directory I currently store things like raw image assets that typically get pushed the WordPress Plugin Directory, a full copy of the WordPress svn repository for any plugins published there, and other “goodies” I need for production that I do not distribute. This is where my new Grunt and other build helpers will go.
Published Files Store
There is a separate directory under my home directory, ~/myplugins, where the published files go. This helps keep my production files separate from the main plugins. This will eventually change as I improve and streamline the process.
NetBeans “Push” Project
I also have a special directory under my home directory where I keep non-WordPress NetBeans projects. One of those projects is a private project named “csa_licman”. One of the many things this project does, which will also be changing, is sync any changes I make in the subdirectories of the csa_licman project up to my live server. I use this to “publish” my premium add-ons to my live server. I will not cover that part of the project here or the NetBeans automated FTP push setup.
You can find details on getting NetBeans projects to watch a directory and FTP files elsewhere on the NetBeans site. I will be changing this complex part of the system to automated Grunt processing in a later revision to the WP Dev Kit. For now you can keep the myplugins directory and manually FTP files from there to any private directories.
Keep in mind that anything going to the public WordPress Plugin Directory will be handled via the legacy update_wprepo.sh script. The NetBeans push project is only for my premium add-on packs that are not hosted in the WP Plugin Directory.
My tool kit currently consists of:
git – for managing my code repository. I find it faster and lighter than svn.
svn – solely for publishing to the WP Plugin Directory.
smartgit – my GUI to help me cheat with git commands, I am MUCH faster with the GUI.
NetBeans – my IDE setup specifically for PHP development with heavy use of phpDoc hints in my code.
command line with Bash – the Linux command line for executing my Bash scripts, most of this should work on OSX as well.
Using The Legacy Publisher
Here is how I setup and use the legacy publisher scripts in my setup. I call them “legacy publisher” scripts as I am learning Grunt and working toward a more intelligent processor. The legacy publisher is based on simple Bash scripts which can be complex to configure and extend. Grunt provides a managed system that will fetch various plugins to do a lot of cool stuff that would take me far to long to replicate in Bash. Why re-invent the wheel?
After I get my new dev box setup and I have WordPress up-and-running and my development plugins in place under the wp-content plugins directory I attach my legacy publisher kit. I am not going to cover the NetBeans push setup under csa_licman though you will see it referenced in the shell scripts. Always answer “n” to “publish to live server” when running any of the legacy scripts and you will not have issues as that part of the script will not be executed.
Under my login I use git to fetch the WP Dev Kit from Bitbucket, setup my published files directories, I then link the legacy publisher kits into my WordPress plugin directory:
cd ~ mkdir myplugins git clone email@example.com:lance_cleveland/wp-dev-kit.git ./wp-dev-kit cd /var/www/wpslp/wp-content/plugins ln -s ~/wp-dev-kit/legacy/publisher/*
I am now ready to use the legacy kit to build my production zip files and publish them by hand to my server or use update_wprepo.sh to push them to my WordPress Plugin Directory listing.
Simple Self-Hosted Plugins
My premium add-on plugins are the simplest setup for this environment. Once I have my legacy publisher scripts in place I can create my base plugin files right in the plugin directory. I edit my readme and php files, test locally, and when ready I publish them in one step with the makezip command. Since I have a NetBeans automated push project I can answer “y” to the publish to live server question and get the files over to my server. If you do not have this setup you can answer no and manually FTP the files in ~/myplugins to your final destination.
cd /var/www/wpslp/wp-content/plugins ./makezip slp-enhanced-results
WordPress Hosted Plugins
WordPress hosted plugins, such as the Store Locator Plus plugin, require a bit of extra work to get them ready for production. After the initial setup is in place I can update the production release using the update_wprepo.sh script. In this setup I use the assets subdirectory to assist in the production. It is where the svn repository lives that gets updates to the WordPress servers.
I start with my plugin directory in place and build the setup necessary for the legacy script to publish to WordPress:
cd /var/www/wpslp/wp-content/plugins cd store-locator-le mkdir assets echo '<?php // Silence is golden.' > index.php svn co 'http://plugins.svn.wordpress.org/store-locator-le/' svnrepo mkdir public
My plugin is now ready for publication. I go to the wp-content/plugins directory and run update_wprepo.sh and answer the prompts whenever I am ready to push to the WordPress plugin directory. The process also build a local zip file in the ~/myplugins directory so I can keep a copy on my servers. The update_wprepo.sh script will update trunk, create the version branch and even try to clean up any tags or branches if a push of the same version has failed previously.
WP Directory Marketing Assets
Getting asset files into the WordPress repository is also part of the script. This is the preferred method for storing your plugin banner and screen shots as it lists them on the WordPress site without filling up the .zip distribution that goes to the client. With the legacy publisher it is easy, though a bit of a manual process. I store my banner and screenshot files in the ./assets subdirectory (note to self: should create a wp_marketing_images subdir). Since the assets directory is never part of the published file set they are ignored. To add assets to the WP Plugin Directory publication I create an assets directory under the svnrepo, copy over the image files I want, and run svn up from the svnrepo directory.
The following scripts are included in the legacy/publisher directory in my WordPress Dev Kit:
Setup common Bash variables that the other scripts use to run.
The list of directories and files to be excluded when zipping up the plugin directory.
The script that packages up the plugin directory. Currently with some extra “cruft” to rename some of my plugin directories to a different zip file name when doing the “publish to live server” logic.
Runs makezip, unpacks the zip file into the assets/public directory to ensure a clean copy of the plugin, copies to svn repository trunk and branches to push to the WP Plugin Directory.