I wasn't going to commit the fix you posted - from testing on our Intranet forums on our network we've come up with a way to fix #1 and #2 frostschutz mentioned (to me, the important ones - not sure what to do with others yet) in the first post.
(2008-11-10, 01:52 AM)frostschutz Wrote: [ -> ]1) Parent forum gets marked as 'unread' even though there is nothing new in it.
2) Parent forum is marked as 'read' even though there is a subforum with unread postings in it.
Proof of concept:
http://resources.xekko.co.uk/ - you can login as developer or developer2 with the password test123 to test it out. Make a post in the subforum then login as the other user to see the unread posts and test to your heart's content. That's hosted on a busy, crappy, shared server and there's no performance issues. In fact, it seems a little quicker when you compare the micro seconds.
As you've told me before, not to mark a bug as fixed unless I was 100% sure I could fix it. We've been testing this for over a month now, and we have subforums 6 or 7 deep, and haven't noticed anything out of the ordinary. The test on Resources shows that it's capable on a crappy server, instead of our decent one.
Of course, feel free to move this back if you think I'm wrong.
Alright, I'd like to see the fix before it gets commit - The only solutions that I've ever come up with involve much more intensive queries that could bring down a forum like ncaabbs.
Ahh... I never thought of it like that. Took a, "as long as it worked OK" sort of approach...
I don't quite have access to the exact code we're using, but it's something along the lines of this. In showthread.php:
$query = $db->simple_select("forums", "parentlist", "fid = '".$fid."'");
$parents = explode(",", $db->fetch_field($query, "parentlist"));
$forum_unread = fetch_unread_count($fid);
// If there are no unread threads in this forum, then update the parents
if($forum_unread == 0)
{
foreach($parents as $parent)
{
// Have we read all the parents? If so, then mark them as read
$unread_count = fetch_unread_count($parent);
if($unread_count == 0)
{
mark_forum_read($parent);
}
}
}
As said, I didn't quite see it from the ncaabbs view, but it works well on our cheap £300 base unit we're using as a server(!). I guess then it's more of a workaround than a fix...
Yeah, see, that is not a good fix at all. That will most definitely crash ncaabbs. Imagine how many times that will loop for a deep forum and then multiply that by the amount of visitors visiting showthread.php - That would easily double the load on the server.
(2009-06-25, 06:43 PM)Tomm M Wrote: [ -> ]Took a, "as long as it worked OK" sort of approach...
You should never use that methodology :\ Everything needs to scale well in MyBB
It doesn't work.
(In your proof of concept forum, mark all forums read, then post in subforum A, then on the redirect page click on 'return to forum', your post is read, go to main index, forum shows up as unread).
Your workaround is very aggressive; if you pursue this line of thought you will most likely end up marking too much as read. It doesn't actually fix or touch the issue (the issue being lastpost and forumsread compared in build_forumbits when those two pieces of information are actually unrelated, e.g. it's done regardless of wether the lastpost was read or not). At best it will only hide it.
My patches (and discontinued Subforum Bulb plugin) were aimed to modify build_forumbits to actually respect the individual read/unread status of each forum, and (the plugin) even went as far as pulling more features out of it (such as displaying both parent and subforum read status in one combined icon, like phpBB does), without adding (much) cost; I still believe this to be the more worthwhile approach, and it fixed the issue your workaround tries to fix more thoroughly.
(2009-06-25, 08:03 PM)Ryan Gordon Wrote: [ -> ]Imagine how many times that will loop for a deep forum and then multiply that by the amount of visitors visiting showthread.php - That would easily double the load on the server.
Like I said, it's well tested. We've tried it on a base unit, and on an I7-core virtual that runs our entire company. We have 11 (not 6, or 7), subforums and it works without implication on the base unit. I'd say thats pretty good, but I'm probably wrong as usual.
(2009-06-25, 08:04 PM)frostschutz Wrote: [ -> ]It doesn't work.
(In your proof of concept forum, mark all forums read, then post in subforum A, then on the redirect page click on 'return to forum', your post is read, go to main index, forum shows up as unread).
Your workaround is very aggressive; if you pursue this line of thought you will most likely end up marking too much as read.
It's a proof of concept, not a fix for this bug. It's not applied to all the areas that are likely to affect to a live forum (that's why the thread finds a "bug" in the quick reply, and why I thought it was best for 1.6 so it could be tested fully). There's a patch to forumdisplay too - but as I can't access it, I can't post the code or update Resources, it really was my best guess at what we came up with. The guy who controls the base unit is on holiday at the moment.
It's aggressive, but it won't mark "too much" as being read. There's nothing untoward to say that it occurs and as Ryan points out, will probably take a rewrite for it to be fully fixed - whether your "patches" or plugin modifications respect anything.
Just screw it. We'll stick to what we've got. An entire 6 weeks of testing and no problems whatsoever obviously works for us but not anybody else. No doubt the 2.0 rewrite will fix it - 1.4 and 1.6 won't fix this issue anyway.
(2009-06-26, 02:18 AM)Tomm M Wrote: [ -> ]Just screw it.
Move this off to bogus then. This thread is not very useful anyway, since everyone seems to have a different idea of when a forum should be marked unread due to a subforum. I believe in my line of thinking, you believe in yours, Ryan believes in his... so this isn't going anywhere except round in circles.
(2009-06-26, 02:18 AM)Tomm M Wrote: [ -> ]No doubt the 2.0 rewrite will fix it
Right. I'll keep my fingers crossed. Hope dies last after all.
I think this is important so No its not bogus .. why do we want repeat looking over the forums that we have read but it doesnt show that they have been read ... sorry I personally think we should not be heading towards not repairing something that needs to be fixxed then just over looking something ...
unless this has been fixxed in 1.4.8
I just started experiencing this issue in 1.4.8. Never saw it before that. I hope a proper solution can be made for the issue.
(2009-06-27, 09:10 PM)John Briggs Wrote: [ -> ]I just started experiencing this issue in 1.4.8. Never saw it before that. I hope a proper solution can be made for the issue.
No changes were made in 1.4.8 that relate to this issue.