I am experiencing a critical issue with the Articles Report CSV export in Open Journal Systems (OJS) 3.5.0.3, running on an environment with Nginx and PostgreSQL.
The generated .csv file is not structurally valid and cannot be reliably parsed by standard tools (e.g., spreadsheet software, Python/pandas, or RFC-compliant CSV parsers). The problem appears to be systemic rather than data-specific.
Observed Issues
Inconsistent Column Count
The header row defines approximately 590 columns.
Subsequent rows frequently contain a completely different number of fields.
Example:
Row 2 contains approximately 63,000 columns
Many following rows collapse into a single column only
This indicates a severe breakdown in delimiter or quoting handling.
Broken Quoting / Escaping
Fields containing commas, quotes, or line breaks are not consistently escaped.
Double quotes (") appear improperly nested or unbalanced.
This causes CSV parsers to misinterpret field boundaries.
Multiline Field Corruption
Textual fields (e.g., Abstract, Bio Statement) appear to contain raw line breaks that are not properly enclosed in quotes.
As a result, a single logical record is split across multiple physical lines.
This explains rows with only one column (continuation fragments of previous records).
Row Fragmentation
After the first corrupted row, the remainder of the file becomes desynchronized.
Many rows are effectively partial data fragments rather than complete records.
Encoding / BOM Presence
The file starts with a UTF-8 BOM (\ufeff), which is acceptable but may contribute to parsing inconsistencies depending on tooling.
However, this is not the primary issue.
Performance Issue
The report generation is extremely slow.
Given the malformed output, it suggests inefficient or unsafe string concatenation during export.
Technical Interpretation
The behavior strongly suggests that:
CSV serialization is not correctly enforcing:
consistent quoting of text fields
escaping of internal quotes ( " → “” )
proper encapsulation of multiline content
There may be direct string concatenation instead of using a robust CSV writer.
The presence of large author metadata expansions (multiple author fields) likely amplifies the issue.
Impact
The exported file is unusable for:
data analysis
reporting pipelines
spreadsheet tools (Excel, LibreOffice)
Automated ingestion fails due to structural inconsistency.
Expected Behavior
All rows must have the same number of columns as the header.
Fields containing commas, quotes, or line breaks must be properly quoted per CSV standards.
Multiline text must be enclosed in quotes and preserved as a single field.
Environment
OJS version: 3.5.0.3
Web server: Nginx
Database: PostgreSQL
Request
Could you please confirm:
Whether this is a known issue in OJS 3.5.x
If there is a patch, plugin, or configuration fix available
Whether this has been addressed in a newer release
If there are recommended workarounds (e.g., alternative export methods)
Hello @Tarcisio_Pereira . Thank you for the post. There is a good amount of info to parse through with many points of potential for error. I’m looking into reproducing it locally to find the root cause. Unfortunately, I wasn’t able to reproduce it from the basic sample datasets. I might need your csv file at some point but I don’t want to expose the info. I’m, also, not sure it would help because the file is already corrupt. The issue is likely with the creation of the file.
Just to be clear of the steps to create the .csv file are :
With user (admin/JM/JE) access Go to Statistics > Articles
Select the Download report button (any particular date or filter(s) selected?)
On the Download panel Select > Download Articles
Some questions for you:
Do the other Download options (Download Files or Download Timeline) work as expected?
Actually I think it is in the Report Plugins (Website > Plugins > Report Plugins). I’ll check more in a bit. I couldn’t repro it on Excel or LibreOffice. Might need that file after all, but will arrange for something more secure.
Thanks @Tarcisio_Pereira for the clarity. That is the same report from the plugins section and yes we can ignore any filters. That was my mistake.
I could not reproduce these issues as the file seems to open for me with those programs. When you say the file is unusable do you mean that the file can open but the content is broken? So this would most likely be from the plugin itself not properly parsing special characters in the report and corrupting the data?
The file itself can be opened, but the internal CSV structure is corrupted/inconsistent.
The main issue is that rows do not preserve a consistent column structure. After certain records, the parser loses synchronization due to malformed field encapsulation.
What I observed:
Some rows expand into tens of thousands of columns
Other rows collapse into a single column
Multiline text fields appear to break record boundaries
Quotes and delimiters seem to be improperly escaped in some entries
So the problem is not that the CSV cannot be opened at all, but rather that its internal structure becomes invalid during generation.
This strongly suggests that the Articles Report plugin is not correctly handling special characters, quotes, delimiters, or multiline content when serializing CSV output.
I will send you some representative excerpts from the generated file via private message so you can inspect the malformed sections directly.
