Aurea Journal Platform

Installation, configuration, and day-to-day usage guide for the self-hosted peer-review and scholarly publishing portal.

PHP 8.1+ SQLite No external libraries British English INKRAH Web Design

1. Introduction

Aurea is a self-contained journal management and peer-review platform, comparable in scope to Open Journal Systems (OJS), built from first principles in plain PHP with an SQLite database. There is no Composer, no npm, no CDN dependency, and no third-party framework anywhere in the codebase — everything required to run the site ships inside this folder.

It covers the full editorial lifecycle: authors submit manuscripts, editors assign reviewers and record decisions, reviewers deliver structured recommendations, and accepted work is published with SEO-friendly metadata, a native PDF viewer, and a token-authenticated REST API for external integrations.

2. Technology stack

LayerChoiceNotes
LanguagePHP 8.1+Strict types, no framework
DatabaseSQLite 3Single file at data/majalla.sqlite, accessed via PDO with prepared statements throughout
Front-endVanilla HTML / CSS / JavaScriptNo React, no jQuery, no build step
RoutingCustom front controllermuwajjih.php, driven by Apache mod_rewrite
EmailPHP mail() or native SMTPHand-rolled SMTP client over fsockopen — no PHPMailer
PDF handlingBrowser-native<object> preview + full-page viewer; no PDF.js bundle
Every dependency decision in this project favours zero external packages over convenience — this keeps the attack surface small and means there is nothing to composer install or npm audit before deployment.

3. Infrastructure & requirements

  • Web server: Apache with mod_rewrite and mod_headers enabled, and AllowOverride All for the site's directory (required for .htaccess to take effect — see §7).
  • PHP: version 8.1 or later, with the pdo_sqlite and fileinfo extensions enabled.
  • Disk: write access to /data (database and uploaded manuscripts) and /iedad (configuration, written once by the installer).
  • Outbound network: only required if SMTP email delivery is enabled (Settings → Email) — the default PHP mail() transport needs a local MTA instead.
  • TLS/HTTPS: strongly recommended in production — several security headers (HSTS, secure cookies) activate automatically once the site is served over HTTPS.
  • Local development: PHP's built-in server works via php -S localhost:8000 muwajjih.php (the router script argument is required for clean URLs to function without Apache).

4. Installation guide

  1. Upload the entire folder to your web server (or point a local PHP server at it, see §3).
  2. Visit /taasis/index.php — this is the one page reachable directly, before any configuration exists.
  3. The installer checks server requirements, then asks for your Site URL, site name, and your name/email/password — this becomes the first Super Administrator account.
  4. On success you are redirected to /login. The installer writes /iedad/iedad.php (a randomly generated 256-bit secret key included) and creates /data/majalla.sqlite with the full schema.
The installer will not run twice. Once iedad/iedad.php and the database both exist, /taasis/index.php refuses to proceed. To start over, delete both iedad/iedad.php and data/majalla.sqlite*. Many operators delete the /taasis folder entirely once installed — safe to do, see §10.

5. User roles & permissions

Four account tiers form an ascending hierarchy — a higher tier automatically has every permission a lower tier has.

RoleCan do
Super AdminEverything below, plus the homepage/indexing-logo editor, live database console, system settings, and the activity log
AdminManage journals, users, custom pages, API keys — plus everything an Editor can do
EditorManage submissions, edit article metadata, leave revision notes, upload the final publish-ready PDF, assign reviewers, record decisions
AuthorSubmit manuscripts; edit or delete their own submission while unpublished; read editor feedback

Peer reviewer is not a separate tier — it is an eligibility flag any admin can grant to any account, exactly as one person can hold multiple roles in OJS.

6. Using the platform

As an Author

  1. Register at /register — a confirmation email is sent; the account activates once the link is clicked.
  2. From the dashboard, choose New Submission, select a journal, and complete title, abstract, keywords, and a PDF manuscript.
  3. Track status under My Submissions. While a submission is not yet Published, it remains fully editable and deletable.

As an Editor

  1. Open a submission from All Submissions, assign a reviewer-eligible user, and set an optional deadline.
  2. Once reviews arrive, record an editorial decision — revision requested, accepted, rejected, or published.
  3. Before publishing, optionally edit the article's title, byline name/institution, abstract, and keywords, leave notes for the author, and upload a typeset final PDF (this supersedes the author's original file on the public page).

