DragonByte Tech
Well-known member
The
This means it is impossible for add-ons to allow users to unsubscribe from individual non-transactional emails via this feature. Extending
For instance, users may wish to no longer receive emails from watched products from DragonByte eCommerce, but they would still like to receive emails about new sales that occur @ our site. The sale email and the watched email are both non-transactional, but they need entirely separate unsubscribe actions, it would be disastrous to lump all of them together.
For that reason, I'd call this a bug as I can't imagine such a design is intended, considering XF's track record of catering to 3rd party developers.
This issue can be fixed by adding two new parameters:
Adding those to the VERP and subject lines, then updating the parsing code to look for two additional fields.
If the parsing code detects a content type and content ID other than
This ensures minimal changes are needed to XF2 code while still offering near-automatic support for 3rd party addons' mailing lists (of course, we still need to update our emailing code to add the List-Unsubscribe header).
Fillip
List-Unsubscribe feature is a great, modern way to support quick unsubscriptions. However, it is currently suffering from a major design flaw: There is no support for the "content type" and "content ID" parameters we utilise in the EmailStop system.This means it is impossible for add-ons to allow users to unsubscribe from individual non-transactional emails via this feature. Extending
\XF\EmailUnsubscribe\Processor :: applyUserUnsubscribeAction is not feasible because that would unsubscribe the user from everything, when they may have just intended to unsubscribe from the mailing list they received an email from.For instance, users may wish to no longer receive emails from watched products from DragonByte eCommerce, but they would still like to receive emails about new sales that occur @ our site. The sale email and the watched email are both non-transactional, but they need entirely separate unsubscribe actions, it would be disastrous to lump all of them together.
For that reason, I'd call this a bug as I can't imagine such a design is intended, considering XF's track record of catering to 3rd party developers.
This issue can be fixed by adding two new parameters:
Code:
public function setListUnsubscribe($unsubEmail, $useVerp = false, $contentType = 'user', $contentId = 0)If the parsing code detects a content type and content ID other than
user / 0, it should fetch the email_stop_class and instantiate the EmailStop service for that content type and hit either stopOne or stopAll depending on the content ID.This ensures minimal changes are needed to XF2 code while still offering near-automatic support for 3rd party addons' mailing lists (of course, we still need to update our emailing code to add the List-Unsubscribe header).
Fillip
Upvote
4
