OJS HTML articles

Hello @bozana,

The HTML galley files, when in OJS 2.4 and after upgrade to OJS 3.0.2, have the header

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<link href="the article name.css" rel="stylesheet" type="text/css" />
</head> 

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.

Thank you,
Best regards

Hi @digitojs

Ah, OK, the HTML looks good :slight_smile:
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…

Thanks,
Bozana

Hi @digitojs

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.

Please track this GitHub Issue for fixes: HTML galley CSS file migration · Issue #2758 · pkp/pkp-lib · GitHub

Thanks!
Bozana

Hi @bozana,

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?

Thank you!
Best regards

Hi @digitojs

You could execute the steps described in this comment: HTML galley CSS file migration · Issue #2758 · pkp/pkp-lib · GitHub.

Let me know if you have any question about that, do not forget to make a backup!!! and let me know if that worked…

Best,
Bozana

Hi @bozana,

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!

Best regards

Hello @bozana,

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.

Did you experience this?

Thank you!
Best regards

Hi @digitojs

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.

Thanks!
Bozana

Hello @bozana,

sorry for the lag. I’ll get back at you with feedback as soon as possible.

Thank you!
Best regards

@bozana, in response to your earlier question:

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.

Hi, Enzo

Hi @Enzo,

If the articles are consistently generated, you might be able to work with a tool like sed to process them in batch and add the missing CSS link…

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @bozana,

The feedback I’ll give you, and your questions, is based on the current state (after the first images fix and the SQL and movecssfiles.php fix).

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?

Yes, all CSS files have genre_id = 1.

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?

No. The entry_key = STYLE is only in some journals, not all, and not in the journal (context_id 26 in print below) with this CSS issue.

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)

So, seems table genres is the problem?

Thank you,
Best regards

Hi @digitojs

Yes, table genres is the problem. I will have to investigate how it could be that you do not have those keys…

Thanks!
Bozana

Hello @bozana,

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!

Best regards

Hi @digitojs

Hmmm… Looking into the code I cannot figure out why you would not have those keys in your DB table genres :-
The function that installs the new genres in the upgrade script is called here: ojs/upgrade.xml at ojs-3_0_2-0 · pkp/ojs · GitHub. And implemented here: ojs/Upgrade.inc.php at ojs-3_0_2-0 · pkp/ojs · GitHub i.e. here: pkp-lib/GenreDAO.inc.php at ojs-3_0_2-0 · pkp/pkp-lib · GitHub.
And there everything seems to be OK.

I tested the upgrade, but with the master branch code, and everything was fine.

Hmmm…
Would it maybe be possible for you to test the upgrade once again and watch that function and result?

Hmmm…
Else, no idea… :_\

Best,
Bozana

Hi @bozana,

(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?

Thank you for your time,
Best regards

Hi @digitojs

Yes, yes, you could manually fix those values…

Best,
Bozana

@bozana,

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!

Best regards

Hi @digitojs

Glad it’s working now! :-)))

I didn’t understand: did the Upgrade::moveCSSFiles() function worked, that should move the files?

Best,
Bozana