vBulletin Upgrade

[M2]

Yes, this is an Ajax function. It's one of the best things I've noticed so far about the upgrade.

Ajax is amazing stuff. As much as you like it now, you're going to love it as you see more of the stuff it can do. Real-time, self-updating game threads are coming in the not-too-distant future. In fact, if MLB.com opens up the API for Gamecast in the next year or two we'll probably be able to grab that and run it at the top of a real-time game thread.

Anyway, the first troubleshoot with Ajax is checking the user browser. If you can use Google Maps, you can use Ajax. If not, then you'll need to update your browser.

[M2]

Can anyone else confirm if they're still having this problem (read threads appearing as unread)?

All fixed for me. Had been a problem earlier and now it's gone.

[Boss-Hog]

vB 3.5 introduced two new methods for tracking which threads have been read and which have not. Here are available options - we are currently using option #1. Let me know what you guys think:

Thread/Forum Read Marking Type

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

1). Inactivity/Cookie Based - once a user has been inactive for a certain amount of time (the value of the cookie timeout option - currently 15 minutes) 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.

[smith288]

Ajax is amazing stuff. As much as you like it now, you're going to love it as you see more of the stuff it can do. Real-time, self-updating game threads are coming in the not-too-distant future. In fact, if MLB.com opens up the API for Gamecast in the next year or two we'll probably be able to grab that and run it at the top of a real-time game thread.

Anyway, the first troubleshoot with Ajax is checking the user browser. If you can use Google Maps, you can use Ajax. If not, then you'll need to update your browser.

You said it. Ajax has so many applications that it can turn any boring normal website into an active application. Just adding a post without actually posting the page is remedial compared to its potential.

Gamethreads with an active update using ajax is making me drool!

IE7 will be putting xmlhttp into the browser rather than using activex. Should be great.

[Blimpie]

vB 3.5 introduced two new methods for tracking which threads have been read and which have not. Here are available options - we are currently using option #1. Let me know what you guys think:

Thread/Forum Read Marking Type

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

1). Inactivity/Cookie Based - once a user has been inactive for a certain amount of time (the value of the cookie timeout option - currently 15 minutes) 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.

Isn't option # 2 more like what we had available prior to this latest upgrade? If so, will: "option is more space and processor intensive than inactivity-based marking" keep this from being a feasible option?

[Boss-Hog]

No, option #1 is definitely what we used prior to the upgrade, as it was the only available option for tracking read threads prior to 3.5. The reason you may not have noticed it is because of this aspect: "Individual threads are marked as read within a session via cookies.". That's how vB marks individual threads read (within a session) before the user clicks "Mark All Forums Read" when he or she is finished. Under this system, all threads will be marked as read if a). the user clicks "Mark All Forums Read" or b). he or she does not do this and 15 minutes pass.

I think we're OK from a bandwidth standpoint that none of the options should cause any problems.

[Boss-Hog]

The following addons have been installed:

• Smilies in Quickreply
• Require Reputation Reason
• Display Given Reputation Comments
• Chat Integration
• 15 Most Recent Searches