Ok, so journal 1 has the path sinkron. Can you double-check that the log entry for Nov 13 had some entries for this journal?
It seems like they are not getting stored in the metrics table. I’m not sure what exactly is happening, but at this stage you’ll need to try processing some sample usage event logs to debug.
For example, I nnotice that the URLs for the journal sinkron all contain a double slash before index.php:
http://jurnal.polgan.ac.id//index.php/sinkron/...
If you process the logs without that slash, do you get entries in the metrics table?
Our Admin Guide includes a section on how to process log files. (The important thing to note is that you may need to move the log files out of the archive directory – I recommend just creating a small dummy file with sample usage events rather than the whole thing, while you debug.)
No, leave the Path setting for the journal as it is. It seems like the logs are writing an extra slash into the URL and that might be preventing the usage stats from being processed correctly (it may not know that usage event is related to the sinkron journal if it doesn’t expect the //).
I dont know how to remove double slash
If you read the documentation on processing log files, you can create a log file in the correct folder and then process it. So you can copy the entries in the .log file and manually edit it.
this metric stop counting since December 2019
Do you have log files in the archive directory from before this period? Maybe you can check to see if the double slash was present in earlier log entries.
and automatically that’s folder files/usageStat and files/usageStat/usageEventLog/ created by OJS, but not subfolder such archive, processing, stage, reject, not created.
also error_log contain
[18-Nov-2020 01:49:44 Asia/Jakarta] PHP Fatal error: Uncaught Error: Call to a member function getTitle() on null in /home/polgnac/public_html/jurnal/plugins/generic/dublinCoreMeta/DublinCoreMetaPlugin.inc.php:154
Stack trace:
#0 /home/polgnac/public_html/jurnal/lib/pkp/classes/plugins/HookRegistry.inc.php(107): DublinCoreMetaPlugin->articleView('ArticleHandler:...', Array)
#1 /home/polgnac/public_html/jurnal/pages/article/ArticleHandler.inc.php(280): HookRegistry::call('ArticleHandler:...', Array)
#2 /home/polgnac/public_html/jurnal/lib/pkp/classes/core/PKPRouter.inc.php(391): ArticleHandler->view(Array, Object(Request))
#3 /home/polgnac/public_html/jurnal/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)
#4 /home/polgnac/public_html/jurnal/lib/pkp/classes/core/Dispatcher.inc.php(143): PKPPageRouter->route(Object(Request))
#5 /home/polgnac/public_html/jurnal/lib/pkp/classes/core/PKPApplication.inc.php(279): Dispatcher->dispatch(Object(Request))
#6 /home/polgnac/public_html/jurna in /home/polgnac/public_html/jurnal/plugins/generic/dublinCoreMeta/DublinCoreMetaPlugin.inc.php on line 154
any clue in here to refer write db metric like INSERT INTO METRIC ?
Did you back it up? All of your usage statistics for all of those months were in there to be recovered.
any clue in here to refer write db metric like INSERT INTO METRIC ?
Please read the Admin Guide’s section on how to process log files. This is how you can process a log file so that it is written to the metrics table.
The only remaining step is to figure out why the log entries are not getting recognised correctly. It is probably due to the double slash, so modifying your old log entries to remove the double slash and processing your log files again may work.
The three OJS refer to the same file storage system in config.inc.php . that is
files_dir = / home / polgnac / public_html / files
The three OJS have different Crontab schedules, so the schedule that works for the first time automatically empties the directory /stage so that the two remaining OJS don’t get any logfiles anymore.
The solution I do now is:
each OJS gets a different files directory
Hopefully, I’m not wrong.
Let’s take a look at the results.
I have the same problem with download statistics and PlumX. From some reason they stopped on November, 25. In usageStats/archive last log is from November 25.
In error.log receive
error_log ( ASCII text )
[26-Dec-2020 15:28:47 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 0 [26-Dec-2020 15:28:47 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::execute() should be compatible with Form::execute(…$functionArgs) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 0 [26-Dec-2020 15:28:57 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 0 [26-Dec-2020 15:28:57 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::execute() should be compatible with Form::execute(…$functionArgs) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 0 [26-Dec-2020 15:30:09 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 92 [26-Dec-2020 15:30:09 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::execute() should be compatible with Form::execute(…$functionArgs) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 112 [26-Dec-2020 15:30:15 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::fetch($request) should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 92 [26-Dec-2020 15:30:15 Europe/Belgrade] PHP Warning: Declaration of PlumAnalyticsSettingsForm::execute() should be compatible with Form::execute(…$functionArgs) in /home/ijcadsee/public_html/plugins/generic/plum/PlumAnalyticsSettingsForm.inc.php on line 112
Also, Download statistics stop working. Open Journal Systems 3.2.1.2 is active with PHP 7.3.
Any idea to solve problems with PlumX and statistics?
I never would have guessed that! Good find!
error_log ( ASCII text )