Single journal in multi journal installation not creating statistics

ajnyga · August 17, 2018, 11:09am

I just noticed that one of our journals is not creating statistics to the metrics table

I mean I can see the stat hits in the log files for that journal, but these hits are not turned into stats in the metrics table.

The base_url for the journal is defined and correct, the stats plugin is enabled (like it is with all journals from site level) and as I said log files are being created.

I can see stats with assoc_types 256 and 259 for that journal, but none with 515 although I can find hundreds of article downloads from the log files.

The journal path for that particular journal is ar. What comes to mind of course is that the article starts with ar, is that affecting the way the log file is being read somehow?

ajnyga · August 23, 2018, 5:46pm

sorry to push this @asmecher, but do you have any idea what this could be about?

ctgraham · August 24, 2018, 7:12pm

Ooohhh… This report also has me baffled, but the description of the problem is the same, aside from the shortname concern.

@ajnyga are you on 2.x or 3.x?

ajnyga · August 24, 2018, 7:23pm

3.1.1.2.

We have 70 journals and this is the only one not getting hits in the metrics table (except the 256(homepage) and 259 kind). I will probably try to replicate this on a test server and see if I can find out the reason there.

ajnyga · August 25, 2018, 9:02am

Ok, so I can confirm that if the context path is “ar”, the _getUrlMatches here https://github.com/pkp/usageStats/blob/master/UsageStatsLoader.inc.php#L709 is not returning any results for an url that is sent for it.

So an url like http://site.com/store/article/download/45178/11450/32130 works, but url like http://site.com/ar/article/download/67591/27887/81477 does not work.

Edit: basically Core::removeBaseUrl is not working correctly. If you give it an url like http://site.com/ar/article/download/67591/27887/81477 it will return /article/download/67591/27887/81477 and not /ar/article/download/67591/27887/81477

ajnyga · August 25, 2018, 9:43am

Ok, so this check is not working if the url given there starts with “article” and the contextpath is “ar”, “art”, “arti” etc.:

github.com

pkp/pkp-lib/blob/main/classes/core/Core.inc.php#L263


 */
public static function getArgs($urlInfo, $isPathInfo, $userVars = [])
{
    return Core::_getUrlComponents($urlInfo, $isPathInfo, 2, 'path', $userVars);
}

/**
 * Remove base url from the passed url, if any.
 * Also, if true, checks for the context path in
 * url and if it's missing, tries to add it.
 *
 * @param $url string
 *
 * @return string|bool The url without base url,
 * false if it was not possible to remove it.
 */
public function removeBaseUrl($url)
{
    [$baseUrl, $contextPath] = Core::_getBaseUrlAndPath($url);

    if (!$baseUrl) {

Probably there are similar collisions with other url’s as well. For example with url’s like “issue/view” there will be a collision with context paths like “is” and “iss”.

So you actually need to have that row like if (strpos($url, '/' . $contextPath . '/') !== 0)
But that will not fix the issue if your context path is for example “article” or “issue”. I wonder if context paths like that are black listed?

ajnyga · August 25, 2018, 10:18am

@ctgraham here is an issue and a fix Usagestats not being processed if contextPath collides with "article" · Issue #4009 · pkp/pkp-lib · GitHub

For me it was what it suspected, the contextPath and “article” collided and there was a bug in core.inc.php.