[Not Bug] Visiting A Single Post Via E-Mail Causes That Whole Forum To Be Marked READ

[DVD Plaza]

If you receive an e-mail notification that a thread you subscribed to has had a new post made, and you use the link to visit that post, that entire thread is then marked as "READ".

When you return to the site later any forums that have new messages are correctly lit, except the one you read a single thread from via e-mail.

This bug occurs obviously only if no posts were made since you read that one thread.

[DVD Plaza]

WHOA... correction, ALL forums are marked READ! If you return after reading just one thread via an e-mail, only posts that are new since that one thread was read are marked as new.

That's a major problem, I've been visiting a single thread because of e-mails and have not had time to look at anything else - now I look at the forums and I've got to sift through all the posts and work out by hand what I have and haven't read...

[Sharg]

Well this is normal.
When you visit the board (no matter if you come by email) the cookie will time out.

What you could do on your board, is set the cookie timeout to 10000000 so it won't time out between your visits and the only way to mark posts read would be to use the mark all read feature.

Though, I don't know if you can set a cookie time out that long.
Maybe an option of cookie no timeout would be welcome ?

[DVD Plaza]

Jesus, the whole way VBulletin handles "read/unread" really sucks. First it simply works on a timer base, now it treats reading a single post as reading an entire forum...?!?!?!?!?

I was busy working on a review so I simply read your post when it came via e-mail, so I guess now that I've yet again returned via that e-mail to post this reply when I venture into the other forums I'm yet again going to have to work out what is new and not new?

Seriously, how on earth does anyone cope with this approach? This is driving me nuts!

I'd much rather going directly to an individual thread have no impact at all, and going to the main forum page for the first time in a session (ie not going to it via any of the links within the forums) generates the "let's update what is new and not new".

[Sharg]

The only difference with 1.5 is that now threads are marked read during your session once you open them. Its only a benefit.

[Me2Be]

I think it's a great feature actually -- otherwise my visitors will always have new messages lit when they return. Most don't use the mark forums read feature, and at least when they return in 15-20 minutes, they'll only see the new messages.

Personally, I think it is one of the better features on this software!

[DVD Plaza]

So let's say a member does a "report post to moderator". I'm flat out so that message is great - I know there is something up and I go straight to that post, sort it out, and get back to my work.

Several hours later I return and read all the messages marked as read. Given all the messages were reset when I went and sorted out the above problem, exactly how do I know what I "really" have and haven't checked?

The same applies with e-mail notification - again that's a perfect case right at this moment. It's 3am here, I am working like crazy to finish a heap of stuff and get to bed. I've received notification there is a reply here, I've come straight to it, am writing this reply, and will then be closing this off and readying for bed (I have to be up at 6am!!!).

So again, suddenly EVERY message will now be marked as read simply because I'm leaping to this one post.

That's obserd, Jelsoft is sabotaging the ability to properly do moderating duties if there is no way you for you properly see what is and isn't new since your last visit. This is hardly a visit, I'm just popping in because of an e-mail notification, but in the process VBulletin has now nuked the "new message" mark for every message that is new and I haven't seen. Thus, when I return tomorrow I'll only be seeing messages marked new that occured between NOW (an irrelevant visit) and THEN.

So the official line from Jelsoft is that I must sit down tomorrow and manually work out the last time I was on (say 1am) and the time right now (3am) and then work out for myself all the messages I've missed because VBulletin did a reset?

During the day the opposite is true - I'll be reading through message upon message upon message - it can take me a good half an hour to an hour to go through them all. Immediately after I then return and do the same, because during that hour plenty more posts were made. But, here VBulletin does something stupid again - it still marks all the old stuff as unread. The official line I got from Jelsoft is that you have to walk away for 15 minutes, and then return.

For those that have always worked this way, this all might seem like common sense - but to me it's crippling not only the usability of the system, but the ability for moderators to actually monitor every post - they're going to be missing stuff left, right, and centre. For example some of my helpers pop in from work, responding to automatic notifications all day. When they go home, they're going to find that the entire day's messages are marked as read!!!!

For a product that is so brilliantly dynamic in every respect, why isn't each individual thread given it's own read/unread mark? There could even be a "Cripple ability to accurately identify new threads" checkbox to engage the present way of working :)

Well I'm off to bed - and in the process causing all messages that are new since my last visit and the present time to be marked as read.

[Sharg]

Several hours later I return and read all the messages marked as read. Given all the messages were reset when I went and sorted out the above problem, exactly how do I know what I "really" have and haven't checked?

It has ALWAYS be this way, or do I miss the point ?

[DVD Plaza]

Yes it has always worked this way so from that aspect it's not a VB2 specific complaint.

That said, I thought the visiting via e-mail notification aspect was a VB2 bug... unbelievably it would appear not. It's a classic Infopop "By Design".

[Me2Be]

Originally posted by Sharg
It has ALWAYS be this way, or do I miss the point ? You are right -- most of us love this feature but I guess there are always a small few who won't. Can't please everyone I guess :)'

This feature is VERY important to my visitors and I think it is what makes Vb stand out from UBBs crappy cookie system. I hope Jelsoft doesn't make any plans to change it.

[dwh]

The feature is great, but it's confusing too. The problem is there is a difference between "Read" message, and "new" message.

When you login, you probably want to know what the new messages are since last login. You want this list to remain there for the duration of your login. The new feature of marking as read those posts specifically read, is cool.

Another feature, which probably would add WAY too much resources required, but would be cool nonetheless, would be to have each thread or even post marked as read if you have read it before. (Post is harder to do than thread, but still possible).

[DVD Plaza]

So what's the point of marking any individual post, thread, nor forum as being read/unread if it's not even correct. By responding to these e-mail notifications I'm having those settings destroyed, nuked, deleted, whiped out...

The marking of ANYTHING as read or unread seems totally useless to me if it's going to be stuffed around like that?

