On The State of Post Notif v1.1.5 Development

I know Post Notif version 1.1.5 is long overdue. And it is eating at me. So, this is what’s between me and getting it out to you; if you make it through this 🙂 and have any general feedback or, better yet, suggestions, I’d love to hear them!

OK, here goes:

  • TL;DR: Testers need to be able to acquire incremental release files and spam filters are making it increasingly difficult to send these files via email, plus, managing (potentially duplicative) testing relationships is suboptimal to testing more “out in the open.”

    I am a firm believer in the need to test code changes as exhaustively as reasonably possible. To that end, I much prefer to have people other than myself (who wrote the code and therefore is an unreliable tester at best!) perform testing on the individual fixes + new functionality that comprise a new release before I consider them for inclusion in the full new release that becomes the default download in the WordPress.org plugin repository. So far, my approach to the testing phase has been working one-on-one, via email, with testers (exchanging .zip files and their resultant feedback). But lately I have been having a ton of problems with emailing .zip files to people (ironic, I know, for a guy who writes a plugin for sending email notifications but life is funny like that!); email hosts have been flagging more and more of my emails as spam, even BEFORE I attempt to send a .zip attachment! So, I am leaning toward shifting to simply releasing incremental “beta” versions of the plugin to download here, on this site, and then announcing these beta versions in the support forum, encouraging anyone interested in testing to do so. I am not totally clear on how I’d manage the iterative testing and feedback loop, so I’m wondering if anyone knows of an existing plugin I could install on this site to manage that?

  • TL;DR: I don’t want to delay releases for the vast majority of users, who I suspect are English readers, BUT I don’t want admins and users of non-English sites to have a subpar experience either. Reconciling these has proven challenging thus far.

    New releases, particularly if they contain new functionality, tend to introduce new and/or modified translatable strings. The switch over to language packs for translations (which eliminates the need for inclusion of translations in the plugin package itself) is progressing (both Czech and Dutch are all set!), so that’s positive. However, I’m concerned about how to prevent English “leaks” from happening. What I mean is that I anticipate a delay between the time I introduce new strings in a release and when translators will catch up and update the language packs to account for the changed set of strings. During this time, untranslated English strings will leak into the plugin’s presentation + displays for admins and users of Czech and Dutch-based sites (since as of this writing these two have language packs). Up until now, I’ve prevented this by adding (admittedly shoddy) Google Translate “translations” in the plugin package itself, to prevent leaks until my translators could get back to me with their updates, at which time I’d roll out a small release to include their updated translations. But this won’t work with the translations moved to language packs outside of the plugin package that I control. Now, the most obvious solution would be to check in a final development version of the plugin’s new release, a certain number of days before releasing the new, “stable” version (meaning the default version that one downloads from the WordPress.org directory), containing the full set of current translatable strings, to give the translators some lead-time to synch up their language packs. But, per the plugin review team’s guidelines, plugin developers are not supposed to be using the WordPress.org repo for anything but production releases. So I remain unclear as to how to best support the translators in their mission to maintain complete language packs over time. (I’ve reached out to someone with a lot of Polyglots team experience about this so I’m hopeful I can resolve this soon.)

  • Finally, I have been thinking quite a bit about a next generation of Post Notif, building upon many of the lessons I’ve learned, from the plugin’s lifespan thus far, about what works well and what hasn’t. A current WordPress core version would be required, so it could employ some of the more recent functionality, such as the REST API. Of course I would maintain support of the existing Post Notif plugin, for a clearly-defined period of time, to allow those interested in continuing to use it to do so until they are able to get their WordPress core updated to the minimum version required for the new plugin.

So there you have it. I have every intention of proceeding with support and enhancement of the existing Post Notif plugin. I use it myself, after all, and will do so until I build something better. 🙂 But, clearly, I need to overcome some obstacles that, individually, may not look like much, but combined, have slowed my progress to a crawl. Please do let me know if you have suggestions about any or all of these items. Thanks!

10

Leave a Reply

Your email address will not be published. Required fields are marked *