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?
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…
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?
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?
I only ran the tool fixGalleyImages.php, Do you have patch? I upgraded ojs 188.8.131.52 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 !!!
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?
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?