CUNY Academic Commons

Boone,

I've looked through the plugin that handles this functionality and I see that the digest is handled mostly through WP's cron functionality. My first thoughts on a potential fix would be trying to use cron to set one-off (single event) notifications that are created when a new forum post is submitted, but I think that might get a little unwieldy on a large, high traffic site. There would be potential cron jobs all over the place. Then I thought we might be able to leverage the transients api. We could set a transient with an appropriate expire time and then every time wp loads (or more specifically when the plugin is instantiated) it could look for expired transients and fire off an email for each one. I'm not sure about the performance implications for this idea though. All that db access and the logic needed to keep track of which notices have been sent, plus would we keep the actual content of the forum post in the transient or pull that specific post back outa the db when its associated transient has expired? Sounds like a lot of work.

Also, I'd like to say this doesn't really sound like a "feature" to me. What I mean is: we may be opening up a whole slew of support emails about these delayed notifications. Think about this, a user posts a new forum entry, then 15-30 minutes later a notification is sent to all email subscribers. Those members that have already seen (on the web), and maybe even replied to that original post, are now getting notifications after the conversation has taken place. Think about very active forums, think about how much conversation can take place in 15-30 minutes! We could potentially be inundated with support requests claiming that forum notifications are always late and sent after the fact, which could be VERY confusing to members in an active forum.

If this feature is designed to help prevent users from getting garbage in their posts, we may be better off exploring ways to improve the error handling earlier during creation of the initial post, thereby preventing the types of errors that lead to the opening of this ticket.

Interesting thoughts, Dom. I'll let Boone speak to the technical issues, but as far as users go, I don't think this will be a big deal, especially if we shrink that 15-30 minute window down to, say, 5 minutes. The key thing is to give users a short chance to edit their posts before the posts get sent out far and wide. I think that the number of users who respond as quickly as you suggest above are actually pretty small. And the issue is not so much with error handling (despite what my quotation example above says) as giving users a chance to edit before the email gets sent.

One other alternative to this system, though, is giving users a chance to preview their posts before they go live. Of course, that can introduce other problems (users may think they've posted when, in reality, they've only previewed).

Matt,

I think you're right about the 5 min. That's much more feasible. The preview is definitely an interesting idea. Even something as simple as the preview below these updates here on Redmine.

Boone,

What do you think about not adding this functionality as a new feature in the plugin, but instead spooling the messages in the GC mail server?

I agree with Dom's original sentiment that a delay seems like sort of a kludgy way to deal with this.

but I think that might get a little unwieldy on a large, high traffic site. There would be potential cron jobs all over the place.

The transient solution that you suggest is, almost to a T, exactly how wp-cron works. It's not real cron. It just checks, on each page load, to see whether any scheduled events are due, and if so, it places a request to the pseudocron runner (wp-cron.php). If we're going to do this, I suggest that we do use WP's core features, instead of building our own version.

What do you think about not adding this functionality as a new feature in the plugin, but instead spooling the messages in the GC mail server?

I'm not sure how this would work (I don't know a lot about how spooling works in general). There are a number of application-side considerations: (a) we only want to delay email notifications of forum posts; (b) we need to have unique identifiers for emails, so that if I post to thread A, which triggers email A1, and then edit my post to trigger A2, the system has to know that A2 supersedes A1 (in cases where there could be a ton of email notifications in the queue). I'm not sure that our outgoing mail server has enough information about the emails to decide these sorts of things; it seems like it should be done from the WP end.

I agree generally that this should not be a default feature in the Group Email Subscription plugin, because it adds a ton of overhead for marginal benefit. My sense is that we should make it a secondary WP plugin (I can add hooks to BPGES if we need them).

Thanks, Boone. If there are technical reasons (potential server load, etc.) not to do this, we can live without it. But I do think it would be a nice feature to have if we can swing it. What do you think about a post preview as an alternative? In the past, I know you've been skeptical of the need for a preview feature, but I think that for many people, seeing a forum post in "publication" form enables them to do a different kind of proof reading than they are able to do while reading the text in the posting box. It seems to me that a preview button might be a more lightweight way of accomplishing the goal here, which is to give members a chance to proofread their posts before they are emailed out to groups.

I'm not opposed to the Preview functionality in principle, I'm just not sure how it should be implemented. See http://redmine.gc.cuny.edu/issues/589 I am going to write a few more thoughts on that ticket.

If it's between doing an email delay and a preview, I would far prefer the preview.

I'm not sure how this would work (I don't know a lot about how spooling works in general).

There's only one thing I am absolutely sure of when it comes to the field of Computer Science:

I do not want to be an admin for an email server.

So my knowledge of spooling is probably even less than yours. I was just running through all the possible avenues in my head to try and come up with a cleaner solution than constantly sticking expiring info into the DB.

Heading over to read your update to #589 now...