This is a bit of a theoretical question to do with the API. I am curious if it would be feasible to run OJS as a headless CMS, with the front-end being rendered separately.
This entails decoupling the content management from the website itself, pulling the relevant data via the API. This is often done using a front-end framework like Gatsby or HUGO to render the website, hosting it using a serverless service like Netlify.
We use this on another of our websites, where we use Forestry to create .md files which are stored on Github. Then we pull those into Gatsby on Netlify.
The benefits are numerous:
Increased performance by leveraging CDNs and load balancing in a simple way
Reducing the attack vectors of the front-end website to near-zero
Requiring less server resources, as the server isn’t publically accessible
Other data sources can be easily combined like a Ghost blog or Markdown files.
As I was writing this, I came across a similar topic that discussed a related question about exporting to Markdown:
As was mentioned there, going through the API is the way to do it. So I’m wondering:
Has anyone had any experience rendering OJS articles with a static site generator? Are there other methods and approaches in use?
@shaun Are you still working on this? I saw the repo has been updated a couple months ago, but I wasn’t sure if Hugo was actually being used on the front-end. I’m curious, has it worked for you? Are there any strategies for SEO, handing the different websites together? I’m curious if you’ve tried proxying certain pages to OJS with Netlify _redirects for instance, if that would be possible.
The theme is live in the Hugo theme directory and I am planning to add features over time.
I do use it to render a static mirror and it works really nicely. However, I haven’t seen it indexed by Google Scholar (possibly because I use the canonical meta tags). In theory, you shouldn’t have a problem with indexing as long as you allow Google Scholar via robots.txt. Since it renders static HTML you can also verify for yourself that contains identical meta tags to what OJS would output.
I have not been developing the Hugo theme a lot because right now I am working on another project. However I think I should be able to write something to pull metadata from the OJS API and then generate a md file for this theme. I also have plans to add the RSS feature. It just depends on how much ‘spare’ time I get!
However, I don’t yet know how to deal with the OAI-PMH function. OJS doesn’t point to external URLs in its OAI repository - it will just give a URL that redirects, which I have found may not work if you have set your site not to display publicly. One of my first thoughts was to write a plugin that modifies the OAI repository in OJS, but now I am thinking that it might be easier to write something to do the OAI repository separately. Possible options are Netlify Functions or Ruby…
Interesting, thanks for the details. This does seem like something I’d like to do eventually for our project. I’ve been holding off so far because the performance is excellent for the scale we’re operating on. Low visitors mean hosting is affordable and doesn’t act as a bottleneck. I am curious about this for the future though, as it would be interesting to provide a separate CMS for others to edit certain pages (more advanced than the static pages plugin).
For OAI, going with a serverless function sounds interesting if you want to handle it custom. Netlify is releasing some things around edge handlers that might be interesting for this. Otherwise to work with OJS in that regard, I wonder if Netlify proxying would work, and then only allowing Netlify to access the public site.
You could, with a bit of work, match your paths in OJS to the static site and then write a few quite general rules for Netlify and/or server redirects. I think you would need to put your OJS submission site on a different subdomain and then I think if your base URL is used by the OAI repository, then it should point to your front-end on Netlify. Otherwise, you could have your server redirect to the front-end for certain pages. Netlify redirects would then strip index.php (if you still have it) and send any requests to the API or OAI repository back to your OJS subdomain.
I think I will try this out - it seems like one of the least painful options for separating these components.
That’s a good idea. Was just watching a Netlify talk this morning that talked about wildcard redirects. You can soft-redirect everything to the main server, then just implement each page to your Netlify build. It will first look to see if there is an appropriate route within the Netlify build, then if not it will fall back to the old server. Could make for a nice easy transition as certain pages (archives, home, etc) are converted to jamstack.
I am very interested in this topic. I have a new journal that is using OJS primarily as a submission management system. We have a separate journal website I built with Hugo. I’m planning to setup a production workflow that uses Pandoc to convert manuscripts from DOCX to Markdown, HTML (via Hugo), PDF (via ConTeXt), and JATS XML (I think Pandoc could also generate an OAI feed?). I would be nice to access the submission metadata (and maybe even the files) from the OJS API to generate YAML headers for the Markdown files. I’m very new to OJS, but would love to chat with anyone working through similar processes.
