Many have told me that WP Autoresponder is enormous. It sometimes surprises me just how much code I wrote in so little time. It is so enormous that it is incredibly hard for me to make any change these days without breaking something somewhere.
There are just too many moving parts for it to be fully testable before very single release. That is why I am not making too many changes in each release. A little here and a little there and that’s all I will be doing in the coming releases.
One major problem I face with working on the plugin is managing to keep every single feature working. Most parts of the plugin have bugs. A lot of it was written with the intention of making the bare minimum. The bare minimum that does something. But somewhere along the way I got carried away. I wrote too much bare minimum. These days I keep running into some serious issues when trying to add a new feature or fix an existing one. It is a struggle to keep the most basic features running on all servers before each release.
I’ve decided that moving forward there will be little to no new features added to the plugin until all the existing critical problems are resolved. That’s it no more. I am committed to making this the best solution for most businesses but that cannot happen if I am not able to move swiftly in the future without some baggage of past mistakes pulling me back.
The plugin’s progress will be in the following order:
- Basic background processing should start functioning again flawlessly (currently in progress): The most fundamental feature – email delivery has many issues – duplicate deliveries, lack of deliveries, complete stoppage of deliveries, among many other.
- Refactor the custom fields interface to not use temporary tables: The custom fields in the plugin are currently being fetched by creating temporary tables and then doing a join on those temporary tables. This has massive issues when it comes to actually replacing custom fields place holders in outgoing email with their values for a particular subscriber.First off, it is a pain to use the custom field interface. Second, it often overloads the database server where it runs.
- Complete rewrite of the subscriber management interface – The subscriber management interface does very little justice to the name it is assigned. Currently you can’t add new subscribers. Can’t subscribe existing ones to other newsletters/autoresponders/blog categories/the kitchen sink.
- Improvement to the subscription form interface: The welcome email will be made optional, the selection of custom fields will be more usable.
- Complete rewrite of the broadcast management interface: The user interface currently lies about things. When a broadcast has “been delivered”. It only means that it has been processed. Not that it has been delivered. It has been placed in queue. It has been delivered when the queue emails for that broadcast has finished. There is no way to stop a delivering broadcast. No way to see the delivery progress of a broadcast currently being delivered.
- Post series overhaul: Make the whole interface a single page. It is so simple I don’t know why does it need to have so many pages.
I am just amazed at the pace at which I wrote as much code that does something on the very first run. Mostly anyway. Something I can’t do anymore for some reason. I delivered a (more than) minimum viable product so fast and didn’t get bogged down by standards and peer critique.
I wrote a minimum viable product that does something at the speed of light and got it out there. Delivered software. Something I struggle with today for the smallest of projects – ones I even get paid for. I was a true
hacker! An innocent daring fireball of pure coding power. The problem: I feel stung by my earlier “mistakes”. I’ve been bombarded with support questions on problems in the UI lacking input validation or type checking or taking too much liberties afforded by PHP/Javascript and so on.
But this plugin can be made better in so many different ways:
- The user interface of the plugin can be made to look more WordPress-y
- The various forms in the plugin can be given nonces so that they are secure.
- All the text in the plugin can be made translatable through a translation file. Something people have been asking for well over a year now.
- The plugin’s code can be separated as models, views and controllers like I’ve been trying to for over 5 versions now.
What ’bout translation?
Most of the plugin will be rewritten completely. So translation will be partial in the beginning and will be complete nearing the end of the overhaul.