- Posts: 4
- Thank you received: 2
Kunena 6.3.0 released
The Kunena team has announce the arrival of Kunena 6.3.0 [K 6.3.0] in stable which is now available for download as a native Joomla extension for J! 4.4.x/5.0.x/5.1.x. This version addresses most of the issues that were discovered in K 6.2 and issues discovered during the last development stages of K 6.3
Important NEW indicator disappears from unread topics after after a day or so
Please Log in or Create an account to join the conversation.
See github.com/Kunena/Kunena-Forum/issues/1945
Blue Eagle vs. Crypsis reference guide
Read my blog and
Please Log in or Create an account to join the conversation.
When the user clicks "mark topics read" in a category, the time is stored as a Datetime in the #__kunena_user_categories table. The time everywhere else is stored as a timestamp int.
In KunenaForumCategoryHelper there is a query:
$query = "SELECT t.category_id, COUNT(*) AS new
FROM #__kunena_topics AS t
LEFT JOIN #__kunena_user_categories AS uc ON uc.category_id=t.category_id AND uc.user_id={$db->Quote($user->userid)}
LEFT JOIN #__kunena_user_read AS ur ON ur.topic_id=t.id AND ur.user_id={$db->Quote($user->userid)}
WHERE t.category_id IN ($catlist) AND t.hold='0' AND t.last_post_time>{$db->Quote($session->lasttime)}
AND (uc.allreadtime IS NULL OR t.last_post_time>UNIX_TIMESTAMP(uc.allreadtime) )
AND (ur.topic_id IS NULL OR t.last_post_id != ur.message_id)
GROUP BY category_id";
UNIX_TIMESTAMP takes a Datetime and assumes it's in the timezone of the server.
The dates are actually stored in UTC (JFactory::getDate()->toUnix())
So unless your SQL server's timezone is set to UTC (which it isn't in my case), you get a difference of some hours between the values.
So people mark a category as read, and then it doesn't actually appear to have new messages until some hours later (your UTC offset). If they click on a category, it actually shows them that some threads have new messages, because the rest of the code correctly uses timestamps everywhere, the only place where the time is stored as a datetime is in the #__kunena_user_categories table.
I fixed this with a hack by putting in my server's UTC offset in that query. But maybe this should be fixed globally somehow.
Hope this helps somebody.
(P.S. This still refers to Kunena 2, but I saw the same query in the Kunena 3 source code, so I think the issue is the same.)
Please Log in or Create an account to join the conversation.
In Kunena 2.0 we improved this feature by fixing a few important bugs in it, but the changes also allowed to have unlimited read indication. However it was decided that the table is only meant to keep that data available during the session, with hardcoded upper limit of 3 days (after with the data will be deleted). That limit is still valid today.
I'm not happy with the limit, but to overcome it, we need to work around an issue of having the data available only 3 days for all older versions of Kunena. Basically the side effect could be to have all the read topics as new after the update for many users.
On the second issue I've never heard it before and the code hasn't changed after the major bug fix in 2.0.2 or 2.0.3. I'm also not able to reproduce it locally -- I've tried to do that few times during the last 3 days, with no luck. Maybe I'm missing something very obvious, I don't know.. Which version of Joomla are you using?
Are you able to provide actual real query you're seeing (debug mode on) and the result in phpmyadmin? I believe you, but it's a bit hard to solve the issue without being able to reproduce it myself.
Please Log in or Create an account to join the conversation.
My computer is always in UTC, recardless of which timezone I pick up (using Ubuntu), so.. It was a bit hard to reproduce the issue. I'll figure out if there's another way to do it..
Please Log in or Create an account to join the conversation.
$date1 = JFactory::getDate();
echo $date1->toFormat() . '<br>';
Result: 2013-10-06 21:01:00
echo $date1->toUnix() . '<br>';
Result: 1381093260
then do this in mysql: SELECT UNIX_TIMESTAMP('2013-10-06 21:01:00');
Result: 1381118460
The difference is the time offset. Arguably, it's a bad practice to have php and mysql run in different time zones (one of them is not UTC), but I am not a shared server so I don't think I can change it.
Please Log in or Create an account to join the conversation.
github.com/Kunena/Kunena-Forum/issues/2007
Not sure if we have time to fix it for the next bugfix release -- we're already started release process on K3.0.3, which will be out within a few days.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.