Post Notif v2: Week 1 Plan

Without further ado, here’s the first week’s worth of functionality I am planning to hammer out for Post Notif “v2”:

  • Plugin settings page (or pages?), consisting of some or all of the following:
    • Email settings
    • Page settings
    • Category settings
    • Subscriber form shortcode settings
    • Subscriber form shortcode messages
    • Widget messages
    • Admin Menu Settings
    • Complete review of @@ email template variables
  • Subscriber management, including:
    • Import subscribers
    • Export subscribers (including mapping out conversion path from Post Notif to Post Notif “v2”)
    • (Existing) subscriber management
  • Subscriber “pages”, consisting of:
    • Confirm subscription
    • Manage preferences
    • Unsubscribe

Alright then, let’s go!


Post Notif – Tear It All Down To Build Something Better!

I’ve been talking about building the successor to Post Notif for more than a year now and finally have a plan mapped out to accomplish it. I will not be de-activating Post Notif immediately but will phase it out, over time, encouraging people to move over to the new plugin, as they feel comfortable doing so.

I have learned a lot in the 3+ years since I first released Post Notif v1.0.0. This includes exposure to better development practices, how to effectively interact with a large (at least to me!) user community, identifying which features are most useful to the most people (and, conversely, which are not important and probably not worth the effort to develop, test, and maintain), as well as adjusting to the ever-evolving WordPress landscape itself (GDPR and Gutenberg, anyone?!).

I had a lot of success with my RetroChallenge project, in April, by publishing a “this is what I’m PLANNING to get done this week” post on Sundays and a “this is what I actually GOT DONE this week” post on Fridays, so I am going to emulate that here, with development of “Post Notif v2” (as I’ll call it for now)1. After some fits and starts in the past several months, my plan is to build this, over the course of the month of September, to a releasable state.

An integral part of making sure this project is successful is help from the user community. To that end, I will be soliciting help, assistance, and feedback from both those who’ve kindly already offered it (in the Post Notif support forum on and/or via email) and anyone else willing-and-able to test out “beta” versions of this new plugin, as it takes shape over the coming weeks. I’d love to get feedback, on what works and what doesn’t, from a variety of site owners, particularly since most of the issues that have cropped up, over the years, with Post Notif, have been due to the vastly differing combinations of themes and plugins people use on their sites. It’d sure be nice to iron out as many of these kinds of problems, as possible, during initial development!

Expect to see a post, spelling out the first week’s plan, this weekend.

  1. I’m simultaneously doing the same for RetroChallenge 2018/09, so you’ll see those posts, here on the blog this month, interleaved with the Post Notif v2 posts.

Post Notif v1.3.0 – At Long Last, Shortcodes!

Happy New Year!

For once, I am going to actually keep one of these release posts brief.

Post Notif version 1.3.0 is now available in the usual locations: the plugin directory, on its GitHub page, and here, on this site.

The main driver behind this release was the (long overdue) introduction of a shortcode to render the Post Notif subscriber form. With this version, admins can now tailor the placement of their subscriber forms within posts, pages, widgets, or any combination of the three.

At the risk of repeating myself, here is a comprehensive list of what’s new:

  • Added the [post_notif_subscriber] shortcode, with a bevy of configurable attributes, to tailor each use of (and support multiple uses of) the shortcode in a post or on a page
  • Added two new sections to the plugin settings (Settings >> Post Notif), to define shortcode default attributes and messages
  • Added the ability, for admins who are CSS-savvy, to specify a separate stylesheet to use with either the standard widget or the shortcode-generated subscriber form, allowing them the ability to target individual element ids or entire classes (for wholesale restyling of the subscriber form)
  • Added the @@postcategory variable, for use in the subject and/or body of the post notification email template

This is going to be the last minor release for Post Notif. I will continue to ship point releases, as-needed, to address bugs, add translations, etc. I feel like the shortcode was the last piece of functionality that Post Notif was really missing. So I will be shifting my development focus to other things in 2018. As always, please do let me know, either here, or in the support forum, if you run into any strange behavior with this release.


Post Notif v1.2.0 – An Overhauled Notification System

Good evening!

As the clock ticks incessantly forward, toward the first of December, I am happy to announce that Post Notif version 1.2.0 is now available! You can grab it via the customary avenues: the plugin directory, on its GitHub page, and here, on this site.

