Article statistics showing 0 abstract views and 0 PDF downloads

For downloads to be converted into metrics, your usage statistics logs must be processed by cron or acron. This is intended to happen daily. As such you will not see your clicks today translate into metrics until that process runs, which will be at least after the close of the day.

If you don’t see any activity for 2017, you may not have an active cron or acron process which is parsing the logs into metrics.

Anyway, in the report I should see at least 1 download in 2016. But it is still zero.

So we can see the metrics, but the whats the error? any idea?

@Ph_We, I suspect you are seeing the bug reported here:

This bug would prevent the ArticleGalley::getViews() call from finding the download of submission_id #1, as identified by the assoc_type 515.

@ctgraham, so now it seems to be solved, doesn’t it?

@Ph_We, I suspect if you are able to patch your installation, or pull the latest stable commits from GitHub, this should work for you.

On the other hand, there is still something preventing what look like correctly recorded metrics from appearing for @varshilmehta, so no promises. :frowning:

Anyway, thank you very much for your support, and sorry for not always following :slight_smile:

Alright… Any ideas? You can even log in my account and have a look yourself. I would be glad if you can help me with that.


Would it be possible for you to somehow debug this function: This function is called when calling $article->getViews(). First this function is called:, which then calls getMetrics. Maybe the function getPrimaryMetricByAssoc allways returns 0, because the result from getMetrics is not an array in your case…

Else, no idea what is happening there…


How should i debug it? Could you please tell me the exact steps?

Also, the journal stats (Reposrt Generator) is showing is 0 abstract views.

Hi @varshilmehta

I think I know what is going wrong in your metrics: I think you need this patch:pkp/pkp-lib#2087 fix usage event on article page · pkp/ojs@75ced9f · GitHub
In your DB table metrics you have only entries for submission ID = 1 and you actually do not have that submission published. Because of the bug above, the system logged the issue ID instead of the article ID. Thus, after you have applied the patch you should wait for a few days (for statistics to get generated again) and then you should see the right numbers on your pages.


Ok cool. I have done the changes and will keep you updated, Thanks a lot bro. :slight_smile:

Hey bro,

I just saw that my ojs is not registering any metrics since 12th Jan. What could be the error here? Any idea?

Hi @varshilmehta

Can you check if you statistic log files since Jan 12th are there – in your files folder under usageStats/? You could check if the logging is functioning correctly: when you for example go to an article page, that that page is logged correctly in the current log file under usageStats/usageEventsLogs/. If this is correct, then something is wrong with the log file processing…



Concerning the View Report Plugin: do you see any PHP errors in your php error log file when you try to create the report?

Concerning the usage statistics log files: I do not know why are they in those folders – it seems like they are not processed. Maybe there is an error occurring, that disables processing.
Initially, the statistics log files are in the folder usageEventLogs. Then when they are processed, they are moved into the folder stage and the file that is processed right now is moved to the folder processing. If the data could not be loaded from that file, the file will be returned to the folder stage, s.
And I do not know why is this happening :frowning:
Maybe the same error that makes View Report Plugin not work is the problem here as well…

Also, what do you see in your files folder > scheduledTaskLogs and then one of the latest Usagestatisticsfileloadertask.. .log files?


Please take a look also in the statistics log files, if the usage is logged correcty i.e. when you click on an article page if the log entry is correct…

Hmmm… Those are a little bit older, from Jan 8th. And apparently they contain nothing :open_mouth:

I will start from scratch. Will put everything from default folders and will see what went wrong.