How to use Rake::PackageTask to create a zip file

I found out that the easiest way to build a WordPress plugin is using a rake task. In fact, you can use Rake::PackageTask to create a zip file. However, there is very little documentation about how to do it in practice. Here is my solution.

  1. (destroy and) create a folder to hold just the needed files
  2. copy the (possibly transformed) needed files to that folder
  3. compress the folder

Here is my Rakefile:

require 'rake/packagetask'

namespace :nzymes do
    desc 'Build plugin'
    task build: %w(destroy create package)

    desc 'Destroy dist folder and its contents'
    task :destroy do
      rm_rf 'dist'

    desc 'Create dist folder and its contents'
    task :create do
      mkdir_p 'dist/nzymes/vendor'
      cp_r 'vendor/Ando', 'dist/nzymes/vendor'
      cp_r 'src', 'dist/nzymes'
      cp_r Dir.glob('*.php'), 'dist/nzymes'
      cp_r Dir.glob('*.md'), 'dist/nzymes'
      cp_r 'readme.txt', 'dist/nzymes'
    end'nzymes', :noversion) do |p|
      p.need_zip = true
      p.package_dir = 'dist'

Here are the tasks it creates:

andrea at Lock-and-Stock in ~/dev/wordpress/plugins/nzymes on master [!?$]
$ rake --tasks
rake nzymes:build            # Build plugin
rake nzymes:clobber_package  # Remove package products
rake nzymes:create           # Create dist folder and its contents
rake nzymes:destroy          # Destroy dist folder and its contents
rake nzymes:package          # Build all the packages
rake nzymes:repackage        # Force a rebuild of the package files

Here is how you can use it:

andrea at Lock-and-Stock in ~/dev/wordpress/plugins/nzymes on master [!?$]
$ rake nzymes:build
rm -rf dist
mkdir -p dist/nzymes/vendor
cp -r vendor/Ando dist/nzymes/vendor
cp -r src dist/nzymes
cp -r nzymes.php dist/nzymes
cp -r dist/nzymes
cp -r readme.txt dist/nzymes
cd dist
zip -r nzymes
  adding: nzymes/ (stored 0%)
  adding: nzymes/ (deflated 70%)
  adding: nzymes/nzymes.php (deflated 46%)
  adding: nzymes/ (deflated 48%)
  adding: nzymes/readme.txt (deflated 53%)
  adding: nzymes/src/ (stored 0%)
  adding: nzymes/src/Nzymes/ (stored 0%)
  adding: nzymes/src/Nzymes/Capabilities.php (deflated 84%)
  adding: nzymes/src/Nzymes/Engine.php (deflated 80%)
  adding: nzymes/src/Nzymes/Options.php (deflated 73%)
  adding: nzymes/src/Nzymes/Plugin.php (deflated 74%)
  adding: nzymes/src/Nzymes/Stack.php (deflated 70%)
  adding: nzymes/src/Nzymes/Unused.php (deflated 69%)
  adding: nzymes/vendor/ (stored 0%)
  adding: nzymes/vendor/Ando/ (stored 0%)
  adding: nzymes/vendor/Ando/ErrorFactory.php (deflated 79%)
  adding: nzymes/vendor/Ando/Exception.php (deflated 29%)
  adding: nzymes/vendor/Ando/Regex.php (deflated 78%)
  adding: nzymes/vendor/Ando/StarFunc.php (deflated 73%)
cd -

Here is what you get:

andrea at Lock-and-Stock in ~/dev/wordpress/plugins/nzymes on master [$]
$ ls -la dist
total 104
drwxr-xr-x   4 andrea  staff    136 May 25 13:03 .
drwxr-xr-x@ 20 andrea  staff    680 May 25 13:03 ..
drwxr-xr-x   8 andrea  staff    272 May 25 13:03 nzymes
-rw-r--r--   1 andrea  staff  50814 May 25 13:03

Backup of a WordPress plugin / theme directory.

I often think: I’m just gonna do this little thing before and then I continue doing that.

The last little thing spanned a couple of days. I needed to make a patch for WordPress and cross fingers after pleading to apply it.

I could be wrong, but some years ago it was considered best practice to have users of your plugin to store their customizations into the same plugin directory. Well, maybe nobody advised me to but nobody advised me against either. The point is that it looks really neat to make users store all the stuff related to your plugin in the same place where your plugin leaves.

Years ago, however, there was no problem. Whenever you wanted to install a new plugin or update an old one, you always needed to first download it to your PC and then to upload it to your remote site, into the ´/wp-content/´ directory, possibly by means of an FTP client. The process was repetitive and cumbersome, but exactly by virtue of that you did things orderly.

Always make a backup of the stuff you are going to replace.

That was the mantra. Even on toilet walls you could read it.

Then, the update now link appeared and it all changed, for better. No more nothing, just a simple click and … magically everything happened remotely. Really really good feature. But there was a problem. A no-feature became a feature (bug?). The magic update now functionality never makes a backup of what is gonna replace. Why? I really don’t know. It is still a mantra for me!

So, the last couple of days, I made a patch for WordPress 4.1 and submitted it minutes ago. It’s quite simple: Always make a backup of the stuff you are going to replace. Then a plugin / theme developer can access a backup of their previous stuff and transparently migrate the previous custom files to the new version. For example, from an activation hooked function:

{[ .example | 1.hilite(=php=) ]}