What I learned by releasing a WordPress plugin

This summer, I launched Webinista WreadIt™, a WordPress plugin that turns blog posts into audio files with Amazon Polly. I decided to build this plugin after a few conversations with friends and clients about turning their posts into audio.

You can read about the plugin in the blog post, Webinista WreadIt™: A text-to-speech plugin for WordPress. This post is more about what I learned by building it.

WordPress block development

I've been dodging WordPress block development for years. All of my current WordPress projects are legacy projects. They use old themes and the Classic Editor plugin. Building WreadIt™ forced me to learn how to add plugin blocks and use WordPress' component library.

PHP type declarations

WordPress, as you probably know, is a PHP and MySQL application. I've worked with PHP in some capacity since PHP 4, but versions 7.4 and later versions support type declarations. Developing WreadIt gave me a chance to use them.

Type declarations allow you to specify the type of data or return value to expect from a variable, function, or class. Consider the script below.

<?php

declare(strict_types=1);

function add(int $a, int $b): int {
    return $a + $b;
}

print add( 1, 4 ) ;

print add( 1.1, 4 );

The first print statement, print add( 1, 4 ) prints 5. However, the second print statement, print add( 1.1, 4 );, triggers the message below because 1.1 is a float value.

Fatal error: Uncaught TypeError: add(): Argument #1 ($a) must be of type int, float given, called in /Users/me/add.php on line 9 and defined in /Users/me/add.php:5

Throughout WreadIt, I used type declarations to indicate what kind of value — such as a WP_Error object, WP_REST_Response, or no value at all (void) — to expect from a function.

Git tagging, archiving, and GitHub releases

I'd heard of Git tags, but didn't quite understand their usage before releasing WreadIt™. Similarly, I wasn't sure how to create a release for download from GitHub.

WreadIt development taught me that it's pretty easy to do both. Tagging makes it easy-peasy to create an archive and a release. I also learned how to use a .gitattributes file to exclude particular files from the plugin's release archive.

First I created an annotated tag using the -a flag.

git tag -a v1.0.0 -m "Annotated tag message."

The v1.0.0 string immediately after the -a flag is the tag name. You can also pass a message with the -m flag, as you might do with a commit. If you don't, Git launches the default message editor.

After creating the tag, I pushed it to the remote repository with git push origin v1.0.0.

Next, I used git archive to create a zip download for release. Archives can be zip or tar. I created a zip archive. Adding a prefix prepends all files in the archive with the prefix string. Passing a directory name ensures that the expanded archive directory will be webinista-wreadit regardless of the .zip file name.

git archive --format=zip --prefix=webinista-wreadit/ --output webinista-wreadit.v1.0.0.zip v1.0.0

The final argument v1.0.0 tells Git to create the archive based on the v1.0.0 tag. You could also use a branch name, HEAD, or commit identifier.

The last step is to use GitHub's Release creation process to create a release. GitHub creates tar and zip archives containing the project's source code. I attached the plugin-ready archive to the release.

Why a separate archive?

Plugin users do not need to install PHP_CodeSniffer or the raw JavaScript components in order to use the plugin. The zip archive includes everything needed to run the plugin without the additional developer tools.

My ultimate goal is to turn Webinista WreadIt™ into a business. In the meantime, it's given me a reason to pick up some new skills.