We are using OJS version 3.5.0-4 and have encountered an issue with the issue table of contents.
The articles within an issue do not maintain a consistent order. Each time the page is refreshed, the articles appear in a different sequence, as if they are being sorted randomly.
I wonder if the lack of page numbers might be throwing this off. I noticed you have numbers like 0302, 0304 associated with your articles on the side - what are these?
Those numbers (e.g., 0302, 0304) correspond to the article number, not to page numbers. We no longer use sequential pagination across all articles published within an issue. Since there is currently no specific metadata field available for article numbers in our setup, we use the pagination field to declare them.
Thanks for clarifying. It might be worth testing to see if you removed these from the page number entries and test if this problem still occurs? I should note as well, that this isn’t really how the page numbers field was intended to be used (for example, it could cause issues for automated citation generation). Using the page numbers field in this manner where there aren’t actual page numbers may have unintended consequences - this may be distinct from the issue you are experiencing, but I did want to let you know that as well.
Thanks for your suggestion. We performed additional tests and found that the issue does not appear to be related to the way the pagination field is being used.
What we observed is that when the articles remain in their default order, the table of contents does not consistently preserve the expected sequence. However, after manually reordering the articles and saving the changes, the articles are displayed and retained in the correct order within the issue’s table of contents.
Based on these tests, it seems that the “misuse” of the pagination field was not the cause of the problem. Our current assumption is that OJS may not be reliably preserving the original submission or insertion order of articles when the default ordering is used.
I’m flagging one of our team members here @grierb - in case this warrants some quality assurance review on our end.
The page numbering may not have been the cause of the issue, but please note that it would be advisable to not use the page numbers field for anything other than specifically page numbers. As it turns out, this may not be related to your issue, but, I am just pointing out it is not good practice to use metadata fields for uses other than what they are intended for, as this may affect things downstream (e.g. reporting metadata to Crossref for DOI registration, or indexing services etc., because this metadata may be automatically picked up as page numbers, despite it not being actual page numbers.
Looks like there are a few issues around this problem here. I don’t believe this was fixed and I have added a milestone for it to be looked at.
Here is one for the sort order. Which would be my suggestion is check the Sort order under Issues > Issue Triangle > Edit > Table of contents > Order and try moving one around and saving. This might reconfigure the sort order to fix any seq values that are conflicting.
There was one that that already dealt with some race conditions but should have already been in 3.5.0-4 so these might not have fixed the underlying problem.
