If it's a multi-page thread you get sent to the first page instead of the last which has your post on it: the purpose of the 'go to thread' link that appears after you've posted is, presumably, so you can give your post a quick check. So it should send you to the last page in a thread.

Viewing the thread you just posted to doesn't update whatever system determins if there are unread posts in a thread. So even though you've just read your recent post, going back to the main forum page gives you the closed envelope symbol and your name as last post.

Slight issues, but annoying none-the-less. Any chance of a fix?

Can they both be updated immediately?

If it's a multi-page thread you get sent to the first page instead of the last which has your post on it: the purpose of the 'go to thread' link that appears after you've posted is, presumably, so you can give your post a quick check. So it should send you to the last page in a thread.

Rich requested this feature when I introduced the multi-page threads. It's quite trivial to do so I'll make sure it appears in the next version.

Viewing the thread you just posted to doesn't update whatever system determins if there are unread posts in a thread. So even though you've just read your recent post, going back to the main forum page gives you the closed envelope symbol and your name as last post.

This is delibrate. If you took 10 minutes to read/reply to a thread, then returned to the index, if the read/unread envelopes were reset you wouldn't know about any messages that had been posted while you were reading.

Why not timestamp each update to a thread and tag each user with the timestamp they last loaded.
So if you create a post in thread 'bob' at 00:00:01, and view it at 00:00:02 for ten minutes the system tags "user: bob00:00:01" to your info.
If someone else creates a post in thread 'bob' at 00:00:03 the system tags the thread "thread: bob00:00:03". So you then return to the main forum page at 00:10:02 and it will detect that the thread has a new post in it since you last visited.

Hmmm, can't it actually track what posts each user has actually read? From your description the system seems to work on a thread basis, telling you if a thread has been updated (ie. not specifically if a new post has been added).

Why not timestamp each update to a thread and tag each user with the timestamp they last loaded.
So if you create a post in thread 'bob' at 00:00:01, and view it at 00:00:02 for ten minutes the system tags "user: bob00:00:01" to your info.
If someone else creates a post in thread 'bob' at 00:00:03 the system tags the thread "thread: bob00:00:03". So you then return to the main forum page at 00:10:02 and it will detect that the thread has a new post in it since you last visited.

If I'm understanging this correctly I'm not so sure this would be a good idea for a forum. Maybe it's ok. for forums like Iconbar and Acorn Arcade that don't have much traffic but once you've got a forum that has a few hundred messages a day in many threads you'll never be able to read all of them and probably not interested to anyway. If you were required to enter all threads to update your last read timestamp you'd end up with hundreds and hundreds of unread threads that you were in no way interested in and would very soon give up on using that forum.

If you were required to enter all threads to update your last read timestamp you'd end up with hundreds and hundreds of unread threads that you were in no way interested in and would very soon give up on using that forum.

Wah? The purpose of an unread/read indicator is to tell you if you've read posts in a thread or not. It doesn't matter what size the forum is. All I'm asking for is that the indicator be accurate.

[Edited by senduran at 09:25, 21/3/2001]

The read/unread envelopes are calculated by comparing the 'last post' timestamp to the cookie, so if you post a reply to the 'bob' thread at 00:00:01 and then someone else posts a reply, when you return to the forum index the unread message will be displayed.

Yes, that sounds good.

The problem you talked about in the original post is that if you post a reply to a thread and then return to the forum index, the unread envelope is displayed. Unfortunately I can't see an easy way to get around this problem without having to store the dates of 10 or so last posts to a forum, so that when the unread/read envelopes are calculated, if the last post was by you then the system looks at the previous last post.

No, _my_ problem is with posting to a thread AND THEN VIEWING the thread immediately after.
My proposed system, and the system as you describe it, should result in a 'read' status on that thread when you subsequently visit the main forum page (unless, of course, someone else posted while you were reading the thread).

Why doesn't it?

[Edited by senduran at 17:28, 20/3/2001]

_my_ problem is with posting to a thread AND THEN VIEWING the thread immediately after.
My proposed system, and the system as you describe it, should result in a 'read' status on that thread when you subsequently visit the main forum page

I've just realised we may be talking about different things: By 'main forum page' do you mean viewforum.php3 or index.php3 ? I'm assuming you mean index.php3.

(unless, of course, someone else posted while you were reading the thread).

Why doesn't it?

Because when you go to the main forum index from any other forum page, you're going to index.php3?serve=cached, which doesn't update the cookie timestamp.

Otherwise, if you came to the forums, viewed the general forum, then went back to the index; the cookie timestamp would be updated and all the other forums would appear as read unless a message had been posted to them in the time that it took you to read the General forum.

Right, so why do other forum pages send you to the cached page? That's certainly the issue at hand. Why are you caching a page that people will always want to see the latest version of?