As an Administrator / Super Administrator

  • Create journals, manage user accounts and reviewer eligibility, and issue API keys under Users / Journals / API Keys.
  • Add standalone content pages (e.g. "Author Guidelines") under Pages — live at /pages/<slug>.
  • Super Admin only: configure the homepage's indexing/partner logos, edit system-wide settings and SMTP email delivery, review the activity log, and use the raw database console.

7. URL structure / sitemap

Every page uses a clean, English-only URL — the underlying file layout is never exposed in the address bar (enforced by muwajjih.php and .htaccess).

PurposeURL pattern
Homepage/
Journals directory / single journal/journals, /journals/<slug>
Single article/articles/<slug>
Custom page/pages/<slug>
Authentication/login, /register, /logout, /confirm-email
Author area/author/dashboard, /author/submissions, /author/submissions/new
Editor area/editor/dashboard, /editor/submissions, /editor/submissions/<id>
Reviewer area/reviewer/dashboard, /reviewer/review/<id>
Admin area/admin/dashboard, /admin/journals, /admin/users, /admin/pages
Super Admin only/admin/settings, /admin/activity-log, /admin/database, /admin/external-links
Downloads/downloads/article/<id>, /downloads/manuscript/<id>
REST API/api/journals, /api/articles, /api/articles/<slug>
XML sitemap/sitemap.xml

Article slugs follow a fixed pattern — the author's full name plus the first five words of the title, hyphenated, with a numeric suffix on collision (-2, -3, …).

8. REST API

Any Administrator or Super Administrator can generate an API key from /account/api-keys. The raw key is shown once; only its SHA-256 hash is stored.

GET /api/journals?sort=newest&limit=6
GET /api/articles?majalla=<journal-slug>
GET /api/articles/<article-slug>
Authorization: Bearer <your-api-key>

Responses are JSON. Invalid or revoked keys return 401; unknown resources return 400.

9. Security measures

  • SQL injection: every query runs through PDO prepared statements — no raw string interpolation into SQL anywhere in the codebase.
  • XSS: all dynamic output is escaped via a htmlspecialchars wrapper; a strict Content-Security-Policy blocks inline scripts site-wide.
  • CSRF: every state-changing form carries a per-session token verified with hash_equals().
  • Passwords: hashed with Argon2id.
  • Sessions: HttpOnly + SameSite cookies, periodic session ID regeneration, secure flag under HTTPS.
  • Brute-force protection: failed logins are rate-limited per IP address.
  • File uploads: manuscripts are validated by real MIME sniffing (not the file extension), renamed to random filenames, size-capped, and PHP execution is disabled inside the uploads directory.
  • Path traversal: download endpoints resolve and verify the real path before serving any file.
  • API keys: stored as salted SHA-256 hashes, never in plain text; revocation is immediate.
  • Direct file access: the underlying PHP files are blocked from direct HTTP access by .htaccess — every page is only reachable through its clean route.
  • Database console: gated behind Super Admin only, with an explicit confirmation checkbox for data-changing statements, and every query logged.

10. Upgrading an existing installation

Replace the application files with a newer release and reload any page — nawat/tarqiya.php runs automatically, adds any missing database columns or tables, and records a version flag so it will not repeat the work. No manual SQL is required, though a backup of data/majalla.sqlite before upgrading is always sensible.

The /taasis installer folder is only needed for the very first setup. It is safe to delete afterwards — nothing in normal operation reads from it again.

11. Folder glossary

File and folder names on disk use Arabic transliteration, per the original project brief — never exposed to visitors, since every route is a clean English URL (§7).

FolderMeaning
taasis/ta'sīs, "founding" — the installer
iedad/i'dād, "preparation" — configuration
nawat/nawāh, "core" — bootstrap and core classes
qawalib/qawālib, "templates" — header/footer/sidebar partials
mawad/mawādd, "materials" — CSS, JS, images
idara/idārah, "administration" — admin/Super Admin panel
tahrir/taḥrīr, "editing" — editor panel
kuttab/kuttāb, "writers" — author panel
muraji3in/murāji'īn, "reviewers" — peer-review panel
hisab/ḥisāb, "account" — login/register/logout
wasla/waṣlah, "connector" — REST API and file downloads
muwajjih.phpmuwajjih, "router" — front controller

12. Support & credits

This platform was designed and built by INKRAH Web Design as an open-source project for journal peer-review portals.

Phone: +62 811-1345-777
Email: webmaster@inkrah.com
Web: inkrah.com · inkrah.com/web-design

For a more detailed technical reference — including the complete security rationale, PDF-viewing notes, and article-slug rules — see README.md in the project root alongside this file.