Single journal in multi journal installation not creating statistics

Hi @bozana and @asmecher

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?

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

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?

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.

Ok, so I can confirm that if the context path is “ar”, the _getUrlMatches here is not returning any results for an url that is sent for it.

So an url like works, but url like does not work.

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

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

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?

@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