This feature is VERY important to my visitors and I think it is what makes Vb stand out from UBBs crappy cookie system.
What does the location of the setting have to do with anything? Yes storing the settings within mySQL is great, but whether its stored within a cookie or mySQL isn't relevant - regardless of WHERE the setting is stored, VBulletin decides to wipe your read/unreads when you haven't even had a chance to read them.

What I'm saying is that UBB will reset the read/unreads when you go to the main forum page, and actually had an opportunity to navigate to forums and posts. VBulletin wipes it all out simply because you came to a post via e-mail - that's rediculous?

One would assume that if VBulletin goes as far as to put a yellow dot next to every individual post that is new and a white one next to every post that has been read, that it is actually true?

I'm forever reading through new posts in this place and wondering why on earth I've never read the replies immediately before them. It's because they were reset without my ever having a chance to know they were there.

This feature is VERY important to my visitors
What is it I'm missing here? How can this be important to anyone, I'm talking about something that causes you to MISS new posts. It's the same as arriving and being told you have "0" new private messages, when in fact there are "5" but "too bad, you responded to an e-mail notification earlier today so now the figure is 0". Why bother telling the user that if it's untrue?

[bira]

Chris why don't you just increase the cookie timeout in the Control Panel's Options?

[Martin]

if he sets the cookie timeout to 10000000000000000, or some such ridiculous number, it will never clear users from the "online" list, resulting in apparently having 1000000 users online at the same time.

there is a competitive BB that does what he's talking about, and I don't know ho wthey do it, but it would be a great feature to have here.

I can go there, read one thread, come back 6 months later and all the threads I haven't read are still marked as such. IMNSHO, that's the way it should be, but I don't know how to implement it.

[DVD Plaza]

I can go there, read one thread, come back 6 months later and all the threads I haven't read are still marked as such. IMNSHO, that's the way it should be, but I don't know how to implement it.
YES, that's exactly what I'm talking about!

With VBulletin you don't truly see read/unread threads - if you come back too soon threads you have read are still marked unread, and if you go directly to a thread via a link you end up resetting the unread marks for every single thread.

I'm amazed anyone can cope with VBulletin doing this, in my opinion it's not simply a bug it's a major flaw - how can it be acceptable to have hundreds of threads reset simply because you visited a thread via an e-mail notification - whoa!!!!

[Martin]

Originally posted by DVD Plaza

YES, that's exactly what I'm talking about!

With VBulletin you don't truly see read/unread threads - if you come back too soon threads you have read are still marked unread, and if you go directly to a thread via a link you end up resetting the unread marks for every single thread.

I'm amazed anyone can cope with VBulletin doing this, in my opinion it's not simply a bug it's a major flaw - how can it be acceptable to have hundreds of threads reset simply because you visited a thread via an e-mail notification - whoa!!!!

apparently something is dicked up in yours. when I read a topic, it closes the envelope in that session until someone posts in it, then it reopens the envelope.

as for being a major flaw, I think you're overstating the case. the other bb software is the only one I know of that does it like that, so I would call it a missing FEATURE, not a major flaw.-

[DVD Plaza]

I haven't visited any of the forums here since I made the initial post, and have only been coming back via e-mail notifications taking me directly to this one thread. I've continued to return directly to this thread each time I receive notification, again I state I have not visited VBulletin since 3am last night.

Now that I'm having a quick break in my night's work, I finally have a chance to return to VBulletin. What do I find? You would expect that everything that is new since 3am last night to be marked as "unread" right?

No, everything has been reset. Why? Because each time you click on an e-mail notification, an e-mail notification taking you to ONE THREAD, it causes EVERY SINGLE THREAD to be marked as read (15 minutes later).

VBulletin assumes I went and read all those other messages - I did not, the point of the e-mail notification was to let me know about the ONE thread - I did NOT touch anything else yet it has reset EVERYTHING!

One person here said that was a "feature", and now NOT doing that is called a "feature"?

So is the official and final stance of Jelsoft the following:

User makes a post with e-mail notification turn on
User receives a e-mail notification FIVE MONTHS LATER
User clicks on e-mail notification
VBulletin decides to reset every thread from the past five months as being read - even though they only went to the one thread and then left.

As I said, I haven't been looking at these forums since 3am yesterday and have only been coming to this one via e-mail notification. Yet tonight I arrive and find, as expected, every thread has reset each time I visited the ONE thread.

Thus... either I sift through every forum and look at every single thread to see if the date is newer than 3am yesterday (which is what VBulletin would automatically do had it not reset the date stamp just because I came to ONE thread), or I just give up.

Tonight, I give up. I don't have the time to manually work out what I have and haven't already read. :(

[bira]

I'm not sure, but I think there is no other viable way to go about it, other than time. And, since it has always been like that in vBulletin (I don't remember it being any better in UBB - I don't remember at all how it worked there), me and my users are quite used to it, knowing full well that when you visit the BB, you will see new threads since your last visit, whereby every visit to the BB - regardless to which page - consititutes as a last visit. By the way, even if you as an admin visit the control panel...

There's no doubt it would be perfect if threads and forums would actually be marked read/unread - I don't really know what m2be is talking about when she says her users love the feature - but I suspect the load non the system, for keeping track in the db for every single user will be so high, that it just won't make it worth while.

I for one would settle for the way it is now, if it adds load.

Just my 0.02

[DVD Plaza]

So the general consensus is that VBulletin has been written in a way that it's too much work to fix the problem of the way the entire forums reset 15 minutes after visiting. This I can live with, even if annoying.

That said, it is still totally wrong for VBulletion reset ANYTHING just because you arrived at a thread via e-mail.

As a programmer myself, I'm not sure why it would take more than say... 5 minutes? ... to do the following:

* Change e-mail notifications to be in the following format (note the &referredvia=email parameter):
http://www.vbulletin.com/forum/showthread.php?threadid=9054&goto=newpost&referredvia=email
* Change the showthread routine so that it updates/resets the last visit timestamp ONLY IF referredvia does NOT equal email

Problem fixed - if you get sent an e-mail notification and you click the link, the entire forums are not suddenly reset on you.

IF you decide to cruise elsewhere in the forums, suddenly the normal timestamp update will occur since the referredvia parameter is missing.

In other words, simply visiting an e-mail link doesn't suddenly whipe out days/weeks/months worth of new post markers.

[Sharg]

Well thats if the guy is only reading the thread he got notification from.
But what if after getting to the board from Email, the guy wants to read all the threads and not just the email notified one ? (just a question)

[Martin]

the email link thing definitely needs fixing if that's what it's doing. I think in my tiredness, I misread your post.

As for the other, I don't think it's that code is written in a way it can't be done, it's just that it isn't a feature now, but could be a feature in a future release.

For the record, I asked for it to be that way when vB was a baby :)

