All projects

WorkITM2026

UNEC Student Research Journal

An academic journal platform on OJS: twenty faculties submit papers, each one walks a reviewed editorial pipeline, and the published issue is indexed and citable.

Role
Full-stack
Status
In progress
Platform
OJS 3.4 (PKP)
Indexing
DOI · Google Scholar

01Overview

UNEC's Student Scientific Society publishes the university's student research journal twice a year. Around twenty faculties submit to it, in Azerbaijani, Turkish, English or Russian, and every paper has to survive the same editorial pipeline before it reaches an issue.

The platform runs on Open Journal Systems, the open-source journal software from the Public Knowledge Project. OJS carries the editorial workflow and the metadata standards; my work is the Laravel side around it - the public journal site, the theme, and the integration that keeps the two in step.

02The problem

A journal is not a blog. A paper is not a document that gets uploaded and appears - it is a record that moves through states, and at every state a different person is allowed to see and do different things. Building that from scratch means rebuilding submission tracking, reviewer assignment, revision rounds, copyediting, galley production, issue assembly, DOI registration and indexing metadata.

The other half of the problem is discoverability. If the metadata is wrong, Google Scholar does not index the article, the DOI does not resolve, and the paper effectively does not exist outside the site.

03Architecture

OJS owns the editorial record; Laravel owns the public experience. Both read the same journal data, so an article is published in one place and appears everywhere.

Readers

Public journal site

Issues, articles, abstracts, PDF galleys

Search engines

Google Scholar and indexing crawlers

Presentation

Laravel front

Blade views, multilingual routes, static pages

OJS theme

Journal skin - issue, article and submission pages

Editorial

OJS 3.4 workflow

Submission → review → copyediting → production

Roles

Author, editor, section editor, reviewer, proofreader

Metadata

DOI plugin

Registers a DOI per article and per issue

OAI-PMH

Harvesting endpoint for indexing services

Citation tags

Highwire Press meta tags Google Scholar reads

Data

MySQL

Submissions, users, issues, metadata

File store

Manuscripts, revisions and galleys, outside the web root

04Components

Submission pipeline

The state machine a paper moves through

  • A paper enters as a submission and waits: the editor first runs a desk check against the journal's scope and the plagiarism report.
  • Papers that pass are assigned to a section editor, who invites reviewers; the review round ends in accept, revisions or reject.
  • Revisions loop back to the author and can run several rounds before a decision sticks.
  • Accepted papers move to copyediting, then to production, where the PDF galley is generated and attached.

OJS 3.4

Roles and permissions

Who may see the paper at each state

  • Authors see their own submissions and the decisions on them, nothing else.
  • Reviewers see the anonymised manuscript for the round they were invited to.
  • Section editors act inside their section; the managing editor sees the whole queue.

Issue assembly

Turning accepted papers into a published issue

  • Articles are scheduled into a volume and number, ordered and paginated - the page range printed on each article comes from here.
  • Publishing an issue is one action; it flips every article in it to public at the same moment.

Indexing layer

Making the work findable and citable

  • Each article and issue gets a registered DOI, so citations resolve permanently.
  • Article pages emit the citation meta tags Google Scholar looks for, and the OAI-PMH endpoint lets aggregators harvest the catalogue.
  • The journal carries an ISSN, which is what turns a website into a citable publication.

Public site

What a reader actually lands on

  • Laravel serves the journal's own pages - about, editorial board, author guidelines, archive - with the same look as the OJS pages.
  • The frontend is hand-written HTML, CSS and JavaScript, so the theme stays close to the OJS templates it has to match.

Laravel · PHP

05How it works

  1. 1

    Submit

    The author uploads the manuscript, fills in the metadata and confirms the submission checklist.

  2. 2

    Desk check

    The editor screens it for scope, formatting and plagiarism, and either desk-rejects it or sends it on.

  3. 3

    Peer review

    A section editor invites reviewers; each returns a recommendation and comments.

  4. 4

    Decision

    Accept, revise or reject. Revisions go back to the author and the round repeats.

  5. 5

    Production

    Copyediting, then the PDF galley is generated and proofread.

  6. 6

    Publish

    The article is scheduled into an issue; publishing the issue makes it public and mints the DOI.

  7. 7

    Index

    Metadata goes out through citation tags and OAI-PMH, and the article starts appearing in search.

06Design decisions

OJS instead of a custom CMS

The editorial workflow, the role model and the indexing standards are decades of accumulated domain knowledge. Rebuilding them would take longer and still be less correct than adopting PKP's implementation.

Laravel around it, not inside it

The public site and the journal's static content live in Laravel, so they can change without touching the OJS installation - and an OJS upgrade does not put the site at risk.

Metadata treated as a feature

DOI registration and citation tags are not an afterthought. They are the difference between a PDF on a server and an article that can be cited.

Four submission languages

Papers arrive in Azerbaijani, Turkish, English or Russian, so the interface, the metadata fields and the archive all have to be multilingual rather than translated once.

07Tech stack

Backend
PHPLaravelMySQL
Journal platform
OJS 3.4PKPOAI-PMHDOI (Crossref)
Frontend
HTMLCSSJavaScript

08What's next

  • Finish the remaining editorial screens and the archive redesign.
  • Widen indexing beyond Google Scholar to the subject databases the faculties care about.
  • Reporting for the Student Scientific Society: submissions, acceptance rate and review turnaround per faculty.

Next case study

Institute of Lung Diseases

A ground-up rebuild of a public health institute's site: hard-coded pages and a dead 2019 layout replaced by a Laravel portal the staff can actually run.