The upgrade history is…
2.3.4.0
2.4.2.0
2.4.7.1
The database upgrade was OK, the counter_montly_log table is used by the statiscCharts plugins, that show the total number of download article by month and year that is necessary to show the download history of the journal, not only by article.
Did you manually add the timed_view_logs and counter_monthly_log tables back into the database?
You will want to update the StatisticsChart plugin to use the new metrics table, if you wish to continue using it with the new version of OJS.
yes, the system administrator do, this is the temp solution to the problem.
Are there incompatibility with metrics concept? If we dropp the statisticChart plugin the problem with statistic of download PDF is solved?
After 2.4.3, only metrics will be collected. In the upgrade to 2.4.7-1, all old statistics should have been converted to metrics. I suspect your administrator has modified the .php or .tpl files to try to add the Views count back in after the upgrade. This will need to be based on the new metrics.
See this earlier conversation for some code suggestions:
We have made the modification to show the abstract view, based in the code that you suggest, but in the case of download files the value is 0, and is not implemented.
I notice that in the system log files only abstract views are colected.
I need to solve the situation. Why in the log files the downloads articles are not colected?
There are a couple of different ways to collect usage events in the latest versions. One should be automatic: the generic plugin “Usage Statistics” in concert with the generic plugin “Acron”. The other is manual processing of your webserver’s log files.
Do you know which method is active for you? Check if both the “Usage Statistics” and “Acron” plugin are enabled; if you have disabled one or the other, have you created specific cron jobs for processing the log files?
If you are looking at your webserver’s access log and not seeing the article galley views, that is odd. Note that the URL will be very similar to the abstract view - with just an additional galley id behind the article id.
These two plugin are enabled and in the case of Usage Statistics the option Create log files are active.
If you look in your ‘files_dir’ location for the folder ‘usageStats’, do you see a couple of current files (today and yesterday) in the usageEventLogs folder, and a lot of daily files in the ‘archive’ folder?
yes, all its ok, the only problem is that the the process for download files are not colected.
If you look at a file in the usageStats/archive/ folder, you see no URLs of the form [$journalUrl]/index.php/[$journal]/article/view/[$articleId]/[$galleyId] ?
If you access an article galley now, do you see that recorded in your current log in usageStats/archive/ ?
No, all have the form [$journalUrl]/index.php/[$journal]/article/view/[$articleId] 200
I dont have access in this moment to the log in the server (generated today), but I have the log files of this month, and all of then have the same form.
What does the URL in the web browser look like when you view/download an article?
For Abstract view
[$journalUrl]/index.php/[$journal]/article/view/[$articleId]
http://revista.ismm.edu.cu/index.php/revistamg/article/view/1117
For dowload file
[$journalUrl]/index.php/[$journal]/article/download/[$articleId]/[$galleyId]
http://revista.ismm.edu.cu/index.php/revistamg/article/download/1203/677
if you want you can visit the journal home page
Hi ctgraham
Which are your conclusions?
I can’t think of a reason those urls wouldn’t be captured in both your usage stats log and in your Apache access log.
I just downloaded article 1203 twice. Once directly and once with a unique string after the galley id: “w95465MFJ4836Ns87m56e53Kv4N5h9PY”. You wouldn’t expect to see that unique string in the usage stats log, but you should at the very least see it in your webserver’s access log. The datestamp will be around 11:30 Eastern, today.
Can you provide snippets of your webserver access log and of your usage stats event log for that time?
This is the lines I found in webserver access log
130.49.185.219 - - [22/Mar/2016:11:24:23 -0400] “GET /index.php/revistamg/article/download/1203/677 HTTP/1.1” 200 359769 “OJS 2.4.7-1 statistical data - #9 by aotero” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0”
130.49.185.219 - - [22/Mar/2016:11:25:11 -0400] “GET /index.php/revistamg/article/download/1203/677/w95465MFJ4836Ns87m56e53Kv4N5h9PY HTTP/1.1” 200 359686 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0”
130.49.185.219 - - [21/Mar/2016:15:51:18 -0400] “GET /index.php/revistamg/article/download/1203/677 HTTP/1.1” 200 259776 “OJS 2.4.7-1 statistical data - #8 by ctgraham” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0”
130.49.185.219 - - [21/Mar/2016:15:52:02 -0400] “GET /index.php/revistamg/article/viewFile/1117/676 HTTP/1.1” 200 40020 “http://revista.ismm.edu.cu/index.php/revistamg/article/view/1117/676” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0”
But in the log in usage stats there is nothing from your IP
1 Like
I think you are running into this error:
It is fixed in 2.4.8. Can you upgrade?
To catch historical statistics, you will want to process your Apache logs instead of the faulty usage stats logs. See this page for details:
https://pkp.sfu.ca/wiki/index.php?title=PKP_Statistics_Framework#Processing_Log_Files
To ensure accurate statistics, you will need to clear the data from the faulty logs from the metrics table, by load_id (the filename). If you have a load from the usageEventLogs and from the Apache logs for the same day, you will be double-counting some statistics.
Yes, in this moment our system admin is maken some test in a secondary server.
I have another question.
It is possible to have a code, similar to this Abstract views, PDF views and Download Stats Made Public 😶 - #6 by Dein, in order to show pre- and post-upgrade statistic by article.
Thank you for your patience
If the upgrade and the reprocessing of the logs is done successfully, you will only have one set of correct metrics. “Pre-upgrade” statistics would be the same as “post-upgrade” statistics.
Ok, but in this case, we need to reprocess all logs from november-2011 (first installation of OJS) until today?, the problem is that I have the doubt of the existence of the logs, my questions is because if the old statistics are in the DB we thought to reprocess only the logs from November 2015 to the present, only the range where the download are not registered.