Scratch that, you can check if its on its way in or out.
I'm still dumbfounded as to how to get user/discussion information from all these crazily sensible classes.
I started work on it but didnt get particularly far. I got it emailing but people had to choose to email it (as a text formatter, there are better ways of doing it now). And i didnt get onto making it work out who to email and where they were. I might pick it up a bit more when v1 goes live but i cant see it happening in the meantime.
no problem, I may pick it up as I need it fairly soon for my board and it seems like once I learn the core vanilla code adding other stuff should be fairly simple
this would definitely be a good thing to have.
I am coding a similar system for my photogallery style forum.
Not that simple a task.
It would be simple if you trigger a new mail sent for EVERY reply a post has, but that sucks because if you are subscribed to a thread and choose to receive mails, if that thread is hot and 45 people post to it, u'll be spammed 45 times.
The idea is to have something like the other major bulletin boards, where uare only notified ONCE no matter how many replies the thread has, UNTIL you visit the thread again.
Hence there has to be logic to detect how many mails have been sent, when u last visited the thread, when the last mail was sent etc, and
THis is not easy considering that EACH thread has its own count.
I realized that there has to be some nifty DB side mods, as well as some php side work.
Not to mention another control panel to manage all ur subscriptions, and then more logic to determine WHEN u are subscribed to a thread (when u post a new thread? when u reply? only if manually choose to subscribe?)
And then u have to see how this entire "subscription" idea gels with vanilla concepts of "bookmarked discussions" and "your discussions" Etc.
Also need to check how much of a performance hit it will cause, because now every time u view a thread, db needs to be updated with last visit timestamp etc.. Every time someone sends a reply, db hit again (check who needs to be notified etc). What happens if a thread has 40 different people subscribing to it? If someone replies, the script needs to pump out 40 mails. Unless u implement a queue system.
Its a good feature to have, but not that simple.
Vanilla doesn't work in the same way. Vanilla is a "less is more" type of program. What doesn't exist can be added in an extension. As it gets older the more extensions there will be. E-mail updates won't be that far behind.
Agreed. I too am glad that this will be an extension for two reasons: 1) I'll use it and 2) It (and other extensions available) don't bloat the core. I'm really wanting this one, and hope it comes to fruition somewhat soon.
Vanill is a fine product and I anxiously await 1.0 and extensions like this one to fit our particular needs for a forum. To think I had either of the big "bloat boards" approved for purchase.
This forum will support what people write for it as extensions, on top of the already awesome and clean core. Nothing wrong with that, especially now that the developer has thrown down the gauntlet saying he'll program it if nobody else is going to. Gotta love Vanilla, Lussumo, and Mark!
this would be really useful functionality to have in an extension. i'd definitely use it!
how do you see it working though?
- everyone who has replied/contributed to a discussion is sent an email when a new update is posted?
- you receive an email when someone replies to one of your comments?
- everyone signed up to the forum receives an email when a new comment is added?
i have quite a small, low traffic forum i administer in my organisation with infrequent posts from members. if i had a way to let members know automatically when someone posts something that would be fabulous.
Comments
it is not a basic feature of vanilla 1.