We have recently upgraded from 2.3.7 to 2.4.6. After the upgrade we have noticed the pdf view stats in Editor section is reverted to zero for our old pdf files.
Also abstract views and pdf downloads are not being updated after the upgrade date.
Would you please advise?
Try this topic: My published file views or statistics reports shows no data. What do I do?
If it doesn’t help, let me know and I will try to debug from there.
Thanks for your reply.
I checked in the system.
- base_url is fine and without “” also the file directory permission seems alright.
- Usage statistics and Acron plugins are enabled.
- scheduled_tasks flag is On in the config file.
- files/usageStats/archive has 3 log files in it as we upgraded 3 days ago.
- files/usageStats/processing and reject and stage folfers are empty.
- The counter report query returns more than 200 rows.
I am not sure based on What's the exact view count statistics and when is it updated? if this behavior is expected or not.
Counter report is only accessible in admin login. However it looks different from other journals in a way that the old counter plugin data and reports generators are missing (please see the image attached).
SELECT * FROM metrics WHERE metric_type = “ojs::legacyCounterPlugin”; returns no rows while
SELECT * FROM metrics WHERE metric_type = “ojs::legacyDefault”; returns again more than 200 rows.
Thanks in advance
I just noticed the** Geolocation database** paragraph in http://pkp.sfu.ca/wiki/index.php?title=PKP_Statistics_Framework#Statistics_migration. I was wondering if that should have done before running the upgrade script. Actually we have already run the upgrade script. I hope there is way to fix this. Although we have a backup of the old database.
I’m not sure what Geolocation database does. Would you please explain?
It seems your stats processing is running ok. Can you make sure you have entries into the metrics table associated with the ojs::counter metric type, running this query?
SELECT * FROM metrics WHERE metric_type = "ojs::counter";
Also, it is important to always read the docs/UPGRADE documentation before doing any upgrade. The Geo location database is used to geo locate the access to the system. Without this your stats will have no location information. But they will be processed anyway.
In respect to the Counter report, there is no old links because there is no old data, we can see that from your first query.
The legacy default is the old data that OJS grabbed itself for the views. This can be accessed using the View report.
Yes I could see the old stats in View Reports. However our journal manager is concerned that if the stats are going to accumulate in View Reports or not? Or it’s going to discontinue in View Reports?
The query ojs::counter returns only stats after the migration. The numbers are very low obviously. The query on ojs::legacyDefault return all our old stats before the migration with high numbers. So I thought we have our old data, however links to legacy stats are missing.
We have another journal which has legacyCounterPlugin rows and legacy links appear in the counter report page. I was wondering how this should be possible as we expected the two journals to be setup similarly (both of them having legacy counter data)
Timed View Stats creates a file with no data even if I tick the checkbox to use the old Timed View Plugin data.
As described in the documentation here: http://pkp.sfu.ca/wiki/index.php?title=PKP_Statistics_Framework, the old reports will not grab stats anymore. But you can still use them to generate reports. The only one that will generate reports using the old stats data by default is the View report one. But this one can also be used with the new stats, that’s also explained into the documentation here: http://pkp.sfu.ca/wiki/index.php?title=PKP_Statistics_Framework#Report_Generation
Maybe the legacy data you see in the table is just for that journal that has the legacy links… You check the context_id of the entries that you found in the metrics table and see if both journals have entries there or if it’s just one.
The Timed View stats can be used by default with the new stats data. So you should select a time range that’s appropriate, after the upgrade. Using the old stats means you need to have old timed view stats, which means you had to be using the timed view plugin before the upgrade. You can also check for timed view old stats data querying the metrics table and searching for the ojs::timedViews metric type.
Thanks for your following this up.
What specific usage stats configuration I need to process my apache access log files?
At the moment I have kept the regex pattern as default:
/^(\S+) \S+ \S+ \[(.*?)\] "\S+ (\S+).*?" (\S+) \S+ ".*?" "(.*?)"/
Two other questions please:
- Would you please advice how can I change the email notifications receipts?
- Can you please confirm that the old data is only accessible via “View Report” and the numbers are not going to increase after the upgrade?
Thanks for your help.
The regex to read the apache log files depends on the format your apache is using for access logs. I can’t help much on this one, but you can look at plugins/generic/usageStats/UsageStatsLoader.inc.php, at _getDataFromLogEntry method, line 324, the information the system expects to get from the log files. That way you can build your regex the way you need it.
The task processing log is sent to the admin email, configured in the site settings page.
As stated in the documentation, there’s different types of old stats data. The view report used to count its own data, as Counter and Timed view plugins also did it. This old stats data is still available, and it can only be retrieved via its respective report. It’s not going to increase after the upgrade.
My apache access log files are in a format like this: YYYYMMDD-access.log
Also would please address my question earlier in this thread regarding Timed View Stats. It creates a file with no data when I tick the checkbox to use the old Timed View Plugin data. Is it supposed to behave like this? This is while I can see the old data in “View Stats”.
Sorry about my too many questions.