Majalengka — PHP 7.4 resmi berhenti mendapat dukungan keamanan sejak 28 November 2022. Artinya, lebih dari tiga tahun setiap celah baru yang ditemukan di versi itu tidak lagi ditambal. Namun di banyak server instansi, PHP 7.4 masih hidup karena aplikasi lamanya dianggap "terlalu berisiko untuk dipindah".

Pada Oktober 2026, tim EASYSTEM memindahkan 11 vhost di dua server milik instansi di Majalengka dari PHP 7.4 ke PHP 8.3 dan 8.4. Semua situs tetap menyala, tanpa downtime. Artikel ini merangkum enam masalah yang benar-benar muncul di lapangan — bukan teori — beserta perbaikannya, supaya tim IT lain tidak menempuh jalan yang sama.

Kenapa PHP 7.4 tidak boleh dipakai lagi

Versi 7.4 adalah cabang terakhir dari generasi PHP 7. Setelah masa dukungannya habis, tidak ada lagi patch untuk celah keamanan, termasuk celah yang memungkinkan penyerang menjalankan kode dari jarak jauh. Dua celah kritis yang dijuluki PHP2Shell pada Oktober 2026 adalah pengingat terbaru: patch hanya tersedia untuk 8.3 dan 8.4, sementara server yang masih di 7.4 tidak punya jalan untuk menambalnya.

Risikonya bukan hanya "situs bisa di-hack". Aplikasi kepegawaian dan absensi menyimpan NIP, data jabatan, dan riwayat kehadiran. Kalau server-nya jatuh, yang bocor adalah data ASN, bukan sekadar halaman depan.

1. mysqli berhenti "diam": exception menggantikan peringatan

Ini penyebab 500 yang paling sering kami temui, dan yang paling membingungkan karena kodenya tidak berubah sama sekali.

Sejak PHP 8.1, ekstensi mysqli secara default melempar exception saat query gagal. Di PHP 7.4, query yang gagal hanya mengembalikan false dan aplikasi melanjutkan seolah tidak terjadi apa-apa. Contoh nyata yang kami temukan di sebuah aplikasi CodeIgniter 3:

$this->ci->db->query("SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION'");

User database aplikasi tidak punya hak SUPER. Di PHP 7.4 baris itu gagal diam-diam dan halaman tetap terbuka. Di PHP 8.4 baris yang sama melempar mysqli_sql_exception dan seluruh halaman berubah menjadi HTTP 500 kosong — tanpa pesan apa pun di browser.

Perbaikannya justru sederhana dan lebih benar secara logika: ubah SET GLOBAL menjadi SET SESSION. Pengaturan sql_mode memang seharusnya berlaku untuk sesi aplikasi itu saja, bukan mengubah setelan global server yang dipakai bersama.

$this->ci->db->query("SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION'");

Pelajaran: sebelum migrasi, cari pola SET GLOBAL di seluruh kode. Query yang selama ini "tidak berpengaruh" bisa berubah menjadi halaman mati.

2. Konstanta tanpa tanda kutip berubah menjadi fatal error

File index.php berisi satu baris:

<?php echo hallo;

Di PHP 7.4, hallo dianggap konstanta yang belum didefinisikan, lalu diganti menjadi string dengan sebuah warning. Halaman tetap tampil. Di PHP 8, konstanta yang tidak dikenal melempar Error dan eksekusi berhenti total.

Perbaikannya tentu saja menambahkan tanda kutip: echo 'hallo';. Tapi masalah yang lebih besar adalah baris seperti ini sering tersembunyi di file lama yang tidak pernah dibuka lagi sejak 2018.

3. count() dan properti dinamis: peringatan yang berubah jadi TypeError

Aplikasi CodeIgniter 3 sering memakai count($data) tanpa memastikan $data berupa array. Di PHP 7.4 hasilnya 0. Di PHP 8, count(null) melempar TypeError.

Selain itu, PHP 8.2 memperkenalkan peringatan dynamic property: kelas yang menulis properti tanpa mendeklarasikannya lebih dulu akan memenuhi log dengan pesan deprecated. Aplikasi tetap jalan, tetapi log menjadi sangat besar dan menutupi error yang benar-benar penting.

Solusi praktis di lapangan:

• Ganti count($x) menjadi count((array) $x) pada view yang datanya bisa kosong.
• Untuk sementara, arahkan error_log PHP ke file terpisah dan saring E_DEPRECATED supaya log web server tetap bersih.
• Jangka panjang: naikkan versi framework. Laravel 8 dan CodeIgniter 3 memang sudah melewati masa dukungan.

4. Captcha hilang bukan karena kode, tapi karena izin folder

Salah satu temuan yang paling sering dilaporkan pengguna: kolom komentar meminta captcha, tetapi gambarnya tidak muncul. Setelah ditelusuri, fungsi create_captcha() gagal menulis file gambar karena folder captcha/ masih dimiliki user lama, bukan user web server.

