After the upgrade to 3.0.2, the HTML articles that were fine in the previous install didn’t preserve the style and image files. The files are in the DB and files folder, but the the HTML display isn’t correct. I’ve tried to understand but without success…any suggestion?
I believe that’s already fixed, and will be released in the next version of OJS. For details on the fix, and a tool to apply the fix for existing 3.0.2 installs, see issue 2582.
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you for your answer.
According to this fix, I need to change that files in the commit and then create and run that script? I really didnt want to perform an upgrade process, or similar, but I was aware of something like this…
Yes, you’d need to apply the code patch, then run the tool at the link above. The tool is provided so that you don’t have to e.g. run a full upgrade process to fix the files.
Of course, take a full backup before doing any of these steps.
Regards,
Alec Smecher
Public Knowledge Project Team
The thing is that my files, of the 3.0.2 stable release are a bit outdated of the ones presented in this branch. I don’t want to mess anything up,so should I change only the lines affected in that commit?
Yes, you can use the patch tool to just change the required lines. Then you’ll need to run the tool in the link above. Please back everything up before you do so.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, I have the same problem and I tried the solutions about 2582 but after I ran the file from tools/fixGalleyImages.php, the HTML display isn’t correct, it’s the same than before. The logs never show me what is happening when I ran the fixGalleyImages.php or when I can open the files in HTML, Do you have any sugestions?
Hi @asmecher,
I only ran the tool fixGalleyImages.php, Do you have patch? I upgraded ojs 2.4.8.1 to ojs 3.0.2, than after the upgrade the version 3.0.2 I can’t see the images from html files. I don’t know what is the patch than you ask me. Can you send me the link for the patch? thanks for all !!!
hi @asmecher,
sorry I’m not expert user. Really I don’t see the patch. maybe i need to run that tools/upgrade.php patch ? or what is the steps for download and apply the patch, Can you help me please?
Hi @asmecher,
I ran the fixGalleyImages.php and the problem is solved. I see the images in the html files. thanks for your patience and your help. Really thanks !!!
I’ve tested it and he fix was successful, the images are associated again and without problems. Thank you! Although, the css isn’t and I don’t see what could be wrong, no errors, nothing was recorded. @asmecher, @Enzo, @JCar did you experience this?
This is an example of an article in the test I’m performing.
Should those values be like that for the css file?
Edit: I checked and for what I realized those values aren’t correct, and it’s a problem that resulted from upgrade. Tried to change them manually, but didn’t make a difference either.
Best regards
I’m not sure it’s the best solution but the use of iframe tag to import the HTML files made impossible to apply CSS style to them (in display.tpl the journal CSS is loaded externaly from iframe).
I guess there is a valid reason of using iframe in OJS 3.0 but I couldn’t avoid to remove it and import html directly in div id="htmlContainer".
Waiting for a better solution (maybe in the next release).
Thank you for showing your solution @Enzo ! Unfortunately it doesn’t work totally. As I’d seen in other topics in the forum, the iframe is removed for this purpose and the style is recovered, but what I experience is an halfway result. It indeed gets the css, but the css that we upload in the journal admin options, not the css of the html. I’ve been around this but without success for now.
Edit: previously I posted a DB print ensuring the file type, and in inspector
At the same time it is related with the error log:
PHP Fatal error: Call to a member function getRemoteURL() on a non-object in /var/www/html/pages/article/ArticleHandler.inc.php on line 230
but when removing iframe it is gone. Or should I apply the commits open for this issue?
Edit2: browser inspector throws
The stylesheet http:/*****.css was not loaded because its MIME type, “text/html”, is not “text/css”.
In php.ini, changed default_mimetype = “text/html” to default_mimetype = “”, but didn’t work.
I’ve just tested the CSS integration within HTML galleys with the latest OJS code and it works if you have embedded the CSS in your HTML code, something like: <link rel="stylesheet" type="text/css" href="article.css">
and if you have uploaded article.css file as the HTML galley dependent.
(This is also how OMP functions.)
But, I am not sure if the OJS 2.4.x users had that line in their HTML code… – @digitojs, do you have such a line in the header of your HTML galley files?
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?