This version contains not only additional functionality but some overdue improvements to the underlying architecture, as well.

In an attempt to be completely transparent about what is NOT included in this release, I’ll acknowledge, sadly, that shortcode functionality did not make it in. I had every intention of adding it to the plugin for this version but a couple of factors conspired to prevent me from doing so. First, the reconstruction of how the post notification send process, overall, works, was far more involved, both in design+implementation and testing (this was extremely painful, due to the [inevitable] explosion of test cases that has resulted from adding more unique paths through which authors can trigger notifications) and then the changes to shortcodes and widgets, introduced in the newly released (11/15/2017) WordPress 4.9, added to my discomfort endeavoring to hastily implement this additional functionality.

Consequently, I have pushed the inclusion of a shortcode, for collecting Post Notif subscription requests from site visitors, to the next minor version (i.e., 1.3.0).

In the meantime, I anticipate there is likely to be a version 1.2.1, consisting, at a minimum, of some translation updates, a small enhancement or two, and obviously, if needed, bug fixes. (I’d like to think my code is flawless but I know, with certainty, it is not 🙂 and with the quantity and scale of the changes, which warranted making this release 1.2.0, rather than 1.1.6, I won’t be terribly surprised if there are issues that need immediate attention and repair).

With all of that out of the way, here’s the list of what is new:

  • Added functionality to check the status of, pause, or cancel post notif processes
  • Replaced the old, read-only, View Post Notifs Sent page with a new Manage Post Notifs Sent page. This page, as did the page it replaces, displays an audit trail of the post notifications sent. However, it also contains additional (sortable) columns that display, in more granularity, the status of (future) scheduled and in-process notifications. And, finally, it allows actions to be performed (pause/resume and cancel) on individual notifications, based on their status.
  • Added a clickable link, inside the Post Notif meta box, which routes authors to the Manage Post Notifs Sent page
  • Bolstered the underlying send post notification process code to avoid PHP timeouts (thanks to Ashley Rich for inspiration)
  • Added batch mode options (batch size and batch pause), accessible via Settings >> Post Notif, to account for host throttling (i.e., limiting the number of emails sent by an account, per hour, in the name of spam prevention)

What has been removed:

  • The progress bar (and related send status indicators) has been removed from the Post Notif meta box (where it was visible when triggering post notification via “Send Now”). This was necessary due to the added PHP timeout prevention handling. I realize this may be annoying to some of you but I hope the addition of the (aforementioned) link to the Manage Post Notifs Sent page (and the expanded capabilities available on this page) provide some consolation.

And what’s been fixed:

  • Code has been added so that, when Post Notif is deactivated (via the Plugins page), all WordPress Cron events for future (scheduled and batch-paused) post notifications are deleted. In conjunction with this action, the send_status, of the corresponding post_notif_post rows, is updated to “Cancelled”.

A hearty thanks is owed to Wolfgang for his tireless patience in providing feedback and testing throughout the nearly year-long(!) ideation, implementation, and testing of the guts of this release!

As a reminder, if you are interested in the current status (and pending release target dates) of the next version of Post Notif, please monitor the Projects page – the Post Notif entry is maintained as a link to the current development version page, which contains details about what new functionality, fixes, and improvements are slated for inclusion in the next release, as well as links through which to download beta versions. Alternatively, you can always pull down the latest version (GA or beta) of the plugin from the GitHub page.

Finally, I know it goes without saying, but please do get in touch, either here, or in the support forum, if you run into anything weird or problematic with this release.


Post Notif v1.1.5 – Style Your Widget The Way You Want It!

OK, I’ll keep this brief; after waffling for (literally) months about what to include, what should have top priority, and how to handle translations in various states of maintenance and active support, version 1.1.5 of Post Notif has been released. It is available from the usual sources: the plugin directory, on my GitHub page, and here, on this site.

The primary new features in 1.1.5 consist of an expanded list of configurable settings for the Post Notif widget, namely the ability to:

  • Set First Name as a required field
  • Modify First Name and Email Address input field sizes
  • Override default theme CSS by defining:
    • Call to Action font family, size, and color
    • Placeholder font family, size, and color
    • Input fields (first name and email address) font family, size, and color
    • Error message font family, size, and color
    • Status message font family, size, and color

