Upgrade OJS 3.4.x ke 3.5.x - Panduan Teknis dan Strategi Aman untuk Migrasi Jurnal Ilmiah

Sistem Open Journal Systems (OJS) versi 3.5.x membawa pembaruan besar yang memengaruhi struktur basis data, arsitektur plugin, dan kompatibilitas dengan PHP terbaru. Bagi institusi pengelola jurnal ilmiah yang masih menggunakan OJS 3.4.x, proses upgrade ke 3.5.x bukan hanya sekadar pembaruan teknis, tetapi juga langkah strategis untuk mempertahankan visibilitas, indeksasi, dan integritas metadata jurnal. Namun, tanpa pemahaman teknis yang utuh, migrasi ini dapat menyebabkan kegagalan sistem, duplikasi metadata, bahkan hilangnya artikel yang telah terpublikasi. Oleh karena itu, memahami struktur migrasi, penanganan error, dan mitigasi risiko menjadi keharusan mutlak bagi pengelola jurnal.

Versi OJS 3.5.x secara resmi diluncurkan oleh Public Knowledge Project (PKP) dengan sejumlah perubahan arsitektur besar. Salah satu perubahan signifikan adalah pemisahan plugin berbasis tampilan dan fungsionalitas, reorganisasi direktori lib/pkp, serta kompatibilitas penuh terhadap PHP 8.2. Perubahan ini memengaruhi lebih dari 30% skrip sistem internal dan menyebabkan plugin lama menjadi tidak kompatibel secara langsung. Upgrade tidak dapat dilakukan dengan mengganti file, melainkan membutuhkan eksekusi perintah CLI agar database dimigrasi sesuai skema baru.

Proses migrasi dari OJS 3.4.x ke 3.5.x juga menyentuh sektor keamanan. Banyak server OJS yang sebelumnya berjalan pada PHP 7.4 kini sudah berada pada ambang akhir dukungan (end of life), sehingga mendorong kebutuhan akan versi sistem yang bisa berjalan di PHP 8.x. Hal ini turut memengaruhi pengelolaan permission, autentikasi pengguna, serta keamanan endpoint API. Jika upgrade dilakukan tanpa audit menyeluruh, risiko terjadinya konflik dependensi dan error 500 sangat tinggi.

Dalam konteks pengelolaan metadata jurnal, OJS 3.5.x memperkuat integrasi dengan Crossref, ORCID, dan OAI-PMH. Namun, agar fitur ini berjalan maksimal pasca-upgrade, seluruh plugin terkait harus disesuaikan ke versi terbaru yang kompatibel. Metadata dari artikel lama yang sebelumnya tidak terindeks akibat error submission atau kegagalan parsing DOI, perlu diperiksa ulang secara manual. Kegagalan menyesuaikan metadata pasca-upgrade dapat menyebabkan artikel tidak tampil di Google Scholar maupun DOAJ.

Proses upgrade harus dilakukan secara bertahap dan diawali dengan backup menyeluruh. Pengelola jurnal dianjurkan menyimpan dump database, salinan direktori public/, files/, dan file config.inc.php sebelum melakukan proses migrasi. Tahapan ini tidak boleh dilewati karena menjadi satu-satunya langkah untuk memulihkan sistem jika proses upgrade gagal di tengah jalan. Selain itu, seluruh plugin non-inti (non-core) wajib dinonaktifkan sementara sebelum upgrade dilakukan. Hal ini penting untuk mencegah plugin yang tidak kompatibel menyebabkan konflik selama proses migrasi database.

Secara teknis, proses upgrade dilakukan menggunakan baris perintah dengan perintah php tools/upgrade.php upgrade. Perintah ini akan melakukan migrasi database, validasi struktur baru, serta menyesuaikan konfigurasi default sistem. Jika proses upgrade dijalankan melalui antarmuka web tanpa pengawasan, maka risiko kegagalan meningkat karena banyak error yang tidak muncul secara real-time. Oleh karena itu, penggunaan mode CLI dengan parameter verbose sangat dianjurkan agar semua proses terekam dalam log yang dapat dievaluasi secara detail.

Setelah proses upgrade selesai, pengelola jurnal perlu melakukan validasi menyeluruh. Validasi ini mencakup akses halaman depan jurnal, login pengguna (admin, editor, reviewer, dan author), pengecekan kelengkapan metadata artikel, serta status indeksasi DOI. Selain itu, plugin yang sebelumnya dinonaktifkan dapat diaktifkan satu per satu sambil mengamati apakah terjadi error atau tidak. Proses ini tidak bisa dilakukan secara sekaligus karena jika satu plugin menyebabkan error, maka penyebabnya akan sulit diidentifikasi.

Strategi lain yang dapat diterapkan untuk memastikan upgrade berhasil adalah dengan menggunakan server staging terlebih dahulu. Server ini akan digunakan untuk mencoba proses upgrade dari OJS 3.4.x ke 3.5.x dengan konfigurasi yang menyerupai server produksi. Setelah semua fungsi berhasil diuji, barulah upgrade dilakukan pada server utama. Strategi ini sangat disarankan terutama jika jurnal menggunakan tema kustom atau plugin hasil modifikasi lokal.

Beberapa kasus upgrade gagal dilaporkan oleh komunitas pengguna OJS akibat ketidaksesuaian versi plugin statistik dan kustomisasi tema. Tema yang menimpa struktur lib/pkp lama cenderung gagal saat di-render di OJS 3.5.x karena struktur direktori telah berubah. Untuk menghindari hal ini, pengelola disarankan untuk sementara menggunakan tema bawaan seperti defaultManuscript atau default sebelum tema baru ditulis ulang sesuai standar OJS 3.5.

Dari sisi manajemen URL dan indeksasi mesin pencari, OJS 3.5.x tetap mempertahankan sistem permalink berbasis path. Namun, pengelola harus memastikan bahwa URL duplikat seperti index.php/index/index atau index.php/jurnal/index dihapus atau diarahkan menggunakan .htaccess agar tidak terjadi duplikasi konten. Hal ini penting agar proses crawling oleh Google Scholar, Bing, dan DOAJ tetap optimal.

Upgrade ke OJS 3.5.x juga memberikan manfaat jangka panjang berupa sistem yang lebih cepat, ringan, dan sesuai dengan standar teknologi informasi terkini. Dengan struktur plugin yang lebih modular, pengelola dapat menyesuaikan fungsionalitas jurnal tanpa mengorbankan integritas sistem utama. Hal ini memberikan fleksibilitas lebih besar dalam pengembangan fitur tambahan, seperti integrasi dengan sistem repository institusi atau layanan identitas digital nasional.

Untuk institusi yang mengelola banyak jurnal dalam satu sistem multisite, upgrade ini juga memberikan keuntungan dalam manajemen konsolidasi user, audit log aktivitas editorial, serta distribusi peran antar jurnal. Namun, perlu dicatat bahwa upgrade multisite membutuhkan perhatian khusus pada struktur direktori cache/, locale/, dan pemetaan DOIs agar tidak terjadi tumpang tindih.

Dengan pendekatan yang terstruktur, penggunaan backup, staging environment, dan pengujian plugin secara individual, proses upgrade OJS 3.4.x ke 3.5.x dapat dilakukan dengan aman dan tanpa kehilangan data. Hal terpenting adalah memastikan bahwa semua dokumentasi, dependensi plugin, dan struktur metadata telah diperiksa secara menyeluruh sebelum dan sesudah proses upgrade dilakukan.

(*)