In OJS 2.x, we jam arbitrary HTML into an OJS-style <head>...<body> wrapper, invariably resulting in invalid HTML that's generally happily presented by browsers. Not ideal.
In OJS 3.x, we present whatever the editor etc. has uploaded without wrapping it in anything. This offloads all metadata, layout, etc. work to the HTML production and potentially means a lot of overhead in maintenance (think header/footer design changes). Not ideal.
Figure out an approach that avoids the pitfalls of each. Are iframes still verboten? @NateWr, ideas on this?
asmecher
All 34 comments
Maybe a content editor for HTML versions and saving these to the database or as flatfile to the files directory? This is something that some journals have been asking for and I do understand the difficulties that it presents.
ajnyga
on 20 Sep 2016
We'll likely add something like this as an additional approach -- but we'll also need to support situations where external tools generate full HTML content.
asmecher
on 20 Sep 2016
How about doing some parsing on the fly. I mean load the production HTML. Save everything necessary like CSS styles from the header => remove the header => replace with a new header created by OJS on the fly adding necessary journal styles headers etc. => show the HTML.
ajnyga
on 20 Sep 2016
@ajnyga, yes, that's an option -- but we can't make many assumptions about the XML's format or quality, meaning certain tools like XSL would be off the table.
asmecher
on 22 Sep 2016
So the basic problem is that we need to jam arbitrary HTML into an OJS layout and set of headers. The more I think about a reliable way to merge two HTML documents together, the less I want to try it -- especially as one of them is likely going to be generated by Word or something equivalently standards-averse.
@NateWr, my current best candidate is an iframe. Additional benefits: it would unify the way we're serving up other prominent content types (e.g. PDF, as PDF.js uses an iframe too). Objections?
asmecher
on 23 Sep 2016
Pulls (work in progress, just collecting links):
asmecher
on 24 Sep 2016
Need to...
- Add rewriting (e.g. for images)
- Try an OJS3 example with proper content
- Try an upgraded example (from OJS2)
- Talk layout.
asmecher
on 24 Sep 2016
@asmecher I'm not opposed to an iframe.
My pre-Substance preference would probably be a TinyMCE field in which editors are encouraged to dump an HTML representation of the article body (no title, authors, abstract, etc). References/citation (#1808) and the full article could be displayed right on the article details page.
This would bypass the use of a galley, which feels wrong to me, and would set us up with a collection of fields that would roughly correspond to what we might be able to do with a document generated by Substance in an ideal future.
An iframe could be how we present HTML galleys, as a kind of backwards-compatibility tool so that OJS 2 users get a roughly equivalent display mode for all of their existing HTML files.
NateWr
on 26 Sep 2016
As user I can tell that publishing full article right on article details page is very good idea. It certainly can help to avoid all problems with article indexing. For example all my rich metadata in my JATS XML that displayed by Lens are lost in the front end. Partly because of plugin structure and partly because of use as Galley (dont think google will indexing galleys right even in presents of metadata). I think that Ideally galleys should be bypassed in favor to full article html with rich metadata (that came from JATS) just on article page. But to done this there is a need of new plugin that would transform JATS XML to HTML because I dont think that Lens viewer is appropriate candidate for this purpose.
Vitaliy-1
on 27 Sep 2016
@Vitaliy-1, is your experience with poor indexing in regular Google, or in Google Scholar?
asmecher
on 27 Sep 2016
I checked Lens xml indexing in regular Google. As for google scholar - I see there only data for view article pages and references to pdf galleys.
For not to be misunderstood: My own experience on using this platform is limited by OJS3 (1 month or so). We have published several articles before official launch that were submitted to us earlier. Just after OJS3 release. They all are in google scholar now (good) and article pages in google. But XML is not in google scholar. I see in regular google only reference for one article`s xml like "XML - myJournalTitle". Its not even title of that transformed html page. Or maybe I just need to wait...
Vitaliy-1
on 27 Sep 2016
The article title issue has already been corrected in github -- see this change:
https://github.com/asmecher/lensGalley/commit/1c1477b428500a6654982a409ee9d970acb1996d
asmecher
on 28 Sep 2016
I already done that and article title in JATS XML is correct now. Maybe it needs some time to change.
To be more specific: google scholar do not provide the link to Lens JATS XML, like it does for PDF.
Vitaliy-1
on 28 Sep 2016
Ah, OK. Google Scholar has specific meta tags for HTML and PDF, but I don't think it has one for XML. That would explain why other document types aren't indexed.
asmecher
on 28 Sep 2016
Lens viewer makes html from xml on the fly. So I see only 2 options for embedding full JATS oriented publishing process in OJS3.
- Transformation of JATS XML into html in external application for using it like a html galley.
- Transformation of JATS XML into HTML with a plugin (which is need to be developed) for using it like a html galley or embedding into article view page.
In my opinion it would be ideally to mimic publishing mechanism from Ambra platform. Transform JATS XML to HTML by some sort of plugin and publish it on the article view page with all JATS metadata. I think there is no need for open access journals to hide full text in galleys.
Vitaliy-1
on 29 Sep 2016
Certainly possible -- but I wonder whether Scholar in particular has a toolset for indexing JATS XML directly. That seems like the kind of thing they'd like to get their hands on. I'll inquire.
asmecher
on 1 Oct 2016
@Vitaliy-1 I'm following two third-party efforts to transform JATS XML into a JSON representation. One is the eLife team, which is working on a stand-alone tool to do just that. The other is the Substance writer project (the tool behind eLens), which I believe can transform XML into JSON and is working on better JATS XML support.
In either case, once we have a tool that can deliver us a JSON representation of the JATS format, I'll be very keen on bringing that full representation to the article detail page so that we can do more exciting things there.
Until then, though, our traditional HTML approach is probably what we're going to stick with, simply because it doesn't make sense to reinvent the wheel when we have a couple of exciting open-source projects working down that path.
NateWr
on 2 Oct 2016
As for HTML. I have made HTML from JATS and CSS for it. For now with iframe css in not working. not if upload it from admin, nor if I change HtmlArticleGalleyPlugin.inc.php and change path to css there. The link to CSS is in the head of a HTML page and it is correct.
Vitaliy-1
on 2 Oct 2016
Is the CSS file's MIME type in your database correct? Check its entry in the submission_files table. It needs to be text/css.
asmecher
on 2 Oct 2016
Yep. You were right. I have changed it to text/css and all worked. Can it be done through dashboard?
Vitaliy-1
on 2 Oct 2016
Not at the moment -- frankly MIME detection of CSS files is problematic and the system often gets it wrong. I suppose we could recommend a specific start to CSS files in order to provide a hint to the system but that seems kind of unreasonable. I think we probably ought to nudge uploads that we know are supposed to be CSS files in order that they get the right MIME type.
asmecher
on 2 Oct 2016
Noticed one more problem. After this modifications (with iframe) I don`t see return button from iframe that is in header:
a href="https://myjournal.com/index.php/psp/article/view/6" class="return"
Vitaliy-1
on 2 Oct 2016
Attached screen. Upper - what I see on bootstarp theme and lower - on default.
Vitaliy-1
on 2 Oct 2016
Also this frame disappears when I click any internal href link. This is true for Chrome and Edge, but not Firefox.
As for iframe header on screens - it looks normal now. Dont know how it was fixed. But the frame still disappears after clicking any internal link in html.
by modifying css in Chrome "inspect" it is possible to retrieve back return link. but I dont know where css (or less) file situated to make this change real.
Vitaliy-1
on 2 Oct 2016
Greetings,
After testing iframes for HTML Galleys we decided to move forward without it. It looks like the problem described above was specific to iframe, so it is impossible to implement more or less appropriate navigation with it.
For about html Galleys I would like to know is it possible (without iframe) to link to an html article an external javascript, because iframe blocked all external links in html somehow ? We have developed a simple javascript code and would like to place it in web access directory for using in every HTML Galley. It is very simple and convenient to use javascript for in-article navigation and adapting html for mobile devices.
Vitaliy-1
on 5 Oct 2016
@NateWr, any thoughts on the navigation problems @Vitaliy-1 mentions? @Vitaliy-1, I suspect the javascript across iframes issue is related to CORS (Cross Origin Resource Sharing) rules, which is a big subject -- but @NateWr might also have a few quick thoughts on that.
asmecher
on 5 Oct 2016
I would agree that's probably the issue that's happening here. I'd recommend making sure that the URL you're viewing, the URL the iframe is loading and the URL of the JS file are all on the same domain.
If that doesn't help, you can send a link with the problematic HTML galley and I'll have a poke in devtools to see if anything jumps out at me.
NateWr
on 10 Oct 2016
Note to self: When this is ready, back-port to ojs-stable-3_0_0 and apply to the demo install(s).
asmecher
on 15 Oct 2016
Greetings,
I had added JS like external file with full link in the head of html. JS file was not downloaded as routing from "upload" form but manually in the web access directory with all needed permissions. For now we are not using iframes for html galley so I cannot check this issue once more.
As I see from pdf galleys, iframe blocks all external urls (and in case of html it has problems with internal). We use latex for pdf and have working doi and links to full text in references which can`t be reached under iframes.
Vitaliy-1
on 16 Oct 2016
@bozana, could you review https://github.com/pkp/ojs/pull/1027? I've already merged it and back-ported to ojs-stable-3_0_0 (bad habit!) but it could use a look.
@Vitaliy-1, if you send me some samples of HTML galleys (including dependent files) that show the navigation/JS problems, I can take a more specific look.
asmecher
on 17 Oct 2016
@asmecher, sorry for such a delay :-( I've just taken a look and have a few very minor comments/questions...
bozana
on 8 Nov 2016
Thanks, I fixed things up per your review!
asmecher
on 15 Nov 2016
@asmecher good day, I have a problem, I try to preview the HTML as galley but the iframe does not take it, I practically leave it blank and it does not show me anything of the HTML file, is there any solution?
in the table submission_file text / html appears.
I am managing the version of ojs 3.1.1.4 thank your collaboration
this is my HTML content
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Test Document</title>
</head>
<body>
<h1 class="center">Hello I am Test Document</h1>
<br>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Error repellat facilis necessitatibus, accusantium culpa aspernatur ut dolorem dolore provident perspiciatis, esse quos voluptas iste quo ipsam ipsum ducimus. Labore, est?</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Error repellat facilis necessitatibus, accusantium culpa aspernatur ut dolorem dolore provident perspiciatis, esse quos voluptas iste quo ipsam ipsum ducimus. Labore, est?</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Error repellat facilis necessitatibus, accusantium culpa aspernatur ut dolorem dolore provident perspiciatis, esse quos voluptas iste quo ipsam ipsum ducimus. Labore, est?</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Error repellat facilis necessitatibus, accusantium culpa aspernatur ut dolorem dolore provident perspiciatis, esse quos voluptas iste quo ipsam ipsum ducimus. Labore, est?</p>
</body>
</html>
jhfredy
on 15 May 2019
@jhfredy, could you post this question on our support forum (https://forum.pkp.sfu.ca)? That's the best place to post this kind of question.
asmecher
on 15 May 2019
Related issues
ajnyga
路
7Comments
asmecher
路
8Comments
sssoz
路
3Comments
alexdryden
路
4Comments
mtub
路
6Comments
Most helpful comment
@asmecher I'm not opposed to an iframe.
My pre-Substance preference would probably be a TinyMCE field in which editors are encouraged to dump an HTML representation of the article body (no title, authors, abstract, etc). References/citation (#1808) and the full article could be displayed right on the article details page.
This would bypass the use of a galley, which feels wrong to me, and would set us up with a collection of fields that would roughly correspond to what we might be able to do with a document generated by Substance in an ideal future.
An iframe could be how we present HTML galleys, as a kind of backwards-compatibility tool so that OJS 2 users get a roughly equivalent display mode for all of their existing HTML files.