[DVD Plaza]

But what if after getting to the board from Email, the guy wants to read all the threads and not just the email notified one ? (just a question)
If they did that it would be exactly the same as navigating right now - the second you touch something, the reads/unreads update. That's exactly what should happen.

the email link thing definitely needs fixing if that's what it's doing. I think in my tiredness, I misread your post.
That makes a little more sense, I was wondering how anyone could find it "normal" that the reads/unreads reset simply for clicking on an e-mail notification.

One thing my solution didn't address is replying to the thread - my proposal would only stop "viewing the thread via e-mail" causing the reads/unreads to update. The script would need to check if the parameter was passed, and if so ensure the reply links include the parameter. The reply routine should then be sure to pass that on, so that when a reply is made and the thread redisplayed the parameter is continued to be passed on so that the reads/unreads don't update.

Thus if an e-mail notification is clicked then viewing AND/OR replying will not cause every read/unread to reset. However if you do anything else, such as viewing profiles or going to other threads or whatever then it'll cause the timestamps to reset.

Hope that makes sense :)

[IgeL]

I'm with DVD Plaza here... It's not that bad for me though, because my board gets like 10 new messages a day, but it would be cool if you could choose how you'd like it to be; the current way or the new way...

[dwh]

Good idea...

Also, how about making this whole thing more flexible. Like an option in profile to prompt you to reset read messages and it would be a link on the top of the page. Dunno if I'm making this clear..

[edward]

Originally posted by Martin
For the record, I asked for it to be that way when vB was a baby :)

What's the logic behind that?

As a reader, I find it very frustrating having to speed read all forums within $cookietimeout seconds before I lose all state information.

Why can't each user have a list of thread ids that they've viewed, and the last post they saw in that thread?

[DVD Plaza]

The e-mail notification is really becoming quite a useless feature once you realise the flaw in it. I got several notifications over the weekend for a few threads I am subscribed to, and had to ignore them. The reason for that is I did not have the time at that point to read through all the new threads here, but if I had responded to the e-mail notification I would have had no choice - else VBulletin would reset every single thread 15 minutes later.

Perhaps e-mail notifications should include a clause:

"Jelsoft advises to disregard this e-mail unless you have time to read through ALL new posts at this forum. Should you visit the link contained in this e-mail, our software will reset every single thread regardless of whether you simply visited the one thread in this e-mail or visited the forums."

[bira]

I would venture to say your point was made loud and clear. Why harp on it further?

[DVD Plaza]

Because it's a major problem that could be so easily and quickly fixed, but has been officially labelled "not a bug".

[bira]

I don't agree with you that it's a major problem, and I don't agree with you that it can be easily resolved.

1) It's been like that from vB's day one. I've never as much as had a single complaint from my users -- who are very fierce in complaining about everything, I assure you -- and in fact didn't even give it a second's thought before I saw this thread.

That's not to say that your point is not valid - it can definitely be better, and as Martin I think said - it's not a bug, it's just a feature that is currently not included in vB. It seems that for a long time, though, many people - here and on their respective boards - didn't mind it so much.

2) As for adding this feature - that requires a major change in the way vB works. It's not just a simple "let's throw in this line here" hack. It means changing some db table(s), it means running many validations, etc. That is NOT a feature you throw in at a whim.

As for your solution of adding a disclaimer to the notify e-mails - well, you can do that yourself. You don't need Jelsoft or anyone else to do it. Just go to the templates and edit "email_notify" -- you can add whatever text you want there.



I want to stress out that I am not belittling your idea or your disappointment. I am merely trying to tell you from another user's standpoint that I think you are overstating the "problem" (and it's definitely NOT a bug) and understating the "solution" - at least as far as coding goes.

Cheers,

Bira

[Wayne Luke]

Hold on...

I visit hundreds of threads a day on many vBulletins from links in my emails and it never resets the entire forum. After reading that thread there are plenty of new messages that I check. Later when I come back they are marked as read because I spent more than the 5 minutes or so each board allots for this.

What is your cookie time out set to?

[bira]

Wluke, his problem is that he clicks on the notify-mail's link, then comes back maybe hours later and doesn't realize he missed messages that were "unread" back when he read only that thread he was notified on.

[Parker Clack]

I there any way to add a "Bypass Cookie" type of line to the end of the email links that get sent out so that if you do go back to the thread in question via the email link it bypasses the cookie timeout altogether?

Just a thought.

Parker

[DVD Plaza]

At the moment VBulletin resets everything 15 minutes after you visit. The problem is, if you receive an e-mail notification and you click on it and JUST read that one thread and LEAVE - if you return 20 minutes later EVERYTHING is marked read...

In other words, reading that ONE thread via e-mail causes VBulletin to engage its 15 minute reset cycle.

I'm not sure why table structures need changing, or anything more complex than the two/three lines I suggested in a previous post. All that needs doing is the following:

* Links provided via e-mail have a tag added to the end such as &viaemail=true
* In the view thread routine, where it somewhere tells the system to reset every thread in 15 minutes, you change it to only do it if "viamail" is NOT true

That's it. VBulletin would continue to work as normal, because "viaemail" would never be true. BUT if you use an e-mail link, whch contains that setting, it causes the VBulletin to not do any resets.

