New Posts Not Working?

[Pony99CA]

This is still happening. I see "new" posts back to January 22.

Could somebody suggest something or look at my account and see if something is messed up?

Thanks,

Steve

[MattF]

Same here. It's not just you.

[Pony99CA]

As noted in my previous post, this seems to be a cookie problem. If I delete all board cookies, the "old" posts no longer show up in the New Posts results. However, that basically just resets the date; I start seeing old posts shown as new from that date forward.

Has anybody looked into this issue yet? It's not just happening to me as VSE noted, so I wonder how many people it is affecting. I'm using IE 10 on Windows 7 if that helps.

Steve

[Khaos-Rage]

This is still happening to me too, I have 3 pages of "New Posts" that date back all the way to February. I'm using Firefox on Windows 8.1.

Edit: So logged in via IE to test this and got the same 3 pages (was still logged in via firefox). Cleared the cookies in IE and then logged back in (IE) and I had no new posts. Refreshed the page in Firefox it now shows no new posts as well.

So maybe a DB/sessions issue, couldn't really be a cookie thing because browsers don't share cookies and resetting IE shouldn't have affected Firefox?

[DavidIQ]

Looking at the way "newposts" works in search.php it looks like users.user_lastvisit is what is being used to figure out what your last visit to the site was and then produce the list. This doesn't look to have changed between 3.0 and 3.1 however and neither has the session methods/functions that update this value, which only do the updating when actually logging in, logging out, when session keys get cleared, or when sessions are "garbage collected".

Not sure if we should maybe be using "session_last_visit" instead but the current behavior is how it's been since 3.0, which doesn't mean it's the correct behavior of course. Just stating the story and the facts the code tells.

[Pony99CA]

Looking at the way "newposts" works in search.php it looks like users.user_lastvisit is what is being used to figure out what your last visit to the site was and then produce the list. This doesn't look to have changed between 3.0 and 3.1 however and neither has the session methods/functions that update this value, which only do the updating when actually logging in, logging out, when session keys get cleared, or when sessions are "garbage collected".

Not sure if we should maybe be using "session_last_visit" instead but the current behavior is how it's been since 3.0, which doesn't mean it's the correct behavior of course. Just stating the story and the facts the code tells.

I confirmed that logging out and logging back in resets the New Posts display. The problem is that it used to work differently here. Each day that I would visit only showed me topics that had new posts (sometimes if I visited twice in a day, I might see a topic with no new posts, but it was gone the next day). I had logged in with the Remember me option selected and never had to log out to see only "new" posts.

Could the session key clearing/garbage collection things have changed, thus causing the changed behavior? The other alternative is that the users.last_visit isn't being reset like it used to be.

Steve

[MattF]

Looking at the way "newposts" works in search.php it looks like users.user_lastvisit is what is being used to figure out what your last visit to the site was and then produce the list. This doesn't look to have changed between 3.0 and 3.1 however and neither has the session methods/functions that update this value, which only do the updating when actually logging in, logging out, when session keys get cleared, or when sessions are "garbage collected".

Not sure if we should maybe be using "session_last_visit" instead but the current behavior is how it's been since 3.0, which doesn't mean it's the correct behavior of course. Just stating the story and the facts the code tells.

I think it's more of an issue with the server here, not the code. For example, on .com, the new posts page behaves as expected.

This has happened here at a51 before, a couple years ago, and was resolved. It returned after a51 was brought back online again after we were down due to our infrastructure attack at the beginning of the year.