Nothing changed after upgrading and I didn’t changed it too.
In files_dir, in OJS 3.0.2, the html file is in articles/1111/submission/proof/ and the *.css and *.jpg in articles/1111/public.
In the submission frontend, production step,the HTML galley has the html file.
All the HTML galleys are previous the upgrade.
Ah, OK, the HTML looks good
Could you then just tell me if the CSS files are uploaded with each HTML galley file, as dependent of them (in OJS 2.4.x as well as how it looks like in OJS 3 after the upgrade)?
I’ll also test the upgrade now – it seems that it is an upgrade issue for you…
Yes, I tested the upgrade and the HTML galley CSS files are not migrated correctly.
Unfortunately, their automatic repair in the DB is not possible any more after the upgrade, because the relationship to the galley_id is missing. I will try to provide a SQL statement that can be manually executed on both DBs, OJS 2.4 and 3.0.2, to repair it. The files migration in the OJS files_dir folder however will be automatically possible, I think – the CSS files should go to the submission/proof/ folder.
Thank you for your time and attention to this!
The CSS files where uploaded with each HTML file, not apart of them.
I’ve checked the issue you opened, and when you think it is ok, I will run the 3 SQL statements and the upgrade. OR wil lthe upgrade tool break something?
I see you upgraded the issue, thank you!
First I’ll execute it in a test environment where I already corrected the HTML images issue, and I’m curious to see how it goes. As soon as possible I’ll let you know!
I’ve performed the test but it didn’t work…
I had to create and dump the ojs2 DB.
The moveCSSFiles.php script ran smoothly but in the end the files are in the same folder and not renamed.
The SQL statements didn’t throw error, but the first one was the only that didn’t affect any row.
Hmmm…
OK, if the first SQL did not work, the tool script will not work as well – it is required that the SQLs are applied successfully.
So lets check your initial situation and why the first SQL did not work:
Do your CSS files in the OJS 3 DB table submission_files have genre_id = 1 after that upgrade that did not consider the CSS files migration?
Do you have a genre with entry_key = STYLE for that journal i.e. for all your journals (s. the column context_id) in your OJS 3 DB table genres?
After the first SQL is executed, the CSS files in your OJS 3 DB table submission_files will then have that genre_id.
Do your CSS files in the OJS 3 DB table submission_files have file_stage = 1 after that upgrade that did not consider the CSS files migration?
After the second SQL the CSS files in your OJS 3 DB table submission_files should have file_stage=17.
After the third SQL the CSS files in your OJS 3 DB table submission_files should have assoc_type = 515 and assoc_id the correct HTML galley file ID.
EDIT: the HTML galleys are handled differently in OJS 3 – they are now standalone files and displayed i.e. downloaded as they are. Thus it seems that they should always contain their CSS. @asmecher, that way (either using the htmlArticleGAlley plugin with the iframe or just using the article download) also the OJS journal CSS is not applied to the HTML files. Just in case the htmlArticleGAlley plugin is used and the iframe removed, as @Enzo reported.
Shall this be so?
I don’t have a strong sense for how the styling expectations for article HTML and OJS interact. OJS 2.x used to exert heavy influence on article styling by jamming the article’s HTML (illegally) into an OJS-styled page, but that wasn’t a good solution and I’m not sure it met anyone’s expectations. I’d suggest we leave it as is and respond to user feedback if they expect e.g. OJS styles to “infect” article styles more heavily. My suspicion is that they won’t.
Regards,
Alec Smecher
Public Knowledge Project Team
I’ve got your point but my problem in this working phase is upgrading a journal site with hundreds of html articles without an internal css link because of OJS2 made it useless.
So I should have modify all the old html files adding a css link. Not exactly fun.
Do your CSS files in the OJS 3 DB table submission_files have file_stage = 1 after that upgrade that did not consider the CSS files migration?
Yes. But after the fix you supplied, they are all file_stage = 17 now (as you mentioned).
After the third SQL the CSS files in your OJS 3 DB table submission_files should have assoc_type = 515 and assoc_id the correct HTML galley file ID.
Yes, all CSS files have assoc_type = 515 and the HTML galley file ID is correct in relation to the submission ID and CSS file ID (eg, in table submission_files: file ID=11058; submission ID = 2713; assoc_id = 11057)
It’s in fact a weird event, even more because that journal and others that have the same key issue, are some of the more complete, active and older journals. Thank you for your attention to this!
(checked all those files and they are the same in my installation)
My appologies @bozana but testing a full upgrade won’t work because there were so many problems with that process that it isn’t a pratical and responsive approach for me at the moment.
I was waiting for your reply to ask this, but can’t I manually correct those key values in the genres table to see if it changes anything? Or should it be through a different kind of fix?
Fixed the key values and checked other submission details. The problem is the migration and renaming of the files, tested with one article and the HTML is presented as it should (finally!). The script throws no errors so I don’t see why it doesn’t move the files. There are a lot of them but at least it is a solution!
Thank you for your time and thought into this!