MailPoet is an awesome plugin, and I love to implement it for my users and customers. It’s my goto-solution for newsletters, period.
When using MailPoet as a developer, it would be even more awesome if we could rely on an API for a number of simple actions.
Imagine the following automations:
You have a BuddyPress website where users can select from a list of interests (let’s say for example: Movies, Music, Sports, Travel…).
Now, imagine you could build a script that would test those selected topics (using built-in BuddyPress functions), and would subscribe the users to specific MailPoet lists.
MailPoet has documented ONE developer functionality, that is quite close to what we want:
The documented method:
$user_data = array(
'email' => $user->user_email,
'firstname' => $user->user_firstname,
'lastname' => $user->user_lastname);
$data_subscriber = array(
'user' => $user_data,
'user_list' => array('list_ids' => array($my_list_id1,$my_list_id2))
);
$helper_user = WYSIJA::get('user','helper');
$helper_user->addSubscriber($data_subscriber);
This function is used when a user subscribes through the frontend… The limitation: if opt-in is globally requested, the user will get a confirmation request, he won’t be automatically added.
Now, you could disable the opt-in globally, and users will get added with this method – not bad!
But unfortunately, you typically have a public-facing subscription form where you DO want the opt-in to be active, and at the same time you want to run your fully automated process in the back-end… so there’s a need for another method.
By looking through the code of MailPoet, I came across the following functions:
$helper_user = WYSIJA::get('user','helper');
$helper_user->addToList(
$list,
$user
);
and this:
$helper_user = WYSIJA::get('user','helper');
$helper_user->removeFromLists(
array($list),
array($user)
);
I tried to use those functions for a project. First, everything seemed to work fine – on a small test site with a dozen of users, it allowed to sort them into lists as expected.
Unfortunately, when I tried to use it on a production site with about 400 WordPress/BuddyPress users, I noticed some errors and realized one thing: the WordPress user IDs are mostly matching the MailPoet IDs, but not always… so I was adding some users to the wrong lists. As a conclusion, we can’t rely on those functions to handle our WordPress users.
The question is: what would be needed, for a functional API?
Some ideas:
- ask to which lists a user (email address) is subscribed to.
- add WordPress user to a list (by ID or email address).
- if the list has an automated welcome message, decide if the user should get it upon subscription.
- remove a WordPress user and remove it from a list.
- create a list.
- delete a list.
Could that be a job for a custom plugin?