Thus at the moment:

* Visit an e-mail notification, leave VBulletin, and in 15 minutes EVERY SINGLE THREAD is now READ!

But with the above simple fix:

* Visit an e-mail notification, leave VBulletin, and it's as if you never came - NO READS/UNREADS are touched.

The problem with the present system is that if you had not been to the forums in 24 hours and then visited ONE THREAD via e-mail, EVERY THREAD is now read and when you return later you will have lost track of every single new thread in the past 24 hours.

With my whole 2-3 lines of fix if you had not been to the forums in 24 hours, visit ONE THREAD via e-mail, and then return later - everything that is unread in the past 24 hours is STILL unread... nothing ever changed - the disadvantage is that the ONE thread you did read is still unread as well. Big deal, better than 10s/100s of threads being marked read that are unread?

You could even take it a tad further with another *1* line of code:

* Whenever a reply to thread is done, create a hidden field called "viaemail" that passes that variable.

Thus if you use the forums normally, "viaemail" is nothing so the hidden field contains nothing and nothing is changed. You post a reply, nothing different.

If you visit a thread via an e-mail, the "viaemail" is true which means the reads/unreads are not touched. If you then hit reply, that "viaemail" is passed along. No worries, nothing different here. The difference is that when you hit submit, you are now taken to the "ViewThread" again - but because you passed along the "viaemail" the unreads/reads are still not touched. Thus you can view, and reply, to a thread via e-mail but not touch 100s/1000s of other threads.

The reason I see this as so important is not "e-mail notificatoin", but that this same fix be done to "Report this post to a moderator".

Let's say you have moderators that receive their e-mail at work. No problems arise in the forums, and the moderator is busy at work, so they don't visit the forums AT ALL during the day. Then right before they go home:

* 4:50pm they get an e-mail "Report Post ToT Moderator"
* They read the e-mail reporting the problem
* They click the URL in the e-mail to go to the thread
* They action whatever needs doing
* They leave (without having touched a single other thread)

They then go home and, as a good moderator, logs in to read through EVERY post for that day (not sure how other forums work, but my moderators read EVERY post to make sure everything is okay):

* Logs in at 5:15pm
* Finds that the ENTIRE DAYS posts are marked as READ - except messages made since ~4:50pm

Now I'm exaggerating the time to be at the end of the day to highlight the problem, but it could have happened at 9am... which means if they had visited first say at 6am and then responded to an e-mail at 9am then when they get home that night they will miss any new messages that occurred between 6am-9am...

Hope that makes sense, and explains why this can be very dangerous - it cripples the ability the properly moderate - unless you instruct your staff to never touch e-mails unless they will definitely have the time to read ALL NEW POSTS, otherwise all those posts will be marked as read later.

What is even more concerning is that people are running "moderated VBulletin forums", and don't realise that this quirk is preventing them from moderating properly.

Imagine if I swore in this post and someone reports this thread. Every one of your staff are busy so all they do is respond to the e-mail and come to this thread. They deal with it, and then leave. All messages are now marked as read 15 minutes later. When they return, they only read all the messages that are new SINCE they visited the trouble thread.

But little did anyone realise that 1 minute prior to my post someone had posted a reply in a thread talking about religion, and for the sake of example let's say you forbid it. Nobody reports it, it happend a minute BEFORE mine so it is marked as read, and thus no moderator goes into the thread.

Ooooops, that post was actually slaughtering a religion, and a media person reads it and writes a report that your nice "VBulletin" forums have topics slashing the crap out of religion...

Even though your moderators spend so much time ensuring they read EVERY SINGLE POST, it was wasted because VBulletin marked 10s/100s of threads as read simply because of an e-mail.

Some of us deal with some serious trouble makers, that's an unfortunate reality of the Internet and giving people the ability to post to your site, so I hope that helps explain the potential disaster this opens up.

And sorry I've dragged this on for three pages :), I'm just not convinced anyone has understood the extremely simple solution I propose - five minutes work maybe?

[DVD Plaza]

Peter - That's what I tried proposing a couple of pages back, seems pretty simple to me? It's the same trick UBB uses to stop RE-visits to the front page from resetting the cookie.

[edward]

This whole situation just exposes vB's weak state management.

[DVD Plaza]

I was just thinking - why on Earth does VBulletin update the 15 minute reset counter when viewing posts anyway?

If you view the main forum listing, or a sub forum listing, then sure activate the timer that causes everything to reset in 15 minutes.

However, why would it ever need to happen just because you viewed an individual thread? If you got to the thread via the forums then your 15 minute timer is already engaged. If not, you DON'T want the timer activating anyway.

I visited two e-mail notifications last night, simply read the thread and left, and returned later in the night. As usual, when I returned (about half an hour later) everything was marked as read bar around two threads. ARGH!!!!!!

If the reset didn't happen with the threads themselves, you wouldn't even need to bother changing anything for e-mail notifications (both subscriptions and moderator warnings).

