Jump to content

best way to remember "read topics" for a forum script


scarhand

Recommended Posts

im making a simple forum

 

i want it to remember what topics the member has and has not read

 

i was thinking of having a mysql table called read_topics (memberid, topicid). whenever a topic is visited a row could be inserted into the database, when a new reply is made all rows with that topic id could be removed. but it seems like this could be intense with a large amount of members and topics

 

then i thought of using cookies instead, but i dont really know how i would go about doing this. i was thinking maybe have a cookie for each topic whose value is the number of replies. set the cookie when they read the topic. if the topic has more replies than the cookie variable, then it would show as unread.

 

anyone have any better ideas?

The normal way of doing this is to use a "last visit" date/time, stored in the visitor's row in the user table, that serves as a bookmark of what has been read or not read.

 

On each new visit/page refresh, the id of posts that are newer than the "last visit" bookmark are added to a table of unread posts, keyed with the current visitor's id. The "last visit" bookmark is then set to the latest date/time of the posts that were just added to the table.

 

As the posts are read by that visitor, his row for that post is removed from the table. If he marks any post as unread, its id/visitor's id gets added to the table. If he clicks on a "mark all posts as read" link, all his rows in the table are removed. If he clicks on a "show unread posts since last visit" posts later than his "last visit" bookmark date/time are added to the table and the bookmark is set to the highest data/time of the posts just added to the table.

 

You could download and examine how SMF (the script this forum uses) does this to get more detail.

wouldn't it be easier to just use my cookies idea? i mean what you said doesn't sound very accurate. it seems like this will mark posts as read even if they have not actually visited the thread.

 

is there a problem with setting thousands of cookie variables?

is there a problem with setting thousands of cookie variables?

 

Yes. There is both a limit on the number of cookies per site and on the size of each cookie.

 

And any method that remembers all the posts that have been read is unworkable long term because of the constantly increasing storage it requires. Do you really think this forum stores 761,348 Posts X 75,788 Members worth of "read" post data?

 

The method I described is how all the major forum software does this.

The normal way of doing this is to use a "last visit" date/time, stored in the visitor's row in the user table, that serves as a bookmark of what has been read or not read.

 

On each new visit/page refresh, the id of posts that are newer than the "last visit" bookmark are added to a table of unread posts, keyed with the current visitor's id. The "last visit" bookmark is then set to the latest date/time of the posts that were just added to the table.

 

As the posts are read by that visitor, his row for that post is removed from the table. If he marks any post as unread, its id/visitor's id gets added to the table. If he clicks on a "mark all posts as read" link, all his rows in the table are removed. If he clicks on a "show unread posts since last visit" posts later than his "last visit" bookmark date/time are added to the table and the bookmark is set to the highest data/time of the posts just added to the table.

 

You could download and examine how SMF (the script this forum uses) does this to get more detail.

 

can someone explain this to me in different terms? i found this very confusing

 

let me get this straight:

 

last visit time in user table reflecting last time he left site

newer threads added to unread threads table with user id

last visit time updated to current time

when thread is visited, row is removed from unread threads table

when "mark all as read", all threads are removed from table etc

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.