Recently, I wrote a post describing the review process for publishing a plugin in the WordPress Plugin Directory:
I've created Perfecty Push Notifications, a WordPress plugin for sending Push notifications using Push API from your server for free. You can check the Github repo and contribute ⚡️. In this post, I will describe what happened next in the review, and how the publishing of the plugin looked like.
Getting the approval
Well, after addressing the initial suggestions from the WordPress plugin review team, I received another email suggesting the upgrade of the plugin dependencies:
At that time the
composer.json
dependencies looked like this:
"require": {
"minishlink/web-push": "5.2.5",
"ramsey/uuid": "^3.9"
},
"require-dev": {
"mockery/mockery": "1.3",
"phpunit/phpunit": "5.7.27",
"wp-coding-standards/wpcs": "^2.3",
"dealerdirect/phpcodesniffer-composer-installer": "^0.7.0",
"phpcompatibility/phpcompatibility-wp": "*"
}
The problem with the upgrade was the initial plan to support
PHP 7.1
, which according to the WordPress statistics had a 5.9% representation of the total WordPress websites. Some of the dependencies in the latest versions required
PHP>=7.2
, specially the Push Server library. So, that cut 5.9% potential users:
However, I was able to compensate that 5.9% loss by supporting WordPress starting from
5.2
, which initially I was not considering. That was a 6.4% gain:
With that in mind, I submitted the second Release Candidate
1.0.0-rc1
with the suggested changes. You can take a look at all the changes I made here: https://github.com/rwngallego/perfecty-push-wp/commit/2f2322f7848b6cb37465e5776d1f60c981b987d9
In this RC, apart from the minor fixes required after the upgrade, I easily updated the CI pipeline to support the aforementioned PHP/WordPress versions:
strategy:
matrix:
wordpress-version: ['5.2', '5.3', '5.4', '5.5', 'latest']
php-versions: ['7.2', '7.3', '7.4']
Everything set, all the automated tests green ✅ (the matrix strategy rocks!):
And finally, their approval 🥳:
Publishing
OK, I got access to the Wordpress Plugin directory SVN servers:
Something important here: Once you get the plugin approved, you will need to read carefully all the guidelines related to the publishing, the directory assets (screenshots, logo, banner), the
README.txt
file and how the whole process works. For more information you can read:
- https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/
- https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/
- https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/
- https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/
I decided not to publish the plugin right ahead, specially because I noticed some potential improvements (and bugs of course), so I took some days and also prepared the design material. You can see the whole set of changes I made before sending the final version here:
https://github.com/rwngallego/perfecty-push-wp/compare/v1.0.0-rc1...v1.0.1
In this case, I refactored some of the code, improved the usability, added more test scenarios and added the branding stuff. Now the release:
So, right now we have the
.zip file
and the release published on Github. To publish the plugin in the Wordpress Plugin Directory, you basically need to sync your development work with trunk, change the plugin version, create the tag and then check in the changes:
# change the version in README.txt:
Stable tag: 1.0.0
# change the version in your plugin entry file (`
perfecty-push.php
`):
* Version: 1.0.0
define( 'PERFECTY_PUSH_VERSION', '1.0.0' );
# checkout the upstream
mkdir dist/svn/
svn co https://plugins.svn.wordpress.org/your-plugin-name dist/svn/
# add the changes to trunk
cp -Rp admin includes languages lib public vendor composer.json composer.lock index.php LICENSE.txt perfecty-push.php README.txt uninstall.php dist/svn/trunk
# add the new files if any and check the diff:
cd dist/svn/
svn add --force .
svn stat
svn diff
# if you're happy with the changes, create the tag from trunk:
svn cp trunk tags/1.0.0
# check in your changes:
svn ci -m "Version $SVN_TAG"
Alternatively, I created two additional shell commands to sync and publish the svn package with
make svnsync
and
SVN_TAG=1.0.0 make svnpush
, which later I used to setup my deployment pipeline:
create_dist() {
rm -rf $DIST_PATH
mkdir -p $SVN_PATH $OUTPUT_PATH
rm -rf vendor && composer install --quiet --no-dev --optimize-autoloader
cp index.php vendor/
cp -Rp admin includes languages lib public vendor composer.json composer.lock index.php LICENSE.txt perfecty-push.php README.txt uninstall.php $OUTPUT_PATH
}
svnsync() {
create_dist
svn co -q https://plugins.svn.wordpress.org/perfecty-push-notifications $SVN_PATH
cp assets/* "$SVN_PATH/assets/"
# we don't sync vendor if the lock file is the same
if [[ $(shasum composer.lock | head -c 40) == $(shasum "$OUTPUT_PATH/composer.lock" | head -c 40) ]]; then
rsync -q -av $OUTPUT_PATH/* $SVN_PATH/trunk --exclude vendor
echo "## no differences in /vendor, similar lock files ## "
else
rsync -q -av $OUTPUT_PATH/* $SVN_PATH/trunk
fi
(cd $SVN_PATH && svn add --force . && svn diff && svn stat)
}
svnpush() {
if (cd $SVN_PATH && svn status | grep -e ^?); then
echo "There are changes not added to the SVN"
exit 1
fi
if [ -z "$SVN_TAG" ]; then
echo "You need to provide the tag version as SVN_TAG=1.0.1"
exit 1
fi
if [ -z "$SVN_USERNAME" ]; then
echo "You need to provide the username as SVN_USERNAME=myname"
exit 1
fi
if [ -z "$SVN_PASSWORD" ]; then
echo "You need to provide the username as SVN_PASSWORD=mypassword"
exit 1
fi
if [ ! -d "$SVN_PATH/tags" ]; then
echo "You need to run svnsync first"
exit 1
fi
if [ -d "$SVN_PATH/tags/$SVN_TAG" ]; then
echo "The tag $SVN_TAG already exists"
exit 1
fi
cd $SVN_PATH && svn cp trunk tags/$SVN_TAG && svn ci -m "Version $SVN_TAG" --username $SVN_USERNAME --password $SVN_PASSWORD
End result, Perfecty Push Notifications published in the WordPress Plugin directory 👏:
https://wordpress.org/plugins/perfecty-push-notifications/
And a deployment pipeline that deploys to Github and Wordpress by just tagging the new version! 🚀
Using the plugin as an end-user
I installed the plugin in one website I have access to, and sent some notifications. In general, it takes about
2 or 3 minutes
to send about
2.000
notifications in a basic sever compared to a
t2.small
. As the plugin uses
wp-cron
to execute the jobs asynchronously, that timing includes the time gaps between job executions, so it would be less than that.
If you're interested, I will publish another post describing the performance metrics of the plugin, for the moment you can see the impact on the server for one of those jobs:
So, descent results for a very first version! ✨
Take the ride
Wrapping up, if you're still considering writing a plugin, I highly recommend you to take the ride. I created Perfecty Push Notifications as an Open Source alternative for sending Push Notifications from your own Wordpress server for free. I don't know if it will succeed in the Plugin directory or not, however all the things I've learned in the process were valuable, and specially important is the fact that I can share both, the knowledge and the joy of the trip with you 🖖.
Feel free to use it in your websites or recommend it to your WordPress-fans folks. Have a nice one!
Photos
Photo by Bill Jelen on Unsplash