Issue: Vaultwiki Alerts Overkill

Reducing this effect will require same major changes to the way instant notifications are handled, such as using a deferred task to reduce the effect on big boards and by only sending one alert for each type of change made to the same node until the user visits that node again (or in the case of cookie-based visitor tracking, within a preset amount of time - like 1 hour). I will upload those changes to your test board once they are complete so you can test them for any issues.

The issue, as reported, is fixed in the next release.

Instant notifications are now processed via deferred task. This mitigates performance issues when the update triggering a notification affects a large number of nodes -- 1 discussion, 1 page, up to 12 books, 1 social group (vBulletin), infinite areas, infinite categories, infinite feeds, 1 entire wiki -- and where each affected node may have hundreds or thousands of subscribers.

1. Update activates deferred task. The IDs of known affected parent nodes are passed to the task.
2. Deferred task begins. We process one parent-type at a time in order of precedence.
   
   1. As before, a list of subscribers for all affected nodes of that type is compiled.
   2. We process up to 500 subscribers in a batch (could be lower depending on the actual processing speed). Because of a possible multiplicative effect, this number is fixed; see below.
      
      1. As before, we determine how many of the affected nodes the user is subscribed to.
      2. We exclude any subscription where a notification was logged within the last 30 days.
      3. As before, we only issue a notification for the closest node with a subscription that would include the update content.
      4. If a notification was sent, we log that a notification was sent for this subscription.

Visiting the node that the subscription was attached to will clear the log for that subscription, allowing new notifications to be sent. Additionally, if a node was not visited for 30 days, its log will be cleared.

Even though there are significantly fewer notifications to be sent, moderator notifications have also been moved to a deferred task.

I will do some more testing locally before I apply the changes at your site. With such massive changes, there is a risk that notifications are sent too often or not at all; due to legal ramifications of either, careful review is needed before roll-out.

In my opinion, it is worth applying similar throttling to the existing cron jobs for daily and weekly notifications and changing them to deferred tasks when they run, because of similar concerns: when 1 thousand nodes have updates in a week and they all have 1 thousand weekly subscribers, currently all 1 million notifications would be processed in a single batch... I am leaving this report open until this is also resolved.

This sounds very good to me.

I have also:
- Limited the number of content shown in a daily/weekly email to 10 items per content-type. This resolves a situation where a node with thousands of updates within a week could produce very long (and slow to send) emails.
- Implemented the XenForo settings that control whether inactive users should receive emails.
- Implemented the XenForo rules regarding users with a history of bouncing emails.
- Stopped sending emails to users with unconfirmed email addresses.
- Stopped sending emails to banned users.

Wow. That is very good to have implemented. Its easy to get blacklisted by sending to invalid email accounts.

Marking this issue as fixed in the next release.

I have uploaded the changes related to this issue to your site. Please check that email notifications and alerts still go out as expected. Since you are using unreleased code, and also since it is always possible that attempts to merge the code with your site produced a bad merge, please report any issues created by this change as new replies to this report, until a real version of 4.0.16 is uploaded to your site.