Changing the "Thread/Forum Read Marking Type" in vBulletin to database

[photomek]

Hi,

how about switching the "Thread/Forum Read Marking Type" in vBulletin to database, Option 3. You get a precise marking, which posts/threads/forums you already have read and which not, although this needs a bit more processor/database resources.

Right now all the unread posts and threads gets marked as read after a visit to the forums later on. So this modification would be great to see, I think. Thanks!

Thread/Forum Read Marking Type

This option controls how threads and forums are marked as read. The options are:

1) Inactivity/Cookie Based - once a user has been inactive for a certain amount of time (the value of the cookie timeout option) all threads and forums are considered read. Individual threads are marked as read within a session via cookies. This option is how all versions of vBulletin before 3.5 functioned.
2) Database (no automatic forum marking) - this option uses the database to store thread and forum read times. This allows accurate read markers to be kept indefinitely. However, in order for a forum to be marked read when all threads are read, the user must view the list of threads for that forum. This option is more space and processor intensive than inactivity-based marking.
3) Database (automatic forum marking) - this option is the same as a previous option, but forums are automatically marked as read when the last new thread is read. This is the most usable option for end users, but most processor intensive.

Manual: https://www.vbulletin.com/docs/html/..._group_general

[arn]

Originally Posted by photomek

Hi,

how about switching the "Thread/Forum Read Marking Type" in vBulletin to database, Option 3. You get a precise marking, which posts/threads/forums you already have read and which not, although this needs a bit more processor/database resources.

Right now all the unread posts and threads gets marked as read after a visit to the forums later on. So this modification would be great to see, I think. Thanks!

Manual: https://www.vbulletin.com/docs/html/..._group_general

Thanks for doing the research on this. It's something we can try. I think back when we started, we were always behind the performance curve on our hardware, but we should be comfortable now, so we may be able to handle this.

arn

[theSeb]

It would be a handy feature. I support this.