Given the developers seem to consider this major problem a feature, is there anyone fluent with the code that knows which line of code in the "view thread" updates the 15 minute reset (I'd find it myself, but am not defecting to VB until this issue is sorted plus the new server has been in place for a month)? If so I'll just nuke that line myself.

[PFunk]

Originally posted by edward
This whole situation just exposes vB's weak state management.

weak state management? Let's run this through some numbers.

Lets say you have a table that looks like this

threadview table.
threadid int(10) unsigned
userid int(10) unsigned
datelastviewed int(10) unsigned

Each column is 4 bytes in length. Total of 12 bytes per record.

For this example, lets say we have 1000 users and 1000 threads.

1000 users * 1000 threads = 1,000,000 records to hold the entire set.

1,000,000 * 12 bytes = 12,000,000 bytes or 11.44MB for the entire set. Not really a problem for a lot of us.

Lets use a larger forum: say vbulletin.com's numbers.
3623 users and 11856 threads.
3623 * 11856 = 42,954,288
42,954,288 * 12 bytes = 515,451,456 or 491.57MB Getting to be a problem for alot of us.

And now lets use a HUGE forum:
10000 users and 50000 threads.

10000 * 50000 = 500,000,000
500,000,000 * 12 bytes = 6,000,000,000 bytes or 5.722GB A problem for 99.9% of us.


These numbers take into account 0 indexes on this table.

As you can see, this is not really an option because people don't usually have access to that much space for a simple "index" table of threadviews not to mention the server overhead.


In Conclusion The only real option is to allow a "bypass".

[DVD Plaza]

Your example is like saying there will be a penalty of 1c for everyone that spends $1. If you spend $100 that's only a $1 penalty, bit if you spend $1 million then that's a penalty of $10,000. That $10,000 is huuuuge, but the guy spending $100 isn't paying that - the guy spending $1 million is.

You're figure of 5.722GB is relevant only to someone having say 100GB worth of forums (I don't know the exact figures), and they wouldn't give a rats about a mere 5GB. Furthermore that 5GB has nothing to do with the average person having maybe 50MB worth of forums?

In any case I don't care for state management, I can't remember who brought it up, but I think VB having "on the fly" state management is cool enough - all I want is a bypass flag to solve the flaw associated with e-mail notifications (via posts as well as moderator reports). Seemed like a simple enough request to me, but Jelsoft can't seem to even acknowledge the problem (other than declaring it not a bug, so therefore the flaw is a feature - good thing Jelsoft don't deal with medicine, side effects are a serious issue in that department).

[DVD Plaza]

OH DAMN!!! I'm heading out right now so I can't check all the other threads, I came here via an e-mail notification.

Since I haven't been here in days, I'm now going to have days worth of threads reset in 15 minutes... BLOODY HELL!!!!!

[eva2000]

Originally posted by DVD Plaza
OH DAMN!!! I'm heading out right now so I can't check all the other threads, I came here via an e-mail notification.

Since I haven't been here in days, I'm now going to have days worth of threads reset in 15 minutes... BLOODY HELL!!!!! Chris congrats on the new server going live :)

so is this the bug that's holding back dvdplaza.com.au moving to vB for it's forums ?

i just ordered my first ever DVDs region 4 a few days ago can't wait to get on your forums to seek out dvd bargains :D

[tubedogg]

Originally posted by edward
As a reader, I find it very frustrating having to speed read all forums within $cookietimeout seconds before I lose all state information.

As long as you're clicking around (and you don't take 15 minutes on a single thread) you won't lose any info, and posts will still be marked as unread / read. It's only if you click through from an email and then come back hours or days later that you might have a problem. The $cookietimeout timer gets restarted every time you click something. It only marks everything as read after $cookietimeout seconds of inactivity.

[eva2000]

Originally posted by tubedogg


As long as you're clicking around (and you don't take 15 minutes on a single thread) you won't lose any info, and posts will still be marked as unread / read. It's only if you click through from an email and then come back hours or days later that you might have a problem. The $cookietimeout timer gets restarted every time you click something. It only marks everything as read after $cookietimeout seconds of inactivity. just checked i am have my cookie timeout set to 30 mins of inactivity

[theflow]

Whatever happened re this issue? I found this thread via search, just read it all. Last post was in March. I joined in June or July. Thus can't tell if the issues raised by DVD plaza -- as well as his suggested solutions --were ever addressed by Jelsoft. I'd been wondering why the read/unread markings seemed to not be accurate. Now I see why. Anyone have an update?


Originally posted by DVD Plaza
At the moment VBulletin resets everything 15 minutes after you visit. The problem is, if you receive an e-mail notification and you click on it and JUST read that one thread and LEAVE - if you return 20 minutes later EVERYTHING is marked read...

In other words, reading that ONE thread via e-mail causes VBulletin to engage its 15 minute reset cycle.

I'm not sure why table structures need changing, or anything more complex than the two/three lines I suggested in a previous post. All that needs doing is the following:

* Links provided via e-mail have a tag added to the end such as &viaemail=true
* In the view thread routine, where it somewhere tells the system to reset every thread in 15 minutes, you change it to only do it if "viamail" is NOT true

That's it. VBulletin would continue to work as normal, because "viaemail" would never be true. BUT if you use an e-mail link, whch contains that setting, it causes the VBulletin to not do any resets.

Thus at the moment:

* Visit an e-mail notification, leave VBulletin, and in 15 minutes EVERY SINGLE THREAD is now READ!

But with the above simple fix:

* Visit an e-mail notification, leave VBulletin, and it's as if you never came - NO READS/UNREADS are touched.

... the disadvantage is that the ONE thread you did read is still unread as well. Big deal, better than 10s/100s of threads being marked read that are unread?

You could even take it a tad further with another *1* line of code:

* Whenever a reply to thread is done, create a hidden field called "viaemail" that passes that variable.

Thus if you use the forums normally, "viaemail" is nothing so the hidden field contains nothing and nothing is changed. You post a reply, nothing different.

If you visit a thread via an e-mail, the "viaemail" is true which means the reads/unreads are not touched. If you then hit reply, that "viaemail" is passed along. No worries, nothing different here. The difference is that when you hit submit, you are now taken to the "ViewThread" again - but because you passed along the "viaemail" the unreads/reads are still not touched. Thus you can view, and reply, to a thread via e-mail but not touch 100s/1000s of other threads.

[DVD Plaza]

Freddie incorporate such a flag into vBulletin, but for the life I've me I've never been able to find his post again (t'was in another thread) so that I know the flag to use. Thus for the moment it's been causing a lot of grief, problems, and confusion but I haven't had a chance to chase it up (my issue is not just e-mails, but because we post DVD reviews into the forums all the posts get reset if you read one via a front page promo and then leave).

Hopefully Freddie can clarify, been meaning to send him a PM about it.

[tubedogg]

&bypass=1

[DVD Plaza]

There we go, simple as that :)

Thanks guys, I better go update the templates and our links now :)

[theflow]

Originally posted by DVD Plaza
Freddie incorporate such a flag into vBulletin, but for the life I've me I've never been able to find his post again

Is it contained in this thread?
http://www.vbulletin.com/forum/showthread.php?s=&threadid=2822

What's "&bypass=1" mean ?

[thewitt]

Unfortunately it still leaves the bigger problem - which it appears will not be addressed.

There is a basic philosophy issue here. vB developers have decided that when someone comes to the forums, they will have the time to read through all the new messages before they go do something else. The only tuning mechanism for this is a cookie timeout - which can be lengthened somewhat, but has negative side effects if set too long. How long is long? It depends. Is it reasonable to believe that someone will visit once for 5 minutes, then read all your new posts in 30 minutes? 60? 2 hours? 24 hours? Who is still logged in after 23 hours of inactivity?

Whenever this characteristic of the software is brought up, people who like it this way, or who have been trained to read the entire board when they decide to visit one, tell others to live with it or change BBS products to something else, or that this is programatically too difficult to deal with or some such thing.

I find that this vB behavior determines my surfing habits, and I don't go to high traffic boards like SitePoint.com, as often as I would like. If I don't have the 45 minutes on a given day it requires for me to browse all the new threads in one session - I don't visit on that day. I might have 10 or 15 minutes to drop by a board at any given time, but since I don't have the time to browse all posts, I don't go - or I go and speed-read the threads and certainly miss some that I know I would have enjoyed. This problem of course compounds over time, as each day I skip going, the number of new posts gets larger and larger, and the time I'll need to spend for a qualify visit goes up and up. Eventually I'll breeze in, speed-read the threads and mark all as read, so I can reset the new thread counts and start over again. I know I miss a great deal of discussion that way, but I hope that the threads I care about will still be active, and I can sneak in from a new posting - reading backwards till I find what I remember I read and then post intelligently.

I've not given this any thought from a programmers perspective, but at some point I will. Even though my board is small - 240 registered users, 330 threads, 1100 posts in total - I've received dozens of complaints about this feature - and had to explain the time bomb to my users in both the FAQ and in a canned email reply I send anyone who complains. The last board I used had individual files as posts, so the links in the thread listing showed as visited in your browser if you had read the message. It had many other problems with forced me to find a better product, and vB is that product, but the cookie visit timeout issue is still very real for me.

The basic story as I see it here is simple. The current design of vB assumes that when you go visit a board, you will have the time to read all the new posts that interest you. If you don't believe you have that much time right now, than you might want to reconsider visiting that particular board right now. I'm glad there is a template modification for email notification, but that's only a very small piece of the problem from my perspective.

-t

[theflow]

Originally posted by thewitt
There is a basic philosophy issue here. vB developers have decided that when someone comes to the forums, they will have the time to read through all the new messages before they go do something else. The only tuning mechanism for this is a cookie timeout ... better product... vB is that product, but the cookie visit timeout issue is still very real for me. ... I'm glad there is a template modification for email notification, but that's only a very small piece of the problem from my perspective. Thanks for the thoughtful reply. A 'paradigm shift' is not likely to happen here; the cookie timeout behaviors are alternately damned and embraced, but the embraces seem to win. Thus, I imagine that when vB is doing prioritization and resource allocation, this issue is deemed "not enough bang for buck" to devote time to. Hopefully in future someone will figure out a way to make the flagging of read/unread more accurate -- and if it's not vB themselves who figures it out, hopefully they will nonetheless embrace a good suggestion and implement it.

[tubedogg]

If any of you have any suggestions as to how to implement this (and make it resource-friendly) we're all ears. The problem is that for larger boards, and even some smaller boards, the amount of data stored would be astronomical. We just can't justify adding a feature that would generate a table with data such as the following:
200 members
1000 threads
200*1000 = 200,000
So for 200 members (a small board) you have a table with 200,000 rows. Not good.

If anyone has any suggestion as to how we could implement this in an alternative way, as I said we'd be more than happy to hear from you.

[tubedogg]

Originally posted by thewitt
,,,or that this is programatically too difficult to deal with...Not so much programatically as much as it would increase exponentially the space required for a vBulletin database.
The last board I used had individual files as posts, so the links in the thread listing showed as visited in your browser if you had read the message.Wayne Luke has recently added a visited link color to his threads at SitePoint using plain HTML. At my site I use underlines on unvisited links and no underline on visited links. You could use simple HTML for visited links to create a difference.

[theflow]

Kevin, what's "&bypass=1" mean ? Is this some workaround piece of code? or an inside joke or what? I really just don't know what it is.

[tubedogg]

You can add that to any URL and as long as you only look at that page it will not reset your last visited time; meaning, posts will not be marked as read the next time you come back as they normally would.

[ethank]

I fixed this by severely hacking my forums to use a database to keep track of the Mark Read time. This also allows me to let users mark individual forums as read. By doing this, the cookie timeout is irrelevent, and users can come on, read what they can, leave and still have it evident what they have and haven't read when they come back.

Using cookies to keep track of read messages really is the only feature of vBulletin I hated, which is why we had to program this hack before going live. We have boards that have 1400 messages a day, and its impossible for people to read them all. Without converting the "read" tracking to the database, a lot of posts would be ignored.

Since the hack is pretty intensive, I haven't had a chance to really document all the changes. Its the one feature of vBulletin that falls short, even compared to ChatSpace's Webboard (which is essentially what I modeled the hack on).

Anyhow, we use a DB to track read status, no complaints from users. And no performance problems, since its tracking forums and not threads.

I'd be more than willing to share my code with Jellsoft.

Ethan

[theflow]

