mark as read hack

[Doom9]

I recently moved from ezboard to vbb. One of the features my moderators (and some other users, too) really missed was the ability to mark certain forums as read manually as in vbb that only works globally and after your cookie times out everything is marked read so you may miss posts.

Attached are the diff files and a description on how the hack works. Registered users can now manually mark forums as read and the forums are marked as read by what the user read and marked as read rather than by timeout. For unregistered readers the behaviour remains the same as before.

Anyways.. feel free to make comments about our implementation (I didn't write it.. hopefully you'll let the author comment even though he has no vbb license himself)

We've tested the hack a bit.. seems to be working just fine but so far we haven't implemented it into the "production" forum.. and we'd love to get some feedback by the community. We're also hoping that jelsoft might consider including the hack or a modification thereof in a future version.

[paulsjv]

i've been looking for this and finally! :D i'll try and install it sometime tomorrow if i have the time.. and let you know how it works...

[ethank]

Looks similar to mine. I did figure out the search issue though. I posted instructions for the markread implementation I've been using in the Releases forum. Its still preliminary, but if someone can walk through it (if you have time) and report any problems I can hopefully get it to release status quickly.

Ethan

[Tommy Boy]

Having this feature will determine whether I buy vBulletin or not. I don't mind if it's built-in or hacked, as long as it works. If it's a hack, it should be compatible with 2.0.4, when it is released.

Since I don't have a license yet, I can't test either of your hacks. Therefore, I'd like to hear some feedback from people who implemented it.

Thank you both Ethan and doom9 for your excellent work! :D

[ethank]

It was a defining factor for me as well, but I just programmed it in. Its modeled after the behavior of Webboard's mark read. At http://tony.murmurs.com you can test out its behavior. Its been in use since May with no problems what-so-ever, with about 1500-3000 messages per day.

Its not that many code additions (as I found last night when documenting it) and someone besides me walked through my instructions without incident, so....

Ethan

[guillep2k]

Ethank... I've been looking your code, and what I didn't like mostly is that it lacks a timestamp feature, as in ezboard. It sets the time of the read mark to the moment of the action, rather than to the moment of the forum-list display, which is more accurate, as one can make posts after the thread list is displayed (with your code one can still loose some posts!). The SQL code isn't very much optimized too... it performs too many SQL accesses per page (look at this post's code: it performs only one). Please don't take me wrong; I'm thankful you had the guts to simply put the hands into work and do it (and share it!), but consider giving this other code a try and give me your oppinions about it. Particularly, there are two things I didn't work out, as follows:

"View new posts"

How do you think the "view new posts" link in index.php should be modified? As the board will only have the read mark for those forums explicitly marked as read by the user, I don't think that info is really usefull to this function... or is it? For the moment, it is ruled by the original vB behavior, using the "last visit" time in the cookie. My real concern is about what date should the forum use to consider a post as "new". At the moment, the cookie time is used. Should it use the MaR (mark as read) date for each forum instead? What about forums never marked as read?

Parent and child forums

Imagine forum "third" is child of forum "second". When a post is made to the "third" forum, vB updates the "lastpost" information in both, the "third" and the "second" forums, as the "third" is child of the "second". The problem comes when one marks the "third" forum as read, because the second forum remains as "unread", even if there are no posts. I'll give you an example:

Initial
2nd forum marked read at 10:00 AM
3rd forum marked read at 10:15 AM

Then:
new post to 3rd forum at 11:00 AM,
3rd forum last post is set to 11:00 AM,
2nd forum last post is set to 11:00 AM (parent of 3rd)

Later:
User marks 3rd forum read at 11:33 AM,
but! 2nd forum remains unread after 10:15 AM, then appearing unread even when having no new posts.

