Now that the BNFW site is live and I’m actively working on it, I thought it would be nice to add a blog. Here, I can offer insight into the plugin, issue transparency reports (first one due out soon), and make any major announcements. I thought the first post should be about BNFW and its origins so that you all have a clear understanding of how the plugin started and what my intentions are for it in the future. Some have noticed in the WP forums that I’m happy to add some things to the roadmap but are hesitant to do so for others – in this post, I hope to clarify why this is but first, a bit of background…
A Project Management System
Better Notifications for WordPress started life as a need to scratch an itch, as most plugins tend to do. A client, whom I was building a project management system using WordPress for, required that email notifications were sent to some of the site’s users when new projects (categories), posts, and comments were made. Comment notifications already existed but new posts and new categories weren’t readily available in core. After a bit of research, realising that no other plugin seemed to exist to meet my requirements, I started mapping out an idea for a small plugin that would handle this but would also allow me to customise the notifications for comments too. This idea became BNFW and the aim was, and still is: to be able to receive notifications about things happening in the WordPress core, choose who to send them to, and choose what is sent in them.
Partnering with a Developer Friend
Whilst I had a good knowledge of WordPress, its functions and possibilities, at the time (back in October 2012), I didn’t have the appropriate skills to code a plugin myself. I spoke to Peter, a developer friend of mine, about partnering up in order to work on the plugin together and release something that was useable, first testing it on my client’s project management system to see if it worked in a real world example. One rainy weekend in February 2013, I drove up to his office in Worcester, England and we set to work on creating a first beta of the plugin. We also wrote up and signed a short contract which outlined the intended purpose and idea of the plugin, our roles in its development, and business progression. In short, Peter would do most of the coding (I could always do a bit), but all the ideas, roadmaps, support, research, and planning was down to me.
What We Learnt
Over the weekend, we learned a great deal about the process that WordPress goes through when it creates a post. At first we thought it would just do one thing when it publishes a post but actually, it goes through many different functions before a post is published – the very first test run sent about 10 emails at once! Once we began to understand how WordPress’ post status transitions worked, we quickly were able to get things working as we expected.
Shortfalls in WordPress
One of the key requirements was to be able to include information from categories, posts, and comments in the notifications and choose who to send them to. A simple matrix-style settings screen allowed us to choose which notifications were sent to which users. It wasn’t very scalable, which is why it isn’t present in the current version but it did allow us to get started. We could then customise the notifications by including shortcodes that we created, specifically for use in the plugin that would pull information from the notification object that we were dealing with and include it in the notification. Using [post_content] for example would include the post content in a notification for a new post.
We soon realised that WordPress, as good as it is, had some interesting shortfalls, namely in the amount of information it stores for certain things in the database. For example, we couldn’t include the details of the user who creates a new project (category) because WordPress simply doesn’t store it. To be able to add this information, we’d have to create a new database table or create new columns in the wp_terms table, which is less than ideal and not upgrade friendly. At this point, we decided to try and show all the information WordPress stored, which is why some obscure shortcodes exist in the documentation whilst others have been removed since the beta.
Release & Progress
Shortly after returning home from the weekend of development, and after appropriate testing, I released the plugin on WordPress.org. After a bit of thought, I came up with the name of Better Notifications for WordPress, which I felt reflected the nature and potential of the plugin.
After a year, the plugin had received over 1000 downloads and I was pleased with the initial reaction so wanted to push development. Unfortunately, although in our agreement, getting Peter to work on the plugin as actively as I was, was proving difficult. Only one small bug-fix was released during the first year and I started to notice other plugins coming out that had similar functionality. I did have a good go at development myself at this point however, my skills still weren’t up to the task and I didn’t feel that it would be an adequate use of my time – something it was using up a lot of just to get the basics right. Convinced that the plugin could be great, and seeing that the scope and need was there in the WordPress eco-system, I wanted to push on with work on the next release – a full 1.0 version that would take the plugin out of beta. Another year passed and I decided to start looking for another developer.
Hiring a New Developer
Although our agreement didn’t say I needed to, being the person that I am, I wanted to speak to Peter openly about the issues I felt the project had with regards to the lack of development and time that he couldn’t / wouldn’t / didn’t want to allocate to the development of the project. We did disagree for a bit but after some level-headed discussions, we came out with an amicable agreement where he would stop working on the plugin and would also receive 4% of any profits from the plugin. I consider Peter a good friend and I took our disagreement as a bit of a personal blow at the time, however, it’s something I’m really pleased I did in the end as it allowed me to find another developer and start some serious development which led to the release of 1.0 within 6 months. Additionally, Peter and I are still friends and the experience taught me a valuable lesson about how and who to partner with on projects. I’ll be following up this post with a transparency report, which I’m hoping will be of use to him with regards to his share.
The developer I found is absolutely fantastic! He has an exceptional knowledge of WordPress and plugin development and is always very accommodating with any questions, support, and ideas that I have. He’s also upfront and honest about what is and isn’t possible with WordPress which is incredibly useful when it comes to developing the user experience of the plugin, something that has been one of my core values for BNFW since the beginning. We have a non-disclosure agreement in place together for his work on the plugin.
Current State of BNFW
In 12 months, and down to the effort I’ve put into the roadmap, alongside regular releases, I’ve had over 20,000 downloads of BNFW and it’s actively installed on over 3000 WP installs, averaging a rating of 4.9/5. It’s used on some pretty major sites across the globe and I couldn’t be happier with the progress, support, and kind words that people have contributed towards the plugin.
In January, providing I iron out a few last minute issues, I plan on releasing two premium add-ons via the Better Notifications for WordPress store. I have a load of other great add-ons that I want to develop this year too and can’t wait to get started on them.
Conclusion
I hope this has been an interesting read and helps give some insight into the origins of Better Notifications for WordPress, what its original purpose was, and a bit about where it is now. Next on this blog, I’ll be writing my first Transparency Report.
