jerry wrote:
fxstein wrote:

jerry,

May I recommend you read the thread in Dec? The whole session management was rewritten due to several issues and even security risks with it.
Patch ONLY post.php
I already read that. And my patch was working in fireboard 1.0.3 for me and is also working now (in 1.0.4).
My patch is actually not session-dependent. As I am only deleting flag (for thread where is message posted) of read threads for all users, when is message posted (in that thread).
Mentioned performance penalty is there, cause these flags are in one column readtopics:char which must be searched by like and parsed.

I see. Did not want to go down that path as it will makes posts on larger and active forums more expensive. On a forum like BOJ or others out there with some 10000 registered users and the fact that people look at 10-30 threads, this would become by far the most expensive query/test on the system. Having said that I do like the approach, normalizing the table comes at the cost of more sqls being run at every page view - of which we already have plenty.

Having said that: for smaller sites your fix might be the perfect temporary solution. I am committed to a long term fix, but after we have fixed more serious bugs with the board.

jerry wrote:
Luisdv wrote:
Hello, thanx for all the work done so far. I use Joomla 1.0.13 and Fireboard 1.0.3
I have a very active forum (445 users) and they post and stay connected to the forum all day long.

I applied the fxstein patch, and it seems all is correct, but when a user writes a new post in the next minute os the las marked as new, it is not showed as new in the category folder (stays blue and dont have new indicator), and also is not showed as new in the list of messages of the category.

This is the last patch?
joomlacode.org/gf/project/fireboard/scms...=461&view=markup

Sorry with my english.
apply my patch on post.php as written on my latest posts in this thread.

Ok thank you i found your patch, here is the page where it is posted www.bestofjoomla.com/component/option,co...t,10/limitstart,100/

Other problem i have is with the hidden users, everybody can see them, i think it will go in other topic, but if someone could help me, i will be very happy.

Thanks Jerry.

Just to be sure:
Here's the WHOLE PATCH to get new flags, when somebody sends message in your session.
It's the one from 2007/09/27 09:01. Nothing new.
components/com_fireboard/template/default/post.php
[code:1]
components/com_fireboard/template/default/post.php
}
}

+ $database->setQuery("SELECT * FROM #__fb_sessions WHERE readtopics LIKE '%$thread%'"«»);
+ $sessions = $database->loadObjectList();
+ foreach ($sessions as $session) {
+ $readtopics = $session->readtopics;
+ $userid = $session->userid;
+ $rt = explode(",", $readtopics);
+ $key = array_search($thread, $rt);
+ if ($key !== FALSE) {
+ unset($rt[$key]);
+ $readtopics = implode(",", $rt);
+ $database->setQuery("UPDATE #__fb_sessions SET readtopics='$readtopics' WHERE userid=$userid"«»);
+ $database->query();
+ }
+ }
+
//Now manage the subscriptions (only if subscriptions are allowed)
if ($fbConfig['allowsubscriptions'] == 1)
{ //they're allowed

[/code:1]

Hi Jerry.. Which Line shall I put this in post.php?

Apologies if my post covers something that has been dealt with already
this thread is huge !

my issue is that posts are getting marked NEW - in fact they get marked new again even after they have been read!

clicking "mark all read" is a quick way to make them all reappear in a jiffy.

I am running Joomla! 1.0.12 Stable with Fireboard 1.0.3 Stable.

It seems to me that at some time I tweeked some sort of timeout value which
may well be the reason that people show up in "who's online for quite sometimeafter they log out in joomla
but not in fireboard!

If anyone can give me a pointer about what this is all about I would appreciate it.
I've hesitant to upgrade - I'm more of an OS admin than a coder.

Your particular problem has been fixed in 1.0.4. Its the faulty session handling that causes just that. The issue left over is newly posted threads within a current session. A proposed fix has been posted by Jerry. I have been looking into it to see what it means in terms of performance and if there are alternatives.

nanaya wrote:
Hi Jerry.. Which Line shall I put this in post.php?
about line 280
it should be just before these lines..

[code:1] //Now manage the subscriptions (only if subscriptions are allowed)
if ($fbConfig['allowsubscriptions'] == 1)
{ //they're allowed[/code:1]

brnr wrote:
jerry wrote:

apply my patch on post.php as written on my latest posts in this thread.

Does this apply to 1.04 fireboard too?
sure

fxstein wrote:
jerry wrote:
fxstein wrote:

jerry,

May I recommend you read the thread in Dec? The whole session management was rewritten due to several issues and even security risks with it.
Patch ONLY post.php
I already read that. And my patch was working in fireboard 1.0.3 for me and is also working now (in 1.0.4).
My patch is actually not session-dependent. As I am only deleting flag (for thread where is message posted) of read threads for all users, when is message posted (in that thread).
Mentioned performance penalty is there, cause these flags are in one column readtopics:char which must be searched by like and parsed.

I see. Did not want to go down that path as it will makes posts on larger and active forums more expensive. On a forum like BOJ or others out there with some 10000 registered users and the fact that people look at 10-30 threads, this would become by far the most expensive query/test on the system. Having said that I do like the approach, normalizing the table comes at the cost of more sqls being run at every page view - of which we already have plenty.
Maybe you are right, that parsing string is faster...
than there should be FULLTEXT on readtopics to not go through whole table (LIKE matching) and pre/postfix free code in matching (for example: "a1b,a12b,a123b," whould be faster to find and replace than 1,12,123).
Also it is possible to do that with users in session, checking lasttime (also needs index on that column).

Having said that: for smaller sites your fix might be the perfect temporary solution. I am committed to a long term fix, but after we have fixed more serious bugs with the board.
Can you mention which are high-priority bugs? Maybe I/we can help.

You can check the bugtracker.