Fixed Something odd with statistics since upgrade ?

[Stemmy]

I upgraded to 1.5 last week and since then the statistics section seems to have had a wobble.

If I look at weekly statistics it looks like this ??

 

[Paul B]

The same is happening here so I have moved this to bug reports.

 

[Stemmy]

Ok thanks Brogan - I'll stop looking for the problem

 

[Mouth]

FYI, set the end date prior to 2016 (eg. 31/Dec/2015) and it works fine.

 

[The Sandman]

Late Y2K bug?

 

[HotCopper]

Y16K!

 

[Mike]

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]

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?

 

[Mike]

Yes, the fix will be in the next release.

 

[PaulB]

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:

'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:

'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.

 

[thedude]

@Zenexer Nice quick patch

Hopefully you didn't come up with some complicated solution, @Mike.

Needlessly smug though

 

[Mike]

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".

 

[PaulB]

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.

 

[PaulB]

Updated patch based on @Mike's hints

 

[The Sandman]

Fixed in XF 1.5.5!