Originally posted by ethank
we use a DB to track read status, no complaints from users. And no performance problems, since its tracking forums and not threads.Ethan, I'm not a coder so sorry if this sounds too newbie: I don't know anything about adding to the database and running various checks, and using a different method than vB to flag mesgs as "read" or "not read", and whether your method is or is not creating a performance problem. All I know is I don't like the way vB does it currently; I find it too inaccurate. If your method works great, I would like to hear more. If the hack is something substantial yet it performs flawlessly (or at least much much much better than vB's system), then I would want to buy your hack, and so would many other people I am sure, if you pulled it into a relase with documentation etc. Maybe it would be worth your while if peole paid for copuies of this hack. But I being non tech have no means to validate that your system works great. Maybe you can provide further details in a use-case scenario. as in:

"Person A comes to the board via an email notification URL.... then leaves after checking that one message" (results in these kinds of flag triggers..; better than vB's method because of "x")

"Person B comes to board board via an email notification URL and stays, surfing through various threads on various forums" (results in these kinds of flag triggers..; better than vB's method because of "x")

"Person C comes to board directly and starts reading "new" messages" ... etc. (results in these kinds of flag triggers..; better than vB's method because of "x")

If I understood the mechanics of what you were doing, then I could better detremine if such a system would work better for me.

---
Also: I read thoroughly this thread a few nights ago after finding it in search. It had been a dead issue since March. Though vB may decide they have an interest in your solution (best case scenario), it would still be monthas and months away before it might find its way into a release. Therefore, if it is demonstrably a better and more accurate system, I would be willing to pay for a well-documented hack. Thank you.

[ethank]

Originally posted by theflow
Ethan, I'm not a coder so sorry if this sounds too newbie: I don't know anything about adding to the database and running various checks, and using a different method than vB to flag mesgs as "read" or "not read", and whether your method is or is not creating a performance problem. All I know is I don't like the way vB does it currently; I find it too inaccurate. If your method works great, I would like to hear more. If the hack is something substantial yet it performs flawlessly (or at least much much much better than vB's system), then I would want to buy your hack, and so would many other people I am sure, if you pulled it into a relase with documentation etc. Maybe it would be worth your while if peole paid for copuies of this hack. But I being non tech have no means to validate that your system works great. Maybe you can provide further details in a use-case scenario. as in:



I'll consider it ;)



"Person A comes to the board via an email notification URL.... then leaves after checking that one message" (results in these kinds of flag triggers..; better than vB's method because of "x")


Basically, the first visit to the board the system looks to see if the users has a record or records in the Mark Read table. The mark read table has three columns: forumid, userid and readtime. If the forumid is 0, that equates when the user marked all messages read on the boards. So if they click in, read a message and don't mark anything read, then when they come back everything is just the same as when they left it, in regards to new message tags.


"Person B comes to board board via an email notification URL and stays, surfing through various threads on various forums" (results in these kinds of flag triggers..; better than vB's method because of "x")


If they are surfing through without marking anything read (forums in this case) then nothing changes. If they read all messages in a forum and mark it read, then that forum will be marked read, but the rest of the forums won't. When they visit again, only messages since they marked read in that particular forum will be shown as New.


"Person C comes to board directly and starts reading "new" messages" ... etc. (results in these kinds of flag triggers..; better than vB's method because of "x")


If they click on "show new messages," my altered search for new messages looks at when they last marked EVERYTHING read, and when they marked only certain forums read, and gets anything new using those two variables. Not an easy thing to figure out :) but it works. I also put in the "New Messages in this Forum" hack, so they can use that as well. As they go through and read, users can mark individual forums read. If they can't finish, they just close the browser and come back and pick up where they left off.


If I understood the mechanics of what you were doing, then I could better detremine if such a system would work better for me.

---
Also: I read thoroughly this thread a few nights ago after finding it in search. It had been a dead issue since March. Though vB may decide they have an interest in your solution (best case scenario), it would still be monthas and months away before it might find its way into a release. Therefore, if it is demonstrably a better and more accurate system, I would be willing to pay for a well-documented hack. Thank you.

Its been in use on Murmurs.com since May 20th about. Thats around 100,000 messages ago, and 3000 users ago. It took me two weeks to program and fully debug the hack.

[theflow]

Very helpful, ethan, thank you. If I understand correctly, in order to exploit the value of your system, one has to actively mark messages read or forum read.

Therein lies a big problem for me. (you may say: you can't have your cake and eat it too; and that would be true...) I don't want to have to mark anything as read. I want the system to mark it for me when I have clicked a thread. Then I want to know, the next time I arrive, if there have been new messages to that thread. Maybe other users will train themslevs to mark "messages read". But I would not want to bother with that. Ever. (even if it gives me the advantage you provide). It's one click too many, even if a minor added click.

So, if I understand correctly, your system requires users to actively denote "I have read this". On the other hand, vB's system uses cookies and timeouts to make some assumptions "I am guessing you read all those other messages too since you were here, so next time I will mark them as 'read' "

I know it's a tradeoff. And I tried to follow this whole thread and the intricacies of "too many db queries" which would be necessary to make the vB system more accurate. For me, I want the system to do the work for me and be accurate about it. I don't want to ever have to be redundant -- i.e., I not only click to read a thread, but then I also have to separately click to SAY "I've read the thread". I want the system to track that I've read it by my having clicked it at x time of day on this date. Then I want the system to tell me on my next visit that there have been new messages added since my last visit. If I never visited more than 1 thread on the prior visit, I don't want the system presuming I did. I'm guessing -- after following this whole discussion -- that what I want is technically possible but places too many db queries into the equation, thus making it impractical. ???

[ethank]

Originally posted by theflow
Very helpful, ethan, thank you. If I understand correctly, in order to exploit the value of your system, one has to actively mark messages read or forum read.

Therein lies a big problem for me. (you may say: you can't have your cake and eat it too; and that would be true...) I don't want to have to mark anything as read. I want the system to mark it for me when I have clicked a thread. Then I want to know, the next time I arrive, if there have been new messages to that thread. Maybe other users will train themslevs to mark "messages read". But I would not want to bother with that. Ever. (even if it gives me the advantage you provide). It's one click too many, even if a minor added click.

So, if I understand correctly, your system requires users to actively denote "I have read this". On the other hand, vB's system uses cookies and timeouts to make some assumptions "I am guessing you read all those other messages too since you were here, so next time I will mark them as 'read' "

I know it's a tradeoff. And I tried to follow this whole thread and the intricacies of "too many db queries" which would be necessary to make the vB system more accurate. For me, I want the system to do the work for me and be accurate about it. I don't want to ever have to be redundant -- i.e., I not only click to read a thread, but then I also have to separately click to SAY "I've read the thread". I want the system to track that I've read it by my having clicked it at x time of day on this date. Then I want the system to tell me on my next visit that there have been new messages added since my last visit. If I never visited more than 1 thread on the prior visit, I don't want the system presuming I did. I'm guessing -- after following this whole discussion -- that what I want is technically possible but places too many db queries into the equation, thus making it impractical. ???

Automatically marking threads as read would be performance prohibitive, plus I don't think users would like it. The way I do it, they just mark forums as read when they finish them, which works well for most.

What you are asking is technically possible, but say with our boards currently have 3000 members and 7739 threads, if each member was to have each thread tracked, thats 23217000 records, plus to display a forum, its 50 queries as it goes down. Just isn't technically advised. Plus, I can't assume that because they clicked on a thread they read it. The way I did it, its at their leisure to say "I've read all the things in this forum."

Right now our markread table has around 4000 rows in it, which is managable.

Ethan

[edward]

Originally posted by tubedogg
If any of you have any suggestions as to how to implement this (and make it resource-friendly) we're all ears. The problem is that for larger boards, and even some smaller boards, the amount of data stored would be astronomical. We just can't justify adding a feature that would generate a table with data such as the following:
200 members
1000 threads
200*1000 = 200,000
So for 200 members (a small board) you have a table with 200,000 rows. Not good.

If anyone has any suggestion as to how we could implement this in an alternative way, as I said we'd be more than happy to hear from you.


Jumping back into this after many months away....

Aren't those numbers a worst case scenario? Why would you preallocate a record for each member for every thread? It assumes that every user will read every thread that exists. On the VBulletin system I frequent, I don't necessarily read every thread that comes up. Others don't because they're not interested in Gaming, or Cooking, or whatever.

The ability to restrict the visible forums with the usercp makes it quite possible that one only reads a small portion of a potentially much larger board. Of the forums on this site, for example, perhaps I'm only interested in Announcements, their discussions, and bug reports. Allocating database space for my user with regard to the code hacks section is entirely wasteful, since it's highly unlikely that I'll visit there.

Can something be done dynamically? When someone views a thread, create a record that records threadid and postnumber. Update postnumber as they go forward through a thread. I guess this would require a separate table for each user. Is that a problem? What is the system impact of adding potentially thousands of tables as the userbase grows? OS limits on file descriptors? That would be an issue with sites that had large concurrent user numbers.

By keying on the user's viewing history, the 200 member system above could have substantially less than 200,000 rows of database data, unless every user read every post. Wouldn't it be at most 200 tables with no more than 1000 rows each?

What am I still not understanding about this?

[Martz]

Ezboard is capable of doing this, and its another "feature" Ezboard users miss when they move over. Of course the pros outweigh the cons, but if Ezboard can do it with 1000's of forums, subforums and users - why can't my little vB?

However, the vB icons state that these are new posts within a specified time scale, not read or unread posts. There is a difference. Whats the point of the "Mark this forum read" link, if 15 mins after you leave its going to be marked read anyway? Its only good if you spend less than 15 mins writting a reply (this one has taken me nearly 30 mins as I have had several phone calls, and I haven't finished reading the forums)

Just my 0.02. I think Me2Be's attitude of "Well my users don't complain, in fact they love it - so it can't be a problem" isn't the greatest. No offense. :)

[tubedogg]

Um...ezBoard is also hosted on something like a few hundred servers and probably uses Oracle or some custom built database for a backend. If we used that it would be no problem either. :)

[ethank]

A persistent (meaning, using a database) mark forum read hack is over on vbulletin.org. I'm putting up the 2.2 version today. Similar functionality to EZBoard.

Ethan

[Fusion]

ethank, have you, or anyone, run any performance tests on such a hack? I'm not a regged user, I'm sort of still considering vB, but I'm curious. From using this and other vB boards, I tend to agree this cookie-based marked_read system leaves something to be desired, but if the hack can make a big/heavily used board turn into a centipede, well, what's the lesser evil. :)

[Freddie Bingham]

If you want expected performance you simply need to visit a forum with the hack installed and add &explain=1. If that number varies more than just a bit from the default vBulletin output than you could have performance problems.

[Fusion]

Thanks, freddie.

[ethank]

Originally posted by Fusion
Thanks, freddie.

We have 2000-3000 messages a day, between 70-250 online at any given time, total of 4600 users and no speed issues.

Hardware:

MySQL box: dual pentium II 500mhz, 1 gig of RAM
Apache server: Dual Pentium III 750, 768 of RAM

http://tony.murmurs.com/index.php?explain=1

We are also using APC Cache.

Ethan

[tubedogg]

You also have 377 queries on the front page alone. 25 seconds is a long time for a server to take loading a page (vBulletin's default page takes less than .5 seconds to load).

[ethank]

Originally posted by tubedogg
You also have 350 queries on the front page alone.

Yeah, well, what'ya going to do :)

I could probably cut that down a bit by smoothing queries out for the sub-forums display (only doing one and using an associative array) as well as doing the queries differently for the mark-read hack.

It certainly is more resource intensive than the cookie method, but vBulletin's use would have been an impossibility without it.

Honestly, I don't know how the cookie method can be defended outside speed concerns. Its just so counter intuitive.

Also the page does not take 25 seconds to load. Explain does. If you go to the forum home its quick.

Ethan

[ethank]

I added execution timing code to my index page, the number is placed at the bottom of it. Averages about 1.2 seconds for executing my homepage. Hardly 25 seconds.

Ethan