The MU forums have moved to WordPress.org

Site Wide Activity stream not working (28 posts)

  1. bbrian017
    Member
    Posted 4 years ago #

    I am hoping someone can help me maybe from experience or because you are a nice person.

    I am having many issues with Buddy press site wide activity.

    I started a thread but still no answers have been given.

    http://buddypress.org/forums/topic/activity-stream-not-working

    Can anyone help me? It's really making me frustrated.

    Thanks so much if you can,

    Brian

  2. bbrian017
    Member
    Posted 4 years ago #

    Something I have also taken note of is as follows.

    I get a member sign up e-mail but when I get to the website is saying member registers 7 hours ago.

    But I only got the e-mail now.

    Perhaps that will help figure out the issue?

  3. bbrian017
    Member
    Posted 4 years ago #

    Also take note I just posted an article and it went behind a few older activities saying it's more then 14 hours old but its' not I just wrote it.

    Any suggestions on how to fix this?

  4. bbrian017
    Member
    Posted 4 years ago #

    I also just got a private message and it states 7 hours ago.

    I was told this is a wpmu issue is this correct?

  5. bbrian017
    Member
    Posted 4 years ago #

    So again I just posted 2 articles created three groups and they say 7 hours old but the important part to make note of here is the older items are still being displayed as if they are newer.

    Nothing is updating properly.

  6. andrea_r
    Moderator
    Posted 4 years ago #

    I think it;s a server issue. Check the time on your server.
    Check the time in the backend of WPMU under Settings.

  7. bbrian017
    Member
    Posted 4 years ago #

    andrea_r the only time setting I see in wpmu is under general setting is this what you are referring too?

    Currently it's set to -7

    My server time is set to Arizona time zone so I think it's central time zone.

  8. bbrian017
    Member
    Posted 4 years ago #

    andrea_r something else I noticed.

    When a user posts in a group forums it will say posted 29 minutes but on the mian site is says 7 hours, 29 minutes ago

    Any suggestions :)

  9. andrea_r
    Moderator
    Posted 4 years ago #

    And what is your *server* time?

    Given you put -7 in the WP settings, and everything is 7 hours off, I'm gonna guess the server is on GMT.

    Test: change your setting to -1. Then see what the site does on the front.

  10. bbrian017
    Member
    Posted 4 years ago #

    I have changed it to -1 and my server is in Arizona GMT

    http://www.timetemperature.com/tzus/arizona_time_zone.shtml

  11. bbrian017
    Member
    Posted 4 years ago #

    After I made the suggested change I wrote an article and it was placed under three or four older activities.

    The article states I wrote it 8 hours ago but I just published it now.

  12. bbrian017
    Member
    Posted 4 years ago #

    This is still proving to be an issue.

    What are my options regarding fixing this andrea_r?

  13. bbrian017
    Member
    Posted 4 years ago #

    I also noticed changing the time in the general settings section doesn't affect the mian site.

    I posted a wire message testing @ -1 and it said posted 7 hours ago.

    I posted a wire message testing @ -7 and it said posted 7 hours ago.

    Just thought it might be important to know that.

  14. andrea_r
    Moderator
    Posted 4 years ago #

    "What are my options regarding fixing this andrea_r? "

    First, you have to troubleshoot exactly where it is broken. Narrow down if it's the server, the WPMU portion, or buddypress itself.

    The last post suggests BP. If you can consistently prove it does this, then it's time for a BP trac ticket. I haven't checked your posts on the BP forum, but at this point, that would be the best place for help.

    Edit: you should also hunt down anyone else posting about this issue, so it can be a proven bug. It also has to be reproducible.

  15. andrea_r
    Moderator
    Posted 4 years ago #

    Edit: rethink

    This is too screwy, go search your db and see if time zone settings are being stored anywhere in MU or BP. Delete 'em so they can be recreated. (and take a backup first please)

  16. bbrian017
    Member
    Posted 4 years ago #

    Sorry what exactly am I searching for?

    Do you have something specific I need to find and what it will possible look like?

    Any hints would be very cool! Consider me blind here lol.

    I know I'm searching for time zone settings but I don't know what the column or row would look like of consist of.

    Thanks,

    Brian

  17. andrea_r
    Moderator
    Posted 4 years ago #

    phpmyadmin has a global search. :) look for GMT or UTC.

    And! I have just encountered someone else who had the same issue.

  18. bbrian017
    Member
    Posted 4 years ago #

    Hi andrea_r Thanks so much for the help by the way.

    I did a search for GMT and found the following,

    5 match(es) inside table wp_10_options
    4 match(es) inside table wp_14_options
    13 match(es) inside table wp_15_options
    1 match(es) inside table wp_17_options
    5 match(es) inside table wp_18_options
    8 match(es) inside table wp_1_options
    10 match(es) inside table wp_20_options
    4 match(es) inside table wp_21_options
    5 match(es) inside table wp_22_options
    8 match(es) inside table wp_23_options
    5 match(es) inside table wp_24_options
    4 match(es) inside table wp_26_options

    And it goes on and on for all the blogs created.

    I did another search for UTC and found the following,

    2 match(es) inside table wp_10_options
    2 match(es) inside table wp_14_options
    2 match(es) inside table wp_15_options
    2 match(es) inside table wp_18_options
    2 match(es) inside table wp_1_options
    2 match(es) inside table wp_20_options
    2 match(es) inside table wp_21_options
    2 match(es) inside table wp_22_options
    3 match(es) inside table wp_23_options
    2 match(es) inside table wp_23_posts
    2 match(es) inside table wp_24_options
    2 match(es) inside table wp_26_options

    This also goes on and on.

    Is this what you expected to find?

    It's good to know I'm not alone with this issue. Or at least wasn't the only one at one point.

  19. lunabyte
    Member
    Posted 4 years ago #

    Brian, you're facing a code issue it seems. Looking at the current trunk of BP anyway.

    When BP generates the text for the "[time] ago" stuff, it passes a time string into a function in bp-core.php called bp_core_time_since.

    In this function the date passed in is compared against a possible second value passed to the function. By default, that value is false.

    When the value is false, it gets the current time as a numerical value (like using the time() function) for the current time as GMT using gmdate to create a date string, which is then converted to a numerical time value.

    Here's the problem. The time being passed into the function as the first parameter is the current server time, and not the GMT time. The second parameter to the function is not passed, thus defaulting to a false condition which then generates the value based on GMT.

    The two times (older and newer as the vars are labeled) are then compared.

    See the problem yet?

    Yes, that's right. It's comparing one time to another, but they aren't in the same timezone.

    If is set as say, 7 hours behind GMT, the initial time passed into the function will be GMT -7. It then creates the current time as GMT without any offset to check against the time passed into the function.

    So, no matter what you do, you're already at a 7 hour difference within this function, and it will show something currently added to the activity as being 7 hours ago even though it just happened right now.

    The times coming into this function either need to be in GMT, or when the time to compare against is created, it needs to be the server time.

    Whichever happens, they need to both be in the same timezone so that 5 seconds ago is 5 seconds ago.

    In summary, you don't have a server problem, or an install problem. It's a BP problem somewhere.

  20. bbrian017
    Member
    Posted 4 years ago #

    lunabyte thanks so much for the feedback. I guess at this point my hope is to fix this as it's affecting the quality of my website and it's members.

    Should I be heading back to buddy press linking them over here to read this thread?

    Hopefully someone will be able to help me rectify this situation.
    I really don't like seeing a new post from a dedciated member get sent way down below all the older stuff. It's rather demotivating.

    What's our next step?

  21. bbrian017
    Member
    Posted 4 years ago #

    Just an update! I posted this reply at buddy press and andy stated the following.

    All true, however bp_core_time_since() runs gmdate() on both time values, converting them to GMT regardless of the time zone.

    What is my options or next step now?

  22. windhamdavid
    Member
    Posted 4 years ago #

  23. bbrian017
    Member
    Posted 4 years ago #

    So does this mean it's officially an issue? Also does this mean we might get a fix?

    Thanks for that link windhamdavid

  24. lunabyte
    Member
    Posted 4 years ago #

    I did a little more digging into this. OK, a lot of digging into this.

    There is a conflict with the timestamps being generated, although I do not have an answer at this time as to why.

    After running various tests on this, from directly within the bp_core_time_since function, the only real results I can see is that the date passed in ($older_date) is offset by the timezone from GMT, where when the $newer_date is created, there is no offset from GMT.

    So if you're 6 hours behind GMT, the $older_date will be 6 hours behind the freshly generated $newer_date.

    Yes, $older_date does have a gmdate applied to it, and is then converted back to a timestamp from that result.

    However, the value remains unchanged.

    Thus, the difference between the two times will always be at least the time offset from GMT.

    I was able to take the $older_date and add 6 hours to it, which then produced the desired time output.

    Before:
    $older_date = strtotime( gmdate( 'Y-m-d H:i:s', $older_date ) );

    After:
    $older_date = strtotime( gmdate( 'Y-m-d H:i:s', $older_date ) ) + (60*60*6)

    That isn't a true solution, just showing what I had to do to get it up to speed.

    It's 60 seconds * 60 minutes * 6 hours, to get the number of seconds the $older_date timestamp was off by.

    Again, not a solution. Just a way to quickly work around the problem.

    The real interest is why is the older_date offset 6 hours (behind), even after the gmdate conversion.

    With everything I ran though, including testing in just a plain, non-wp/bp php file, I can't say anything was found that really adds to this.

    I can say that If I printed the timestamps used in bp_core_time_since, then used those in the plain php file, that the output results were different.

    Whether the underlying issue is php/server config, with WP (it did this on a plain MU 2.9.1.1 install as well) trying to fix it, or if it's something just really weird somewhere within the WP or BP core, I can't say.

    I'd dig into it more for ya, but I'm a bit out of time. Keep an eye on that trac ticket to see what comes of it.

  25. lunabyte
    Member
    Posted 4 years ago #

    Something I should note.
    I had to go back into the activity templates file (bp-activity dir), to the function calling it from there and add a defined constant.

    Then in the time_since function, only add the time difference when that constant is defined.

    Looking back at the install I was testing with a minute ago, other times are being calculated correctly, just not when it's dealing with activity.

  26. windhamdavid
    Member
    Posted 4 years ago #

    thks for the help lunabyte! this update fixed the ticket ~
    http://trac.buddypress.org/changeset/2416

  27. lunabyte
    Member
    Posted 4 years ago #

    You're welcome. Wish I could have tracked it back further, but I was pretty short on time.

    Good news is that Brian wasn't going crazy, and didn't need to waste his resources on hiring someone to look at his server for nothing.

    Plus, another bug bites the dust.

    Thanks for working with the ticket, and getting it some attention.

  28. bbrian017
    Member
    Posted 4 years ago #

    Thanks for all the help guys it will be nice to have this fixed.

About this Topic

  • Started 4 years ago by bbrian017
  • Latest reply from bbrian017