before I choose working solution, would like to ask if there’s also some other/nice once. I have a challenge, that I need to “share” same articles (with PDF and some also DOI) in two issues. Solution is that I can publish second issue and upload once again same articles and so on.
But was thinking if this can be done in DB. I looked at table publication_settings where it said in which issue (setting_name = issueId, setting_value) is article (publication_id). My idea was to make duplicate rows with new issue ID, but there’s a problem due to indexing (of course!). So was following up some relationship and come up to six tables that I would need to make manually records (duplicates with some ID changes). Which is not such a problem as I have only 3 new issues and each with approx. 25 articles.
But before I try this, would like:
that somebody stops me
to know if this would work
is there any working solution for that kind of challenge
not to hear that the best solution is to upload articles once again
I think you’re going to cause yourself endless headaches trying to do this!
So, technically, this is possible using the versioning system. Each version is assigned to an issue, so in theory you could have two versions assigned to the different issues.
But really, I think this will be a nightmare for you in the long-run. To do this right, you’d need to rework how versioning is displayed to the reader, to indicate that the versions are the same but assigned to different issues. And fair warning, we may move the issue assignment back from the publication (version) to the submission. I designed the versioning system to be really flexible to support cases like this, but in hindsight I think it’s overly complicate the code and we may not stick with it.
So there are all my warnings for you!
It might be worth stepping back and asking what use cases you need to fill. Is this about the article metadata that’s sent to somewhere like Crossref? Is it about the meta tags that appear on the article’s landing page? Or is it just about making this thing appear, visually, in the table of contents in two issues?
Depending on what you need, there may be simpler options.
We had a problem at some (3) issues from the 80s where “year of issue” was (as example) 1985/86. As field for year is integer (year! ) we’re unable to make it “1985/86”. So, I made changes in two files (Issue.inc.php and issue_summary.tpl) with adding if…else to show year correctly for those issues.
I am not certain if this is the best solution. But it’s working, and it’ll be easily implemented at next versions of OJS.
Ah, ok, I see the problem. I suspect this might cause issues down the line. Are you depositing metadata somewhere like Crossref? What does the metadata for Google Scholar look like? You may want to check whether whether the non-integer year is causing problems.
If it is a problem, then I would recommend giving these issues a single year as the “year of issue”, and then adjusting the display in the theme template only (a child theme can be used to isolate this change from others and reduce potential breakage). However, if there are no issues with downstream depositing services, then you’re all set!
I think you’re going to cause yourself endless headaches trying to do this!
) we’re unable to make it “1985/86”. So, I made changes in two files (Issue.inc.php and issue_summary.tpl) with adding if…else to show year correctly for those issues.