Additionally, the following has been repaired in this release:

  • Duplicate post notifications are no longer being sent when a post has multiple categories
  • Subscriber import (from file) is no longer erroneously failing on “invalid” categories
  • Email addresses containing “+” now work with personalized URLs

Finally, as a heads up to those who use Post Notif with non-English sites, this release marks the first one where translation files have been removed from the plugin package. Specifically, as they now have language packs (defined and maintained via the Polyglots team), all translation files for Czech and Dutch have been removed.

A special thanks goes out to Dan Heim for his suggestions related to additional widget settings and Frank for his tireless assistance in figuring out how to get language packs integrated into Post Notif and helping me determine the process+timing for hedging against English “leaks” in the translations; those who use Post Notif in Dutch will see that he managed to maintain 100% coverage in his translation as the plugin’s Stable version transitioned from 1.1.4 to 1.1.5.

There are some big improvements coming to Post Notif in the next release (shortcode and post notification send process configurability additions chief among them), so it will be released as version 1.2.0. If you’d like to see the features, fixes, and improvements slated for inclusion, target dates for each of these, or help out with testing the beta releases, please check out the development page:



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 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 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 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!


Post Notif v1.1.4 – Czech It Out!

This release, coming quickly on the heels of the much larger version 1.1.3 release of Post Notif, is chiefly to include the Czech translation kindly provided by Jirka Licek. There is also a rather subtle improvement included, in the form of the email dashicon replacing the generic gear dashicon, for the Post Notif top level menu in the admin dashboard.

What this release also marks, longer term, is a change in the way translations will be managed for Post Notif going forward. Specifically, I am officially turning the future handling of translations over to the Polyglots. I no longer wish to be a bottleneck between the generous translators and those who’ve come to rely on Post Notif appearing completely translated (with no English “leaks”) into their preferred language, release after release. Instead, I will return all of my focus to promptly addressing issues raised by users and deliberately adding functionality that incrementally improves Post Notif.

I will post again once I have confirmation from the Polyglots that language packs have been created for each language Post Notif has a translation for, at which time I will remove the .po and .mo files from the ../post-notif/languages directory in the plugin package. If you would like to provide a translation for a language that has not yet been addressed or you’d like to help maintain an existing translation, please let me know and/or contact the Polyglots directly.

In the meantime, I continue to appreciate any and all feedback you have, so please let me know what you think.

And thanks again, Jirka!


Post Notif v1.1.3 – Scheduling Posts Just Got A Whole Lot Better!

I am pleased to announce the release of Post Notif version 1.1.3! It has taken far longer than I’d anticipated, but I am firmly of the opinion that its improvements are worth the wait. I hope you’ll agree, once you’ve had a chance to install it and experiment with the new features.

Speaking of which, here’s what’s new:

  • Added ability to auto-send post notifications when post is published
  • Bolstered ability to manually run and schedule post notifications

A frequent request I’ve heard from people, starting almost immediately after the release of Post Notif 1.1.0, was that though they appreciated the ability to schedule post notifications (rather than ONLY being able to manually trigger them), they didn’t necessarily want to wait to schedule the send process until after a post had been published. Further, it became clear that a commonly desired use case consisted of drafting a post, scheduling it to be published at a specific future date and time, and then having the post notification go out immediately following the publish event. So I added this.

To employ it, a new option has been added to the plugin’s settings page (Settings >> Post Notif). In the Email Settings section, the “Send post notifications when post published” option will appear defaulted to “No (Manual)”. If you’d like your post notifications to be sent automatically, upon post publish, you can change this to “Yes (Auto)”. You’ll see this appear in the (core WordPress) Publish meta box, prefixed by an email envelope icon. This value will be initially set based on how you’ve set the default on the Post Notif settings page but can be overridden per post. Even when “Auto” is chosen, you will see it revert to “Manual” automatically, once a post is published and the post notification is sent out. This was a deliberate implementation decision to address a couple of noted concerns from testers. Specifically, it is common for authors to perform minor punctuation corrections or formatting updates to a previously-published post, without wanting to automatically send out a fresh batch of post notifications. Additionally, any post published before introduction of this new functionality will individually default to “Manual”, regardless of the admin’s choice in the Post Notif settings, to avoid inadvertently flooding subscribers’ inboxes if minor updates are ever made to old posts. Of course, if an author makes a content correction or update and DOES want to call attention to the revised post, they can easily either change the auto-send option back to “Auto” or trigger a manual send.

