• Hi there,

    It’s probably something that I’m doing incorrectly, but I’ve had to modify the core plugin file found at /paid-memberships-pro/includes/profile.php to fix an annoying bug in my users’ admin profile page.

    WordPress Timezone is correctly set.
    PHP ini_get(date.timezone) is correctly set.

    In the original code, I’ve set my WordPress Timezone to be “Australia/Melbourne” but PMPro doesn’t seem to honor this setting. i.e. In my database, the expiry date is stored in my TZ as 2017-02-19 00:00:00 (which is correct), but on the wp-admin edit user page, it displays at 2017-02-18 13:00:00 (which is UTC). After debugging the code, the following appears true:

    Database = 2017-02-19 00:00:00
    MySQL Query Returns = 2017-02-19 00:00:00
    PHP date() = 2017-02-18 13:00:00 <- uses UTC???

    And PMPro ignores the local timezone, which means that EVERY time someone edits a user, the date is reduced by 1 day. Each time.

    I’ve made the following correction to the aforementioned profile.php code from line 87 to fix my certain situation, but I’m sure it’ll probably be in more places than this.

    //FIX FOR 1 DAY OFFSET BUG
    //Database holds date in current timezone (i.e. Australia/Melbourne) but
    //database query returns UTC timestamp. PHP date() function converts it as
    //it is supplied in UTC - not in current timezone.
    
    /Database - 2017-02-19 00:00:00
    //Query return - 2017-02-18 13:00:00
    //PHP date() = 2017-02-18 13:00
    
    //Manually set the timezone by getting the WordPress option
    $orig_tz = date_default_timezone_get();
    date_default_timezone_set(get_option('timezone_string'));
    
    //some vars for the dates
    $current_day = date("j");
    if($end_date)
    	$selected_expires_day = date("j", $user->membership_level->enddate);
    else
    	$selected_expires_day = $current_day;
    
    $current_month = date("M");
    if($end_date)
    	$selected_expires_month = date("m", $user->membership_level->enddate);
    else
    	$selected_expires_month = date("m");
    
    $current_year = date("Y");
    if($end_date)
    	$selected_expires_year = date("Y", $user->membership_level->enddate);
    else
    	$selected_expires_year = (int)$current_year + 1;
    
    //Reset the timezone to UTC (or originally set)
    date_default_timezone_set($orig_tz);

    Again, if I’m doing something wrong, please advise and I’d be more than happy to correct this as I hate modifying the core files (evidently, I don’t seem to be able to override this file in my theme directory, either?).

    Any advice greatly appreciated.

    EDIT: Also have just noticed the same behaviour on the front-end under “my-membership” – date is incorrectly displaying as 2017-02-18. Bugger.

    Cheers,

    Craig.

    https://wordpress.org/plugins/paid-memberships-pro/

Viewing 9 replies - 1 through 9 (of 9 total)
  • Hey Craig – not affiliated with PMPro but happened to notice someone else with this same problem who’d posted on the premium support site, so brought your post here to their attention. The PMPro people say that a fix is being coded. (Hopefully they’ll actually come here and let you know about it but figured you deserved to be told, since you did so much sleuthing to identify the issue in the first place.)

    Hello Craig and essaysnark,
    I’m the one with the problem from the PMPro support site. “Thank you” to both of you – this problem has been causing our site problems for months. I’ll post back here when the people at PMPro post their notification of a fix on their support site. Thanks again.

    Thread Starter powerfix

    (@powerfix)

    Thanks guys, greatly appreciated.

    I’ve ended up hardcoding the above “fix” across the entire sections of code that deals with a date. Essentially all of it.

    Will look forward to a permanent fix, but haven’t ruled out that I’m not doing something wrong!

    Cheers,

    Craig.

    Plugin Author Jason Coleman

    (@strangerstudios)

    The 1.8.10.2 update that went out today does not contain a fix for this, but I really appreciate the work here and will be able to look into this next week. Thanks again.

    Plugin Author Jason Coleman

    (@strangerstudios)

    FYI it looks like updating profile.php use something like this might do the same thing:

    $current_day = date("j", current_time('timestamp'));

    Passing the current_time(‘timestamp’) there makes sure the date function uses the time zone set in WP.

    There might be more to do, but that is the idea.

    Plugin Author Jason Coleman

    (@strangerstudios)

    FYI 1.8.10.3 went out with some critical checkout fixes. It again DID NOT contain this fix, but it is in on my radar for this week. Thanks.

    Thread Starter powerfix

    (@powerfix)

    Thanks Jason,

    I understand that these things take time, so would rather get a permanent, best case solution in place than rushing it.

    Hi Craig,
    I’ve been told that version 1.8.10.4 of PMPro has fixed this problem. For my site this seems to have fixed part of the problem i.e. if I update a PMPro order then the order date now does NOT have one day subtracted from it (which is correct).

    If I update the user record however, which contains the expiry date, then the expiry date is still having one day removed from it – which is wrong – at least on my site.
    This part of the problem is still being investigated by PMPro.

    I’ll let you know when/if this part of the problem also gets fixed.

    Hi Craig,
    The source of the problem regarding updating User records and the expiry date being reduced by 1 day has been identified. A fix appears here:
    https://github.com/strangerstudios/paid-memberships-pro/pull/387
    I’m informed that this code, or some version of it, should be in incorporated into the next release of PMPro.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘UTC vs. WordPress Timezone – 1 day offset bug’ is closed to new replies.