@asmecher: Our site is not yet public, but i hope it will be soon. I’m testing in an virtual ubuntu box. Is there something specific that i can deliver?
@Vitaliy: Thank you for the tip. The method worked: the html-article is displayed and the iframe scrollbar is away. But there is no scrollbar on the browser either so that you can read just the beginning of the article. I tried Firefox and Chrome both with the same result.
I’d suggest working with a developer tool like Firebug for Firefox to inspect the page elements and styles. If you’re able to put the site up somewhere I can see it, perhaps I can provide some guidance.
Regards,
Alec Smecher
Public Knowledge Project Team
If you click Edit in the Editor’s listing of Galleys for the submission, you should see the opportunity to upload/manage files. This is where you’d upload images/CSS/JS/etc. to go with the HTML. I’d strongly suggest using the latest OJS 3.x release for this – you may need to upgrade.
Regards,
Alec Smecher
Public Knowledge Project Team
Than adding this line to display.tpl (in htmlArticleGalley): {$htmlGalleyContents}
So all your html article content will be downloaded.) it. However I cant scroll down since there is no scroller.
We also had similar problem. Here ist our display.tpl
{**
* plugins/generic/htmlArticleGalley/display.tpl
*
* Copyright (c) 2014-2017 Simon Fraser University
* Copyright (c) 2003-2017 John Willinsky
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.
*
* Embedded viewing of a HTML galley.
*}
<!DOCTYPE html>
<html lang="{$currentLocale|replace:"_":"-"}" xml:lang="{$currentLocale|replace:"_":"-"}">
{translate|assign:"pageTitleTranslated" key="article.pageTitle title=$article->getLocalizedTitle()}
{include file="frontend/components/headerHead.tpl"}
{include file="frontend/components/header.tpl"}
<body class="pkp_page_{$requestedPage|escape} pkp_op_{$requestedOp|escape}">
{* Header wrapper *}
<header class="header_view">
<a href="{url page="article" op="view" path=$article->getBestArticleId()}" class="return">
<span class="pkp_screen_reader">
{translate key="article.return"}
</span>
</a>
<a href="{url page="article" op="view" path=$article->getBestArticleId()|to_array:$galley->getBestGalleyId()}" class="title">
{$article->getLocalizedTitle()|escape}
</a>
</header>
<div id="htmlContainer" class="rot">
{$htmlGalleyContents}
</div>
{call_hook name="Templates::Common::Footer::PageFooter"}
{include file="frontend/components/footer.tpl"}
</body>
</html>
We modified the header and footer includes and remvoed the iframe to embed the html article. The htmlGalleyContents has to be defined in HtmlArticleGalleyPlugin.inc.php as already described
This ist display.css of the HTML-galley plugin. I think the overflow was the critical point.
/**
* plugins/generic/htmlArticleGalley/display.css
*
* Copyright (c) 2014-2017 Simon Fraser University
* Copyright (c) 2003-2017 John Willinsky
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.
*
* Styles for embedded viewing of a HTML galley.
*/
html, body, #htmlContainer, iframe {
height: 100%;
width: 100%;
}
iframe {
padding-bottom: 30px;
}
html, body {
overflow: auto;
}
iframe {
border: 0px;
}
This thread recently came to my attention, as I was working on a stats issue with a hosted site who had modified their htmlArticleGalley plugin in a similar manner. Please be aware that not calling the “download” op when loading the HTML galley contents (which is what happens in the original iframe solution) will result in the usage stats framework not logging a hit on the download. Only the download op generates a stats log entry. If you’ve implemented something like this and have noticed a discrepancy between the usage stats report and something like google analytics, this may be why.
We have a journal who has recently solved this issue by generating a jQuery .get() request to the galley download with the inline?=1 parameter, and then inserting the HTML in the div element, instead of grabbing it in the plugin and then passing it in via a template parameter.
The solution described in this thread worked perfectly for us using OJS 3.1.0-1, but when we recently tried to upgrade to 3.1.2-1, the display unfortunately broke. It seems that display.css is no longer called in connection with the HTML galley display, which results in something like this:
We called @florianruckelshausen and apparently the same workaround still works for 3.1.1-4. Does anyone have any idea what caused this regression?
Correction: we had a mistake in the <div> section in display.tpl. class needs to be "rot", which had apparently changed in 3.1.2-1. With that HTML is displayed correctly as before. We will do some more tests and post any new findings. Here is our display.tpl:
{**
* plugins/generic/htmlArticleGalley/display.tpl
*
* Copyright (c) 2014-2019 Simon Fraser University
* Copyright (c) 2003-2019 John Willinsky
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.
*
* Embedded viewing of a HTML galley.
*}
<!DOCTYPE html>
<html lang="{$currentLocale|replace:"_":"-"}" xml:lang="{$currentLocale|replace:"_":"-"}">
{capture assign="pageTitleTranslated"}{translate key="article.pageTitle" title=$article->getLocalizedTitle()|escape}{/capture}
{include file="frontend/components/headerHead.tpl"}
{include file="frontend/components/header.tpl"}
<body class="pkp_page_{$requestedPage|escape} pkp_op_{$requestedOp|escape}">
{* Header wrapper *}
<header class="header_view">
<a href="{url page="article" op="view" path=$article->getBestArticleId()}" class="return">
<span class="pkp_screen_reader">
{translate key="article.return"}
</span>
</a>
<a href="{url page="article" op="view" path=$article->getBestArticleId()}" class="title">
{$article->getLocalizedTitle()|escape}
</a>
</header>
<div id="htmlContainer" class="rot">
{$htmlGalleyContents}
</div>
{call_hook name="Templates::Common::Footer::PageFooter"}
{include file="frontend/components/footer.tpl"}
</body>
</html>
We just upgraded to OJS 3.1.2-1 and in can confirm that the descibed modifications still work to display HTML-galleys. For us it was also possible to leave class=“rot” out of the code without any effect.
Unfortunately, this solution does not work for us and I don’t know why. After updating the files, when clicking on the HTML galleys, nothing happens. There is only a white screen. What could be the solution?
I have already cleared the template cache.
Are you sure that you are using the relevant version of the plugin? As far as I see, the call to this method was removed before OJS 3.1
I suggest rechecking if it’s the relevant plugin’s version.
I guess we use an old version, but this is part of the problem. The newest version does not work. After clicking on the HTML-galley the galley is not loaded properly.