×
Kunena 5.1.13 Released (21 Jul 2019)

The Kunena team has announce the arrival of Kunena 5.1.13 [K 5.1.13] which is now available for download as a native Joomla extension for J! 3.9.x. This version addresses most of the issues that were discovered in K 5.1 and issues discovered during the development stages of K 5.1.

× Topics that are moved into this category are considered to be closed. Users may want to add additional information but these topics should not be resurrected in order to discuss new problems or unrelated matters.

Important NEW indicator disappears from unread topics after after a day or so

More
5 years 11 months ago - 5 years 11 months ago #1 by natty
I've read that the behavior of the New indicator has been changed in K 3.0 in that posts say New until the user actually reads them. I've upgraded my forums, logged in, there were some new posts. I didn't read them, and logged out. This morning none of them are marked New, same behavior as before. What do I need to do to make posts stay New until the user reads them?
Last edit: 5 years 11 months ago by sozzled. Reason: Add URL reference to link related topic

Please Log in or Create an account to join the conversation.

More
5 years 11 months ago #2 by sozzled

Please Log in or Create an account to join the conversation.

More
5 years 10 months ago - 5 years 10 months ago #3 by natty
Ok, I think I found another interesting bug with the New indicator.

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.)
Last edit: 5 years 10 months ago by natty. Reason: typo
The following user(s) said Thank You: Jiminimonka

Please Log in or Create an account to join the conversation.

More
5 years 10 months ago #4 by Matias
Read notification is designed to reset after logout -- basically if you don't return soon after the session times out, Kunena will assume that you have read all the messages you want to and forces all topics older than that to be read.

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.

More
5 years 10 months ago #5 by Matias
OK. The obvious part that I was missing was this:

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.

More
5 years 10 months ago #6 by natty
Here's how I figured out something weird is going on

$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.
The following user(s) said Thank You: Matias

Please Log in or Create an account to join the conversation.

More
5 years 10 months ago #7 by Matias
Added a bug from this issue:

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.

More
5 years 8 months ago #8 by Matias
Fixed for Kunena 3.1 -- the change will break backwards compatibility (or downgrades) which is why we couldn't introduce the change into Kunena 3.0.

Please Log in or Create an account to join the conversation.

  • Not Allowed: to create new topic.
  • Not Allowed: to reply.
  • Not Allowed: to edit your message.
Time to create page: 0.088 seconds