I have a problem when I want to display the number of pdf views and downloads. currently I have 3 sites, there are some sites that have problems such as a working pdf view but the pdf download does not work.
I have followed the tutorials of many articles on this forum but still have not found a solution, all of them display the result 0, one of the ways I follow is to check whether Usagestat in the archive section is empty or not.
I’ve checked everything on the site that I have but there is still no definite solution.
How have you tried to do that, could you please describe the steps/code…?
Do you see the numbers when you (as journal manager) go to Statistics > Articles?
Or, can you check what is in your DB table metrics: are there entries for assoc_type = 515 and file_type = 2 and appropriate context_id and submission_id?
I added a few lines of code to article_summary.tpl and articleGally.inc , I changed it according to some of the solutions on this forum they said by adding it we can find out the number of abstract views and pdf downloads. and that’s right Abstract view and pdf download appear but the number is very low even 0. I think this is very strange because this site has been around for a long time.
You can see here only ITSDI does not have a pdf download, all pdf download articles are 0 , but the abstract view is there and the number is very small, besides ITSDI for other journals it has abstract views and downloads but the number is very low. Like a newly created journal.
And for AJRI which is on the adi journal site, everything went smoothly but why only 2019 did not have statistics.
If you look at the usage events that have existed since 2019, and if you check the metrics table for context id 1, namely AJRI in 2019 it was recorded but the assoc type was 531, assoc type 515 only appeared after 2021.
On the ITSDI aptikom journal site I’ve checked it in the metrics table according to your direction and I didn’t find articles with assoc type 515, for other than ITSDI they have several articles with assoc type 515 with very few numbers. To me this is very absurd, this site has been around for a long time, but the number of statistics is very low, even though the number of visitors is quite large.
Regarding assoc_type = 531.This type was introduced with OJS 3.1 (2017 I believe) for the files that are not full text documents. For the decision if a text is a full text document the DB table genre is considered. There should be (only) one genre per journal that is neither supplementary and nor dependent, and has entry_key=SUBMISSION. The PDF submission files should have that genre associated with them – you can check that in the DB table submission_files.
So, if the PDF files are represented in the metrics table with 513, then something might went wrong with the genres.
For the other installation where the numbers are very low: it seems like something happened in February or March this year and since then the usage logs are partly there? Do you know if maybe an update or something else happened then?
Are there any 513 entries in the aptikom-journal.id installation?
Can you take a look at a log file and double check if at least the abstract views are correctly represented in the DB table metrics?
You could also take a look into the actual usage event log files and see if everything seems OK there – for example, what URLs were accessed, if there are PDF and abstract URLs, are domains and paths in URLs correct…
In the worst case you could reprocess the usage event log files again, but:
First all other possible issues should be resolved, e.g. if there is a genre problem.
It depends when they start, i.e. what OJS version was used back then. For example it could be that article URLs changed between some OJS version (e.g. between 2.x and 3.x). So it would be important that you investigate your URLs first!!!
It would be good/necessary to test it first, i.e. on a copy of the site, on a test installation.
When testing reprocessing: You would first take only one file, investigate that the URLs are correct there, backup everything!!!, and then test the reprocessing of just then one file.
I can send you the steps you would need to reprocess a file, but let us first figure out what could be the actual problem, that has to be solved first…
I tried to fix the base url on the apticom journal and now the statistics pdf download and abstract view are running normally on the front page of our journal, you can see it at the following link http://aptikom-journal.id/index.php/itsdi/index
However, the statistics in the dashboard of the statistics/article file view menu still display the number 0.
If you look back, it seems that the increased statistics have only been for the past few days. while the overall statistical data from the previous data is not calculated, although the usagestat record in the archive is still there.
Is there any other solution that can be done so that the overall statistics from the previous data can be displayed?
I think there is still a possibility that it can be displayed because I still keep the log archive on usagestat.
The code that you use to display the PDF counts is different than the one used for the statistics in the dashboard – for example, it does not consider assoc_type (which I think is the problem).
Yes, the log files can be reprocessed, but we first need to find out where are the problems and fix them – it could be that the problems will exist also if the log files are reprocessed.
How did you fix the base url problem?
Your code is reading from the DB table, so I am wondering how base url could fix that problem…
Could you take a look into your DB table submission_files, submission_artwork_files and submission_supplementary_files of the aptikom installation, and see if there is the file_id = 194 and file_id = 1159?
Could you also please make this SQL query: SELECT sf.file_id, g.* FROM genres g, submission_files sf WHERE sf.genre_id = g.genre_id AND (sf.file_id = 194 OR sf.file_id = 1159)