The options:
1) Leave it "as is", because this is the vB normal behavior.
2) Change vB behavior, so the parent forums do not count posts made to their childs.
3) Change the "mark as read" behavior, to mark as read every parent of a given forum (doesn't make much sense, as it is not necessarily true).

I look forward for reading your feedback.

Guille

[ethank]

Originally posted by guillep2k
Ethank... I've been looking your code, and what I didn't like mostly is that it lacks a timestamp feature, as in ezboard. It sets the time of the read mark to the moment of the action, rather than to the moment of the forum-list display, which is more accurate, as one can make posts after the thread list is displayed (with your code one can still loose some posts!). The SQL code isn't very much optimized too... it performs too many SQL accesses per page (look at this post's code: it performs only one). Please don't take me wrong; I'm thankful you had the guts to simply put the hands into work and do it (and share it!), but consider giving this other code a try and give me your oppinions about it. Particularly, there are two things I didn't work out, as follows:


Timestamp issue: I get what your saying and its a simple modification. Actually a very useful one :) I didn't know thats how EZBoard worked.

About SQL queries: Well, yeah, I could do it differently and do one query per page and use an array, but I just haven't had time to go through and recode. Never said it was perfect! Just that it works and has for a half a year now. The timestamp is based on when they click the link, not when they read the forum.

I'll take a look at your code and see how it works. There are many ways to add this feature, I just did it the only way I knew how considering my lack of PHP knowledge at the time.

Do you have a live site where I can test your implementation out?

Just looking at your code, the way you do marking all forums read might cause more queries than necessary and a bigger table than necessary. I just make it so it adds a record with forumid 0 with the mark all read time. That means that when I do a select on a userid from the markread table, I'll get the forumid 0 time (when they marked all read) and times when they marked individual forums read after. When you mark all read, it clears individual forum timestamps out for that user. This makes it MUCH easier to do the New Post search.

Minus these differences, and some minor implementation stuff (new templates, etc), our code is pretty much the same.


"View new posts"

How do you think the "view new posts" link in index.php should be modified? As the board will only have the read mark for those forums explicitly marked as read by the user, I don't think that info is really usefull to this function... or is it? For the moment, it is ruled by the original vB behavior, using the "last visit" time in the cookie. My real concern is about what date should the forum use to consider a post as "new". At the moment, the cookie time is used. Should it use the MaR (mark as read) date for each forum
instead? What about forums never marked as read?


The way I did it is that it looks at which forums were marked initially as read and goes by that time, and for those that were not marked as read, goes by the last time they marked the entire board as read (forumiid = 0 in my case).


Parent and child forums

Imagine forum "third" is child of forum "second". When a post is made to the "third" forum, vB updates the "lastpost" information in both, the "third" and the "second" forums, as the "third" is child of the "second". The problem comes when one marks the "third" forum as read, because the second forum remains as "unread", even if there are no posts. I'll give you an example:

Initial
2nd forum marked read at 10:00 AM
3rd forum marked read at 10:15 AM

Then:
new post to 3rd forum at 11:00 AM,
3rd forum last post is set to 11:00 AM,
2nd forum last post is set to 11:00 AM (parent of 3rd)

Later:
User marks 3rd forum read at 11:33 AM,
but! 2nd forum remains unread after 10:15 AM, then appearing unread even when having no new posts.

