• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Fixed Something odd with statistics since upgrade ?

Mike

XenForo developer
Staff member
#7
Hmm, I wrote a post to this, but I guess I never submitted it.

It was down to a quirk of ISO-8601 week numbers and the year that they apply to. (For example, Jan 1 - 3 2016 were considered to be part of week 53 2015.) I made the handling consistently use the year number based on that week number and it sorts it.
 

StarArmy

Active member
#8
I noticed this too on my forum. I see the prefix says "fixed" now so I can safely assume this will be fixed in the next version release?
 

Zenexer

Active member
#10
Here's a patch file for those of you who want to fix it on your own. If you're not sure how to apply a patch and you just want a quick fix:

Open library/XenForo/ControllerAdmin/Stats.php in a text editor. Scroll down until you see:
PHP:
'weekly' => array(
	'printDateFormat' => '\WW Y',
	'groupDateFormat' => 'YW'
 )
Notice the two instances of "Y". That's the wrong year code for weekly statistics. Change both of them to "o". Yours should now look like this:
PHP:
'weekly' => array(
	'printDateFormat' => '\WW o',
	'groupDateFormat' => 'oW'
)
Hopefully you didn't come up with some complicated solution, @Mike. ;) Here's the description for "o":
ISO-8601 year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead. (added in PHP 5.1.0)
The MySQL changes in the patch aren't strictly necessary, but they should (theoretically) increase performance.
 

Attachments

Last edited:

Mike

XenForo developer
Staff member
#12
That's a partial fix, though the code in the controller isn't actually used. The MySQL change definitely is necessary and there are some other spread out PHP changes in the stats formatting to use "o".
 

Zenexer

Active member
#13
Needlessly smug though
Haha, well, it certainly doesn't benefit me if a complicated alternative ends up in a release. Optimization is important. The only reason I mentioned it is because often they release a patch for simple fixes. My apologies if it was offensive.

That's a partial fix, though the code in the controller isn't actually used. The MySQL change definitely is necessary and there are some other spread out PHP changes in the stats formatting to use "o".
The MySQL change is necessary to get a perfect chart, but not to get a "good enough" result, which is what I figured most people would want for now. The controller fix is what got it working on our site, but we've made a lot of other changes in that general vicinity, so it's possible it's not relevant to a vanilla site. I didn't need to change anything else to get proper results specifically for weekly stats. The MySQL query doesn't actually return the year/week numbers; one week just ends up split into two adjacent groups if the query isn't fixed.

Edit: I think I see why that patch worked for us even though that code isn't used. It wouldn't work in years where there are 4 or more days of the overlapping week in January. I'll update the patch with a quick fix.
 
Last edited: