Minor issue – Stats default timerange UTC-based

  • Resolved OnePressTech

    (@timhibberd)


    10 years, 5 months ago

    I’ve tagged this as a minor issue…hopefully it won’t come across as being too nitpicky ??

    Minor Issue:
    The stataway shortcode displays a default stats range with an end date of “now” but “now” is not reflecting the local timezone (Australia in this case). So for me, being in Australia, “now” gets displayed as yesterday. I just raise it as a minor issue only because when I uploaded a file and looked at the stats it did not appear. It took me a minute and a bit of head scratching to realise that the default display range for stataway was showing uploads up to yesterday (Australian time) and today’s uploads were not being displayed. I just had to click on it to select today’s date (in Australia) for the files to appear so it’s pretty minor in the scheme of things. Others might not make that connection though.

    NOTE: I noticed that the plugin code sets the default timezone and I have the WordPress Timezone correctly set in WordPress Settings so I’m not sure what the culprit is for this issue. It appears a United States timezone is being used rather than the Australian timezone configured in WordPress…once the U.S. date and Australian date aligned the stataway shortcode user interface displayed the correct “now”.

    Thoughts?

    PS: I’ll poke around at this further to see if I can figure out where the issue is. First pass debugging did not yield any suspects. Code all looks good.

    ————
    Don’t worry about the world coming to an end today. It is already tomorrow in Australia. Charles M. Schulz
    ————

    https://www.ads-software.com/plugins/file-away/

Viewing 15 replies - 16 through 30 (of 70 total)
  • Thread Starter OnePressTech

    (@timhibberd)

    Thanks again for your patience. One of us will have an aha moment or kill the other…thankfully I’m in Australia ??

    If you trace an initial call on shortcode render, the html displaying the date range is built on line 21-22 based on the $begin and $end variables.

    The $begin and $end variables are set on lines 5-6 based on the $_GET[‘fsb’] and $_GET[‘fse’] superglobals.

    When I backtrace into the class.stataway.php file which is the shortcode logic called by WordPress I don’t see where $_GET[‘fsb’] and $_GET[‘fse’] superglobals would get initialised. I’m sure they are…I just can’t see the lines of code that are doing it and they are not passed in as shortcode paramters.

    Plugin Author thomstark

    (@thomstark)

    Why do you think they have to be initialized?

    Thread Starter OnePressTech

    (@timhibberd)

    Because they are the default values in the html being displayed on initial shortcode display rendering? (I think my aha moment might be coming).

    Plugin Author thomstark

    (@thomstark)

    They either are or are not the default values. If they’re not in the url, then the default values are current date and current date minus one week.

    Thread Starter OnePressTech

    (@timhibberd)

    You are definitely going to shoot me…

    The html displaying the date range is built on line 21-22 based on the $begin and $end variables.

    The $begin and $end variables are set on lines 5-6 based on the $_GET[‘fsb’] and $_GET[‘fse’] superglobals.

    You said “If they’re not in the url, then the default values are current date and current date minus one week. ” but which lines of code set that?

    Feel free to give up on me ??

    Plugin Author thomstark

    (@thomstark)

    Lines 10-11. ??

    Thread Starter OnePressTech

    (@timhibberd)

    That’s what I would have thought but my errorlog triggered in the first part of the if statement involving the $_GET statements…the else part of the if statement never triggered. Weird or what! Also noted that the else section lines 10-11 sets the $end date to $now which does not appear to be initialised.

    Plugin Author thomstark

    (@thomstark)

    Well lines 10-11 clearly work because otherwise you wouldn’t be having the problem of the end date being yesterday vis-a-vis Australia. ??

    $now is initialized on line 4 of inc.stataway-declarations.php

    Thread Starter OnePressTech

    (@timhibberd)

    I agree they are initialised because they are preceded by the following check on line 3:

    if(isset($_GET[‘fsb’]) && isset($_GET[‘fse’]))

    And I get that they are set via javascript onclick…but it’s bugging the heck out of me that I can’t seem to backtrace where they are being initialised on shortcode call :-O

    Thanks again for your patience ??

    Plugin Author thomstark

    (@thomstark)

    They are not initialized on shortcode call. They are not shortcode attributes.

    Thread Starter OnePressTech

    (@timhibberd)

    But then why is the if(isset($_GET[‘fsb’]) && isset($_GET[‘fse’])) passing? Something is initialising them…any ideas where?

    Plugin Author thomstark

    (@thomstark)

    Lines 5-6 of inc.stataway-range.php is as far back as you can trace them, because that’s the first time they are introduced into the method.

    Plugin Author thomstark

    (@thomstark)

    The $_GET superglobal is defined by the url, not by the shortcode.

    Thread Starter OnePressTech

    (@timhibberd)

    I know…that;s what’s puzzling me…the if(isset($_GET[‘fsb’]) && isset($_GET[‘fse’])) is passing so something is initialising them! Ahh ??

    Plugin Author thomstark

    (@thomstark)

    Php initializes them because they are in the url. They are initialized before my shortcode even exists, nay, before WordPress even exists.

Viewing 15 replies - 16 through 30 (of 70 total)
  • The topic ‘Minor issue – Stats default timerange UTC-based’ is closed to new replies.