I’ve recently released a Hugo port of the Health Sciences theme.
The theme is now listed in Hugo Themes and available for download from Github and you can see a demo here.
What is Hugo?
Hugo is a static site generator that generates all of the content for a website ahead of time so that when someone visits the webpage, the server can just send files without needing to dynamically generate webpages. The result is faster loading times for visitors and less load on servers.
Why Use This?
Static content is ideal for situations where the website is the same for every visitor - no login is required - so it is ideal for open access journals. For OJS users, a static version of the website may be useful for:
- Creating a mirror of the journal’s content, which readers can be redirected to if the main journal is offline for any reason (e.g. server problems or during OJS update)
- Separating the front-end and the back-end, so that content can be served to readers separately from the OJS submission system
- Mimics and OJS journal running the Health Sciences theme
- Fully functional journal webpage with tables of contents and article pages, ORCIDs, abstracts, keywords, funding and license information
- Metadata embedded in HTML landing pages with
meta tags for Dublin Core and Google Scholar and COinS for Zotero
- Export citations in RIS, BIB and CSL-JSON.
- The option to embed Crossmark links in article landing pages
- Mimics the OJS experience of reading PDFs in-browser and XML articles in Lens
- Lens has been modified to show a journal logo with a back button to take you back to the article landing page
- I haven’t implemented the way OJS renders HTML galleys yet, but if you are interested in this feature please let me know
- In conjunction with this theme, we need a plugin that registers the location of ‘remote’ galleys and then injects that information into the OJS OAI repository and potentially metadata exports. I have started fiddling around with development for this, but am not a PHP developer so this will take me some time to learn.
- I am also considering using Hugo’s templating to build in some production tools, either in this theme or in a related repository, which would build Crossref XML exports and frontmatter for LaTeX and JATS XML. For example, you might notice that in the article templates I include places for author affiliations to include ISNIs and RORs.
The theme, like OJS, is GPL-licensed, so please feel free to use and adapt.
This is amazing @shaun! I love seeing what you’ve done here. How are you generating the static content? Are you building each article by hand or are you fetching it using the REST API or directly from the database?
At the moment, I’m doing the article metadata by hand, but feedback I have gotten earlier in this process is that the API would be the best way to import metadata into another system. Another possibility might be to use a plugin, maybe one of the built in export plugins or SWORD, perhaps with some customisation.
So the workflow I envision would eventually be to do everything in OJS except the journal front-end:
- Submit and review on OJS.
- After acceptance, retrieve metadata and galleys from OJS (either by API or plugin) and push to a git repository
- Journal front-end automatically builds thanks to integration with the server or service (I use Netlify’s free plan, but Github or Gitlab pages would also be good options).
- Metadata deposits and the OAI repository need a bit of tweaking - currently you can either enter a remote URL or upload a galley, but not both. So putting together a plugin that allows you to upload your galleys but also to register your remotes and then inject those URLs into your metadata exports (e.g. Crossref) and OAI repository would be needed.
- Usage statistics would probably need to be done via matomo, since the static site no longer generates the server logs that OJS is looking for (especially if hosted elsewhere).
Yeah the API will be the best place to retrieve the data that you need to transform into markdown. You’ll also benefit from the fact that it is well documented, and changes with each version are documented, so that maintaining that connection over time will be easier than going directly to the database or something.
The galleys are going to be the trickiest part to handle. Instead of trying to wrestle with the remote URL feature, I’d suggest building that into your processing script. Something like:
- Upload galley files.
- When fetching the submission from the API, download the galley files.
- Upload them to your CDN and get the URL.
- Use that URL in your Hugu metadata.
All of that could be automated and you won’t run into any tricky issues with trying to make OJS’s galleys work in a way that they weren’t intended to work.
The metadata exports and OAI will still be a challenge, but I think as long as you go the static site route, you’re probably going to need to handle these separately anyway. You won’t be able to “trick” OJS into using the correct published URL without a lot of bending over backwards.