Hello all, @asmecher, @NateWr, @ctgraham
I’m having the same problem as in post https://forum.pkp.sfu.ca/t/section-order-in-issue/50426
Reordering sections was done in the database, so they are displayed in the sections list correctly.
However, the sections are misplaced in the table of contents, and the Ordering within section configuration and Table of Contents isn’t working within the editors interface (I have multiple roles within multiple journals!).
OJS 126.96.36.199 is in use.
Checking the database, data seems to be fine:
| submission_id | section_id |
| 5508 | 230 |
| 5510 | 230 |
| 5511 | 230 |
| 5518 | 231 |
| 5522 | 231 |
| 5523 | 231 |
| 5524 | 231 |
| 5525 | 232 |
| 5526 | 232 |
| 5530 | 232 |
| 5531 | 232 |
| 5532 | 232 |
| 5513 | 233 |
| 5516 | 233 |
| 5517 | 233 |
But they are being displayed all messed up in the issue table of contents form, as well as in the public page:
I managed to fix my ToC manually in the database, setting the section orders and article orders.
If there’s a patch to fix this issue, as it seems the code is savind the ordering incorrectly, please let me know as I couldn’t find any at GitHub.
We encountered the same bug in the modification of the order of sections inside an already published issue.
One of our journal editor created a new section and added it in an already published issue as a replacement of another section, it appeared that this new section came at the bottom of the Table of Content of the issue. Modifying the order was not possible.
We noticed in the “custom_section_orders” table that a new entry was not created as expected, preventing the reordering. We also noticed that the empty section was still present in that table.
We solved the problem with this little change on the database:
- go to the “sections” table to identify the “section_id” of the newly created section
- go to the “issues” table to identify the “issue_id” of the issue in which the new section appears
- go to the “custom_section_orders” table and add a new row with the “issue_id”, “section_id” found and give a greater number for the “seq” field than the others issue sections
If there is a section that is no longer used in the issue (this was our case) we don’t need to create the new row, we can simply update the row with the “issue_id” and “section_id” no more in use. After this creation or modification of the table “custom_section_orders”, it becomes possible to change the order in the admin interface again.
We also discovered that the addition of a new section in an already published issue, duely unpublished to make the change, didn’t create a new line in the table. So:
- the removal of a section doesn’t delete the entry in the database
- the addition of a new section doesn’t create a new entry in the database
Hope this helps to correct that bug.
Thank you @claivaz !
I followed your instruction and it was a bit hard to identify the “section_id”, “issue_id” but I figured it out as shown in attached screenshot. It works!
Much appreciate your sharing.