Fungsi itu gagal tanpa pesan, dan template menerima data kosong sehingga tag gambar tidak pernah dicetak. Perbaikannya satu perintah:

chown -R www-data:www-data /path/situs/captcha/

Kasus ini tidak berhubungan langsung dengan PHP 8, tetapi muncul justru saat audit setelah migrasi — karena pada saat itulah semua halaman benar-benar diuji satu per satu.

5. phpMyAdmin tertinggal versi dan bisa dibuka tanpa batas IP

phpMyAdmin adalah pintu langsung ke database. Di salah satu server, versinya masih 5.2.1 (Oktober 2023), sementara rilis terbaru sudah 5.2.3 dengan perbaikan keamanan.

Yang lebih serius: phpMyAdmin berada di dalam dokumen root yang juga dilayani oleh default server nginx. Akibatnya, aturan allow berbasis IP yang dipasang di vhost domain bisa dilewati hanya dengan mengakses server lewat alamat IP atau nama domain lain di port 80.

Dua langkah yang kami lakukan:

1. Blokir direktori tersebut di vhost default server: location ^~ /ADMINDATABASES { deny all; }
2. Blokir akses langsung ke file konfigurasi: location = /ADMINDATABASES/config.inc.php { deny all; }, lalu upgrade ke versi terbaru dengan verifikasi checksum SHA-256 dari situs resmi.

Pelajaran: allowlist IP di satu vhost tidak otomatis melindungi aplikasi yang sama jika dokumen root-nya juga dilayani vhost lain.

6. TLS 1.0 dan 1.1 masih menyala

Banyak vhost lama masih mengaktifkan TLSv1 dan TLSv1.1 plus cipher 3DES. Protokol ini sudah dianggap tidak aman dan tidak memenuhi standar pengadaan teknologi informasi. Setelah diperiksa dengan openssl s_client, perubahan konfigurasi langsung menolak kedua protokol tersebut dan hanya menyisakan TLS 1.2 dan 1.3.

Urutan migrasi yang aman

Kunci agar tidak ada downtime: jangan menimpa PHP lama. Pasang versi baru berdampingan, lalu pindahkan vhost satu per satu.

1. Pasang PHP baru (8.3/8.4) di port FPM terpisah, misalnya 9083 dan 9084.
2. Buat vhost uji sementara di 127.0.0.1 dengan dokumen root yang sama, arahkan ke port baru.
3. Bandingkan hasilnya dengan versi lama: status code, ukuran halaman, dan isi HTML. Perbedaan 40 byte biasanya hanya nama host saat pengujian.
4. Uji halaman yang paling sering dipakai pengguna, bukan hanya halaman depan.
5. Cadangkan konfigurasi, ubah fastcgi_pass ke port baru, nginx -t, lalu reload.
6. Pantau log aplikasi 15–30 menit pertama. Kalau muncul 500, kembalikan konfigurasi — rollback cukup satu baris.

Untuk aplikasi dengan banyak worker (absensi, API), semua worker harus dipindah bersamaan. Kalau tidak, sebagian request tetap jatuh ke PHP lama dan hasilnya sulit ditebak.

Checklist sebelum memindahkan vhost

• Cari SET GLOBAL, count(, dan konstanta tanpa kutip di kode aplikasi.
• Pastikan ekstensi yang dibutuhkan tersedia di PHP baru: mysqli, pdo_mysql, gd, intl, zip, soap.
• Periksa folder yang harus bisa ditulis: uploads, captcha, cache, storage, tmp.
• Catat versi framework. CodeIgniter 3 dan Laravel 8 masih jalan, tetapi sebaiknya segera direncanakan upgrade.
• Cadangkan konfigurasi nginx dan file aplikasi yang akan diubah.
• Siapkan cara rollback sebelum mulai.

Hasil yang kami catat

• 11 vhost dipindah ke PHP 8.3/8.4 tanpa downtime.
• Satu situs pemerintahan yang sebelumnya butuh 2,7 detik untuk halaman depan turun menjadi 1,1 detik setelah query yang berjalan di setiap request diperbaiki.
• TLS 1.0/1.1 dimatikan di seluruh vhost yang diaudit.
• phpMyAdmin naik dari 5.2.1 ke 5.2.3, dengan akses IP dan file konfigurasi yang sudah ditutup.
• PHP 7.4 di kedua server dinonaktifkan, sehingga tidak ada lagi aplikasi yang berjalan di versi tanpa patch.

Kalau server Anda masih memakai PHP 7.4

Jangan menunggu sampai ada insiden. Mulailah dari inventaris: daftar vhost, versi PHP per vhost, dan aplikasi apa yang berjalan di dalamnya. Dari situ migrasi bisa direncanakan per situs, tanpa mematikan layanan.

EASYSTEM membantu audit keamanan, migrasi PHP, dan perbaikan konfigurasi server untuk situs pemerintahan, sekolah, dan usaha di Majalengka dan sekitarnya. Konsultasi awal bisa dilakukan tanpa mengubah apa pun di server Anda.