Please note that though, to this point, I’ve focused on posts scheduled to be published at some time in the future, setting a post to auto-send post notifications will do just that for manually published posts as well. So if your process is to finish your draft and hit publish (immediately), with Post Notif set to “Auto” your post notifications will go out as soon as you hit “Publish”.

Because some people wish to be able to schedule post notifications for posts scheduled to be published in the future but do NOT want post notifications sent immediately after publish, I did some considerable rework on the Post Notif meta box. You will not see anything but the “Test Send”-related fields in the Post Notif meta box unless you’ve set the Post Notif auto-send option to “Manual” for the current post. However, once you do set it to “Manual”, you will have the option to schedule a future post notification send for any post that is either already published (the current functionality, as introduced in v1.1.0) OR for any post that is scheduled to be published. If the post is already published, you will also have the ability to send it immediately. Please be aware that if a post is not in published status when the scheduled post notification time and date come around, no post notifications will be sent out for the post, and you’ll need to reschedule the send or perform it manually.

You’ll also notice some slight aesthetic changes to the contents of the Post Notif meta box. To provide consistency with the new auto-send feature (in the Publish meta box) and make the UI more intuitive, I replaced the “Send Now” and “Schedule” radio buttons with clickable links to toggle between the two post notification send options (when both are available; if the current post is not-yet-published, but scheduled to be, only “Schedule” is available so it is selected for you and not changeable).

There were also a couple of fixes introduced in this release, pertaining to subscriber creation:

  • Fixed subscriber import process bug, to allow imported subscribers to be subscribed to ANY category available to subscribers (as defined in Post Notif settings)
  • Added missing check validating successful subscriber creation (when processed via Post Notif widget)

My sincere thanks go out to Dan Heim, Ben Bois, and Wolfgang for first identifying bugs and features lacking completeness, and then following up by testing and providing feedback on the changes I made to address the issues they raised; the new release is in much better shape as a result of their help!

Finally, I’ll mention that there were several things I’d originally intended to include in this release that just simply didn’t make it in (I won’t bore you with the details explaining precisely why 🙂 ). Consequently, I will be embarking on the next version of Post Notif almost immediately, so look for another new version out before long.


Post Notif v1.1.2 (Dutch edition)

..And the releases keep rolling out!

This time it is not (entirely) to fix a bug, though Post Notif version 1.1.2 does contain a very slight update to a custom table CREATE statement (to adhere to a WordPress 4.6 dbDelta() KEY format change and thus avoid errors generated on plugin install or update).

The real focus is the addition of a Dutch translation to complement the existing German and Spanish. A hearty thank you to frankmaNL for supplying it mere days after the big Post Notif 1.1.0 release!

That’s it for the contents of this release; I hope this new translation is a welcome one for those of you who run your site(s) with Dutch as your base language.

Here’s hoping November has started out well for you and that we get a break from updates for a bit1!

As always, please do let me know if you have any feedback.

  1. Obviously, if you’d like to create a translation for a language Post Notif has not yet been translated to, by all means send it my way and I WILL roll out another point release!

Post Notif v1.1.1 – Sanding Down The Rough Edges!

Though I’m not exactly pleased about the need to release this next version so very quickly after the previous one, I can’t say it is totally surprising that there was a bug discovered in version 1.1.0. Fortunately, thanks to Dan’s quick reporting, I was able to eradicate it without much trouble. The root cause was that, per the PHP docs, prior to PHP 5.5, empty() only supports variables; anything else results in a parse error. The example given in the docs, that “empty(trim($name))” will not work, pre PHP 5.5, is precisely what I’d added as a part of the new code in Post Notif v1.1.0. Switching to “false == trim($name)” (always be thinking Yoda conditions! 🙂 ) fixed the problem.

On a more positive note, Ruediger Walter executed a fantastic turnaround on translating the new Post Notif v1.1.0 strings into German (both formal and informal), so those are included in version 1.1.1 as well!

I sincerely hope this is the last of the (negative) fallout from the significant code changes made in version 1.1.0. Thanks for bearing with me!