The options:
1) Leave it "as is", because this is the vB normal behavior.
2) Change vB behavior, so the parent forums do not count posts made to their childs.
3) Change the "mark as read" behavior, to mark as read every parent of a given forum (doesn't make much sense, as it is not necessarily true).


The query for the lightbulb (the on/off) in my code looks in the child forums to see if there were any posts after markread time. If there were, the lightbulb is on for the parent. The lightbulb goes off if all child forums and the parent have no new messages in them.

[guillep2k]

Hi! Glad you wrote back!

Just looking at your code, the way you do marking all forums read might cause more queries than necessary and a bigger table than necessary.

Well, actually I disagree... I do a single query, but with several rows of results, which is very much performant than making two queries with a single row result each (that's because of processes' context switching, which is expensive). It's true that inserting a single row is space saving, but the fact of using "replace" instead of "delete" and "insert" gives a better performance for the following reasons:
1) Once the row is somewhere in the table, it won't move. Table doesn't get disorganized, no need to move or clean up blocks, etc. This is precious when talking about DB performance.
2) There are no index updates. Index updates usually take longer than table's.
Take into account that a 5,000 user board with 40 forums (and all of the users using the mark as read feature), makes a 200,000 rows table+index (4.1MB, I tested myself), so the table, in the worst case, will fit entirely in RAM. It is not that much info for a board with that size!
Also, organizing things like this, we minimize the complexity of the "bulb" query, which will be used 20 to 30 times the "mark forums read" query (whether it is insert, update, etc.).

The new post search is not easier or harder in either method (remember "left outer join" and "ifnull"?). I only question if it is accurate to use these times to consider if a post is new or not, because it is very likely that most posts from forums you are not interested in will show up with this (mine or yours) method.


The query for the lightbulb (the on/off) in my code looks in the child forums to see if there were any posts after markread time. If there were, the lightbulb is on for the parent. The lightbulb goes off if all child forums and the parent have no new messages in them.

You don't need to do that, as vB already does it for you in the "lastpost" column of the "forum" table.

Guille

[ethank]

Originally posted by guillep2k
Hi! Glad you wrote back!



Well, actually I disagree... I do a single query, but with several rows of results, which is very much performant than making two queries with a single row result each (that's because of processes' context switching, which is expensive). It's true that inserting a single row is space saving, but the fact of using "replace" instead of "delete" and "insert" gives a better performance for the following reasons:
1) Once the row is somewhere in the table, it won't move. Table doesn't get disorganized, no need to move or clean up blocks, etc. This is precious when talking about DB performance.
2) There are no index updates. Index updates usually take longer than table's.
Take into account that a 5,000 user board with 40 forums (and all of the users using the mark as read feature), makes a 200,000 rows table+index (4.1MB, I tested myself), so the table, in the worst case, will fit entirely in RAM. It is not that much info for a board with that size!
Also, organizing things like this, we minimize the complexity of the "bulb" query, which will be used 20 to 30 times the "mark forums read" query (whether it is insert, update, etc.).

The new post search is not easier or harder in either method (remember "left outer join" and "ifnull"?). I only question if it is accurate to use these times to consider if a post is new or not, because it is very likely that most posts from forums you are not interested in will show up with this (mine or yours) method.




You don't need to do that, as vB already does it for you in the "lastpost" column of the "forum" table.

Guille

There was a specific reason I stopped using Last Post, and now I forgot! Anyhow, I did use the Last Post column in the first version, but things broke so I changed how it worked. THere was a specific chain of user-actions that caused Last Post not to reflect an accurate time for determining read status for the lightbulb.

Anyhow, check your e-mail. If we combine the two different hacks I think we've got something to release.

EThan

[guillep2k]

The problem of the "lastpost" column is exactly what I was talking about in previous posts (what you can not remember is that when a child forum is mark as read, the parent keeps the unread status). I personally think we should change vB behavior on this matter: it should not update parent forums at all, because you may want to mark the posts at the parent level as read and not at child's. Besides, it would make much more efficient queries.

Guille

[ethank]

Originally posted by guillep2k
The problem of the "lastpost" column is exactly what I was talking about in previous posts (what you can not remember is that when a child forum is mark as read, the parent keeps the unread status). I personally think we should change vB behavior on this matter: it should not update parent forums at all, because you may want to mark the posts at the parent level as read and not at child's. Besides, it would make much more efficient queries.

Guille

Yeah, you can do it either way. Still need to query on the parent forum to see if there are any unread children forums within it though. My rather unweildy code block for "lightbulb" does that, but it can probably be compressed down to one SQL statement instead of multiple.

Ethan

