mark as read hack

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.

i've been looking for this and finally! 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

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!

[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

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.

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

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