And very importanly, fyi, what you say about going back to the index is NOT TRUE. At least with IE, going back to the index or any other page on the site, then clicking the 'Forums' link (IE tells me it's a link to 'index.php3') will load in index.php3?serve=cached. You have to leave the site completely and _then_ return to get plain index.php3.

If you were required to enter all threads to update your last read timestamp you'd end up with hundreds and hundreds of unread threads that you were in no way interested in and would very soon give up on using that forum.

Wah? The purpose of an unread/read indicator is to tell you if you've read posts in a thread or not. It doesn't matter what size the forum is. All I'm asking for is that the indicator be accurate.\[\/quote\]

But IconBar is currently using the 'new posts since last visit' indicator which is in most cases a better option but I do understand your point of view.

The index page being cached? By what? The users browser? And the solution is to send the user to a cached page? Ok, you're totally loosing me on this one. Regardless, I'd have thought that the index page was constructed on the fly with php, so all that gets cached is the basic outline of the page. Is that not the case?

Right... so the problem is that the cookie timestamp is too simplistic. My suggestion was for a user timestamp for each thread. That would solve the problem, yes?

The index page being cached? By what? The users browser? And the solution is to send the user to a cached page? Ok, you're totally loosing me on this one. Regardless, I'd have thought that the index page was constructed on the fly with php, so all that gets cached is the basic outline of the page. Is that not the case?

The index page you first go to sets a cookie for the time of your visit; you don't want this done again until the program is ready to update that time stamp. So, when you just want to go back to a list of items you're sent to a version being called "cached" to avoid resetting the cookie. It doesn't really matter what's doing the caching, just the effect - the browser may or may not cache, but the PHP-generated page knows what to do with the request.

Right... so the problem is that the cookie timestamp is too simplistic. My suggestion was for a user timestamp for each thread.

Yes, unless you had an enourmouse number of threads - cookie data is finite.

Yup, and when you start getting 1,000 threads... 10,000 threads... it'll start getting a bit ridiculous.

The index page being cached? By what? The users browser? And the solution is to send the user to a cached page? Ok, you're totally loosing me on this one. Regardless, I'd have thought that the index page was constructed on the fly with php

It is generated on the fly. All the 'cached' parameter does it tell the PHP script not to alter the 'last visit' timestamp/cookie for reasons already mentioned.

From your description the system seems to work on a thread basis, telling you if a thread has been updated (ie. not specifically if a new post has been added).

Isn't it the same thing?

Why not timestamp each update to a thread and tag each user with the timestamp they last loaded.
So if you create a post in thread 'bob' at 00:00:01, and view it at 00:00:02 for ten minutes the system tags "user: bob00:00:01" to your info.
If someone else creates a post in thread 'bob' at 00:00:03 the system tags the thread "thread: bob00:00:03". So you then return to the main forum page at 00:10:02 and it will detect that the thread has a new post in it since you last visited.

I'm not completely clear what you're suggesting, but it sounds like the system that's already in place.

Basically, when you visit index.php3 (without the ?serve=cached bit on the end), a timestamp is written to your file, and a cookie is sent containing the previous timestamp that was in the file.

Each thread has a 'last post' timestamp, which is updated everytime someone posts a new reply.

The read/unread envelopes are calculated by comparing the 'last post' timestamp to the cookie, so if you post a reply to the 'bob' thread at 00:00:01 and then someone else posts a reply, when you return to the forum index the unread message will be displayed.

The problem you talked about in the original post is that if you post a reply to a thread and then return to the forum index, the unread envelope is displayed. Unfortunately I can't see an easy way to get around this problem without having to store the dates of 10 or so last posts to a forum, so that when the unread/read envelopes are calculated, if the last post was by you then the system looks at the previous last post.

I'm not sure if that made any sense...

Well I've no idea how to access viewforum.php3

viewforum.php3 is the page you go to when you click on one of the links from index.php3, e.g.
the Site comments forum.

so why do other forum pages send you to the cached page?

I've already explained that : Otherwise, if you came to the forums, viewed the general forum, then went back to the index; the cookie timestamp would be updated and all the other forums would appear as read unless a message had been posted to them in the time that it took you to read the General forum.

And very importanly, fyi, what you say about going back to the index is NOT TRUE. At least with IE, going back to the index or any other page on the site, then clicking the 'Forums' link (IE tells me it's a link to 'index.php3') will load in index.php3?serve=cached.

Yes, that's because when you go to index.php3 whilst logged in, the timestamp will be written to your file, the cookie will be sent; and then you are redirected to index.php3?serve=cached. That's a nasty (but necessary) hack included to get around the problem of the index page being cached.

So in this situation it sent me to the wrong page.

Not quite dream like then, but pretty close