[guillep2k]

I don't think the bulb should be on for the parent if any child has unread posts!!! That's because the parent and the children are all displayed in the index.php page, so you can get confused thinking that the parent itself has unread posts, which may and may not be. Or there's something I'm missing?

Guille

[guillep2k]

They aren't displayed on the main page if they are deep enough or you have it set to only show one level of depth on the homepage (as we do). I tried this behavior out and users had a fit, because they missed new posts within children conferences.
I already sent you a query that solves this in one single DB operation. Here's the copy:

select a.forumid as forumid, max(b.lastpost) as lastpost, min(ifnull(m.timestamp,0)) timestamp
from forum a
inner join forum b
on instr( concat(',',b.parentlist), concat(',',a.forumid,',') ) > 0
left outer join forumread m
on m.userid = $user and m.forumid = b.forumid
group by a.forumid;


Guille

[Zeoran]

I think it's absolutely wonderful that you two are working so hard on this project. As an Ez-board convert, I myself and the rest of my board have been dearly missing this feature. And in Q's defense, it is very important to have it timestamped properly so that it's based on the last time I refreshed my list so that I don't miss posts that were made while I was reading.

Can you guys let me know when you get this all worked out?

Thx!

~Z

[ethank]

Originally posted by Zeoran
I think it's absolutely wonderful that you two are working so hard on this project. As an Ez-board convert, I myself and the rest of my board have been dearly missing this feature. And in Q's defense, it is very important to have it timestamped properly so that it's based on the last time I refreshed my list so that I don't miss posts that were made while I was reading.

Can you guys let me know when you get this all worked out?

Thx!

~Z

I decided just to release my code as is, as when I dug through it, the integration was too cumersome. I'm adding two more features (mark read parent + children and new messages parent + children) as well as testing with 2.2

Ethan

[Zeoran]

That's great. Just let us all know when you're done. I'm sure it will be a high-demand feature/hack.

~Z

[MrLister]

too bad there's no more use for it.... vB 2.2.0 already has this.
Originally posted by Zeoran
That's great. Just let us all know when you're done. I'm sure it will be a high-demand feature/hack.

~Z

[ethank]

Originally posted by MrLister
too bad there's no more use for it.... vB 2.2.0 already has this.


Not so, this uses persistent database storage, vBulletin still uses cookies, so after the cookie expiration, everythings read.

Ethan

[SWFans.net]

I'm a suppoter of the database method that Ethank employs, and am eagerly awaiting his re-release for the 2.2.0 version, so I can go ahead with my upgrade. :)

Besides the fact that it is more reliable, to me at least, than using cookies, it also allows me to place "Mark Forum Read" links on the Forum index, and oh how I love redundancy and multiple ways to do the same thing. :)

[ethank]

Originally posted by SWFans.net
I'm a suppoter of the database method that Ethank employs, and am eagerly awaiting his re-release for the 2.2.0 version, so I can go ahead with my upgrade. :)

Besides the fact that it is more reliable, to me at least, than using cookies, it also allows me to place "Mark Forum Read" links on the Forum index, and oh how I love redundancy and multiple ways to do the same thing. :)

CHeck the other Mark Read thread later today. I'm going to reedit the first post and hopefully put a prettier version of the instructions up. Not much changed for version 2.2 really, just one template.

Ethan

[VirtueTech]

Why can't it be set so that when a user clicks on a thread it marks the thread as read by that user. It would be so much better.

Can this be done ?

[Tommy Boy]

NOOO!!! That's exactly why I like this hack so much! You see, I run a support forum, and not always have an answer at reading time. So keeping the thread unread is the only way for me to know I haven't answered it yet. Please don't ruin that...

[Zeoran]

any updates on when this hack might be available for 2.2.1?

[SirSteve]

me too... need this for 2.2.1...

[Figment]

Does this work on 2.2.2?

D'oh - just re-read the thread title!