I am setting up a test environment using OJS 3.5.0-1 with PostgreSQL 17.6, but the system is not generating any access log files inside the /usageStats/usageEventLogs/ directory.
Data collection is enabled in the OJS settings, and there are no related error messages in the Apache logs.
The directory permissions also appear to be correct, but the log files are still not being created.
Does anyone know if there are additional steps, cron tasks, or configuration changes required for usage statistics to work properly in this version of OJS?
Update:
I have now conducted the same tests using OJS 3.5.0-2 (with PostgreSQL 17.6), and the issue persists exactly as described above.
No log files are generated inside the /usageStats/usageEventLogs/ directory, despite usage data collection being fully enabled and no errors appearing in the Apache error log.
File permissions remain correct, the path is properly configured, and the system behaves identically in both versions (3.5.0-1 and 3.5.0-2).
At this point, it appears that the Usage Statistics plugin is not producing any logging activity in the 3.5.x series under these conditions.
If there have been any recent changes to the logging mechanism in OJS 3.5.x — or if an additional task, configuration step, or scheduled process is now required — I would greatly appreciate any clarification or guidance.
I’d like to add an important detail to this discussion.
To rule out any server-side or configuration issues, I performed two tests using OJS 3.5.0-2:
Fresh install test
I deployed a clean installation of OJS 3.5.0-2 on the very same server (same PHP version, same PostgreSQL 17.6 instance, same filesystem permissions). Result:
Usage statistics work normally — log files are created in usageStats/usageEventLogs, moved to stage, and processed as expected.
Upgrade / migration test
However, when I run an upgrade test using the same codebase and migrate an existing OJS installation to 3.5.0-2, the usage stats system stops working completely:
No log files are generated in usageEventLogs
Nothing is moved to stage
No entries appear in scheduledTaskLogs
Permissions and ownership are identical to the fresh install
salt file exists and is readable
No related errors appear in PHP or webserver logs
Since the fresh install works, but the migrated instance does not, it looks like something in the upgrade process might leave the usage statistics subsystem inactive or improperly initialized.
If anyone has insights about what part of the migration could affect the usage stats logging mechanism (e.g., task registration, job runner configuration, leftover plugin metadata, database flags), I would appreciate any guidance.
Hmmm… Strange…
From which version are you upgrading?
Just in case: Because you said “Usage Statistics plugin is not producing any logging activity…”: Do you still have the UsageStatistics plugin? – It should be removed – the usage statistics are moved into core in 3.4.
But maybe you do not actually have it, because you managed to run the fresh install without problems…
When you do the upgrade you do not get any errors?
Actually the upgrade should not affect the log file creation after the upgrade
Log file creation and writing in the log file happens in the core, by an event listener, that listens when a web page is requested by the user. So nothing special is needed here, except the right file and folder permissions. Also, the user should not have the option “do not track” set in their browser – in that case the usage will not be tracked.
Are your settings in the config.inc.php correct? The base_url and files folder?
Then, for log file processing, the scheduled task UsageStatsLoader is called, that creates lots of jobs. Per default the system internal scheduler and job runner are used, to run the scheduled tasks and jobs. But, maybe first we need to figure out why the log files are not created correctly.
No, this is not the right behavior. I have just tested it locally, the abstract page views are logged, also the PDF viewing in the browser (if the whole file is visible i.e. downloaded in the PDF viewer), also the journal index page.
So I am wondering why it is not working for you…
Regarding the processing of the log files: could you try not to use cron and to use the default settings in your config.inc.php, and maybe first with the fresh installation:
[queues]
job_runner = On
Fresh install test
Upgrade / migration test
