Cara Mengatasi A PHP Error was Encountered di CI3

A PHP Error was encountered

Severity: 8192

Message: Creation of dynamic property CI_URI::$config is deprecated

Filename: core/URI.php

Line Number: 101

Blok bertuliskan A PHP Error was encountered adalah tampilan error bawaan CodeIgniter 3. Bentuknya selalu sama: judul, lalu empat baris berisi Severity, Message, Filename, dan Line Number. Pesan ini sering muncul tiba-tiba setelah hosting menaikkan versi PHP, misalnya dari PHP 7.4 ke PHP 8.1 atau 8.2. Kodenya tidak berubah sama sekali, tetapi halaman yang kemarin bersih sekarang penuh kotak error, kadang diikuti pesan Cannot modify header information - headers already sent dan login yang tidak bisa dipakai.

Kabar baiknya, blok error ini sebenarnya sangat informatif. Ia memberi tahu jenis masalah, isi masalah, file, dan nomor barisnya. Artikel ini membahas cara membaca blok tersebut, arti angka Severity yang paling sering muncul (terutama Severity: 8192), peran konstanta ENVIRONMENT, lalu solusi untuk tiga kelompok error paling umum: deprecation di PHP 8, Notice/Warning karena variabel atau index yang tidak ada, serta masalah session dan header. Di bagian akhir ada pembahasan kapan sebaiknya memperbarui CodeIgniter 3 dan kapan mulai memikirkan migrasi ke CodeIgniter 4.

Cara membaca blok "A PHP Error was encountered"

Tampilan ini berasal dari file application/views/errors/html/error_php.php. CodeIgniter memasang handler error sendiri, sehingga setiap error PHP yang tidak fatal ditangkap lalu ditampilkan memakai template tersebut. Berikut arti tiap barisnya:

Di CodeIgniter 3.x, sering ada tambahan bagian Backtrace di bawahnya. Bagian ini menunjukkan urutan pemanggilan fungsi sampai error terjadi, dan hanya menampilkan file di luar folder system/. Backtrace dikendalikan oleh konstanta SHOW_DEBUG_BACKTRACE di application/config/constants.php. Kalau Filename menunjuk ke file sistem, lihat Backtrace untuk mencari baris kode Anda sendiri yang memicunya.

Kenapa Severity kadang berupa angka?

CodeIgniter 3 punya daftar nama untuk sebagian level error, misalnya E_WARNING diterjemahkan menjadi "Warning" dan E_NOTICE menjadi "Notice". Level yang tidak ada di daftar itu, seperti E_DEPRECATED, ditampilkan apa adanya sebagai angka. Itulah sebabnya Anda melihat Severity: 8192, bukan tulisan "Deprecated". Berikut nilai konstanta PHP yang paling relevan:

Jadi a php error was encountered severity 8192 artinya: ada kode yang memakai fitur usang. Ini bukan error fatal. Aplikasi biasanya tetap jalan, tetapi tampilannya rusak karena kotak error ikut tercetak, dan output tambahan itu bisa memicu masalah lanjutan seperti header dan session.

Peran ENVIRONMENT dan error_reporting di index.php

Apakah blok error tampil atau tidak ditentukan di file index.php di root proyek. Di bagian atas ada definisi berikut:

define('ENVIRONMENT', isset($_SERVER['CI_ENV']) ? $_SERVER['CI_ENV'] : 'development');

Artinya, jika server tidak mengatur variabel CI_ENV, aplikasi berjalan dalam mode development. Banyak proyek yang diunggah ke hosting tanpa mengubah baris ini, sehingga situs produksi tetap berjalan sebagai development dan menampilkan semua error ke pengunjung. Sedikit di bawahnya ada blok switch:

switch (ENVIRONMENT)
{
	case 'development':
		error_reporting(-1);
		ini_set('display_errors', 1);
	break;

	case 'testing':
	case 'production':
		ini_set('display_errors', 0);
		if (version_compare(PHP_VERSION, '5.3', '>='))
		{
			error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_USER_NOTICE & ~E_USER_DEPRECATED);
		}
		else
		{
			error_reporting(E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE);
		}
	break;
	...
}

Di mode development, semua level error dilaporkan dan ditampilkan. Di mode production, display_errors dimatikan dan level Notice serta Deprecated tidak dilaporkan. Untuk mengatur mode tanpa mengedit index.php, Anda bisa menambahkan baris ini di .htaccess (Apache dengan mod_env aktif):

SetEnv CI_ENV production

Atau, cara paling sederhana, ubah langsung nilai default di index.php dari 'development' menjadi 'production' pada server produksi.

Menyembunyikan error tidak sama dengan memperbaikinya

Mengubah ke mode production memang membuat kotak error hilang dari layar. Itu langkah yang benar untuk situs live, karena pesan error bisa membocorkan path folder dan struktur kode ke pengunjung. Namun penyebabnya tetap ada. Deprecation hari ini adalah error fatal di versi PHP berikutnya, sebab fitur yang usang pada akhirnya dihapus. Warning seperti "Undefined array key" juga sering menandakan data yang memang hilang, misalnya input form yang tidak terkirim, sehingga logika aplikasi bisa salah tanpa ada yang sadar.

Pendekatan yang sehat adalah: matikan tampilan error di produksi, nyalakan pencatatan log, lalu perbaiki error satu per satu di lingkungan lokal atau staging. Untuk mencatat error ke file, buka application/config/config.php dan atur:

$config['log_threshold'] = 1; // 1 = hanya error, termasuk error PHP

File log akan tersimpan di folder application/logs/, jadi pastikan folder itu bisa ditulis oleh web server. Jika Anda ingin memahami lebih jauh perbedaan error, warning, dan exception di PHP modern, baca juga cara menangani error dan exception di PHP 8.

Solusi Severity 8192: "Creation of dynamic property ... is deprecated"

Ini varian yang paling banyak dicari sejak PHP 8.2 dirilis. Mulai PHP 8.2, membuat properti objek yang tidak dideklarasikan di class (disebut dynamic property) dianggap usang. Contoh kode yang memicunya:

class Produk_model extends CI_Model
{
	public function set_data($nama)
	{
		$this->nama = $nama; // properti $nama tidak dideklarasikan
	}
}

CodeIgniter 3 dirancang jauh sebelum aturan ini ada, dan cara kerjanya memang banyak bergantung pada properti dinamis. Contohnya, saat Anda memanggil $this->load->library('session'), objek library itu ditempelkan ke controller sebagai properti $this->session. Karena itu deprecation bisa muncul dari dua sumber: kode Anda sendiri di folder application/, dan class inti di folder system/.

Cara 1: deklarasikan propertinya (paling bersih)

Untuk class buatan Anda sendiri, solusi terbaik adalah menuliskan properti di bagian atas class. Selain menghilangkan deprecation, kode jadi lebih mudah dibaca karena semua properti terlihat di satu tempat.

class Produk_model extends CI_Model
{
	public $nama;

	public function set_data($nama)
	{
		$this->nama = $nama;
	}
}

Cara 2: pakai atribut #[\AllowDynamicProperties]

Jika class Anda memang sengaja memakai properti dinamis, atau jumlah propertinya banyak dan sulit didata satu per satu, tambahkan atribut #[\AllowDynamicProperties] tepat di atas deklarasi class:

#[\AllowDynamicProperties]
class Produk_model extends CI_Model
{
	// ...
}

Atribut ini tersedia sejak PHP 8.2. Di PHP 7.x, baris yang diawali tanda # dianggap komentar, sehingga kode tetap kompatibel dengan versi lama. Perlu diingat, atribut ini diwariskan ke class turunan. Selain itu, class yang punya method magic __set() tidak terkena deprecation ini, karena penulisan properti ditangani oleh method tersebut.

Jika Filename menunjuk ke folder system

Kalau baris Filename berisi seperti core/URI.php, core/Router.php, atau core/Loader.php, sumbernya adalah inti CodeIgniter. Langkah pertama adalah memastikan Anda memakai versi CodeIgniter 3 terbaru (lihat bagian patch kompatibilitas di bawah). Jika deprecation masih muncul setelah itu, cara yang umum dipakai adalah menambahkan #[\AllowDynamicProperties] pada class inti yang disebut di pesan error, misalnya CI_URI, CI_Router, CI_Controller, atau CI_Model. Lakukan dengan hati-hati: catat setiap file sistem yang Anda ubah, karena perubahan itu akan tertimpa saat folder system/ diganti dengan versi baru.

Solusi Severity Notice dan Warning: Undefined index, variable, dan array key

Kelompok kedua adalah pesan seperti ini:

Severity: Notice
Message: Undefined index: email

Severity: Warning
Message: Undefined array key "email"

Severity: Warning
Message: Undefined variable $judul

Pesan Undefined index adalah versi PHP 7 dengan level Notice. Sejak PHP 8.0, pesan yang sama berubah menjadi Undefined array key dan levelnya naik menjadi Warning. Begitu juga Undefined variable yang naik dari Notice ke Warning. Inilah sebabnya aplikasi lama yang dulu terlihat bersih (karena Notice tidak ditampilkan di produksi) tiba-tiba memunculkan Warning setelah pindah ke PHP 8: level Warning tidak dikecualikan oleh konfigurasi production bawaan CodeIgniter.

Solusinya adalah memastikan key atau variabel ada sebelum dipakai. Beberapa pola yang aman:

// Operator null coalescing (PHP 7.0+)
$email = $data['email'] ?? '';

// Cek dengan isset
if (isset($row['foto'])) {
	echo $row['foto'];
}

// Ambil input lewat class Input CodeIgniter
$email = $this->input->post('email'); // menghasilkan NULL jika tidak ada

Kebiasaan memakai $this->input->post() dan $this->input->get() alih-alih mengakses $_POST langsung sangat membantu, karena method ini mengembalikan NULL ketika key tidak ada, bukan memicu Warning. Kalau Anda masih bingung kapan data dikirim lewat GET atau POST, artikel perbedaan GET dan POST di PHP bisa membantu.

Untuk Undefined variable di view, penyebab paling umum adalah variabel yang tidak dikirim dari controller. Di CodeIgniter 3, isi array yang dikirim ke $this->load->view('nama_view', $data) diubah menjadi variabel biasa. Jadi $data['judul'] di controller menjadi $judul di view. Jika satu cabang logika di controller lupa mengisi $data['judul'], view akan memunculkan Warning. Berikan nilai default sejak awal, misalnya $data['judul'] = ''; sebelum blok kondisi.

Solusi "headers already sent" dan error session_start()

Kelompok ketiga biasanya muncul bersamaan dan terlihat seperti ini:

Severity: Warning
Message: Cannot modify header information - headers already sent by
(output started at /var/www/html/application/controllers/Login.php:1)
Filename: helpers/url_helper.php

Severity: Warning
Message: session_start(): Failed to read session data: user (path: ...)

Header HTTP (termasuk cookie dan perintah redirect) harus dikirim sebelum ada satu karakter pun keluar ke browser. Jika sudah ada output, PHP tidak bisa lagi mengirim header. Akibatnya redirect() gagal, cookie session tidak terpasang, dan login tidak tersimpan.

Bagian terpenting dari pesan ini adalah "output started at ...". Itu menunjukkan file dan baris yang pertama kali mengeluarkan output. Penyebab yang paling sering:

• Error PHP lain yang tercetak lebih dulu. Ini yang paling sering terlewat. Kotak A PHP Error was encountered untuk deprecation atau Warning adalah output. Begitu kotak itu tercetak, header tidak bisa dikirim lagi. Perbaiki error pertama di halaman, dan pesan headers already sent sering ikut hilang.
• Spasi atau baris kosong sebelum <?php atau setelah penutup ?> di file controller, model, config, atau helper. Untuk file yang isinya murni PHP, praktik yang dianjurkan adalah tidak menulis tag penutup ?> sama sekali.
• BOM (Byte Order Mark) di awal file yang disimpan sebagai "UTF-8 with BOM". BOM tidak terlihat di editor, tetapi terkirim sebagai output. Simpan ulang file sebagai UTF-8 tanpa BOM. Di VS Code, klik penanda encoding di status bar bawah, pilih Save with Encoding, lalu pilih UTF-8.
• echo, print_r, atau var_dump untuk debugging yang lupa dihapus sebelum redirect().

Untuk error session_start(), periksa konfigurasi session di application/config/config.php. Jika memakai driver files, CodeIgniter 3 membutuhkan sess_save_path berupa path absolut ke folder yang bisa ditulis web server:

$config['sess_driver'] = 'files';
$config['sess_save_path'] = APPPATH . 'cache/sessions/';

Buat folder tersebut dan pastikan izin tulisnya benar. Jika memakai driver database, pastikan tabel session (default ci_sessions) sudah dibuat sesuai struktur di dokumentasi CodeIgniter 3, dan nama tabelnya sama dengan nilai sess_save_path. Versi CodeIgniter 3 yang lama juga dikenal bermasalah dengan driver session di PHP 7.x ke atas, sehingga memperbarui ke rilis terbaru sering menyelesaikan error session tanpa perubahan kode lain. Dasar cara kerja session dan cookie dibahas di artikel cara menggunakan session dan cookie di PHP.

Patch kompatibilitas: perbarui ke CodeIgniter 3.1.13

CodeIgniter 3.1.13 adalah rilis terakhir dari seri CodeIgniter 3. Rilis ini membawa perbaikan kompatibilitas untuk PHP 8.1, sehingga banyak deprecation dari class inti yang muncul di versi 3.1.11 atau lebih lama sudah tertangani. Namun rilis ini keluar sebelum PHP 8.2, jadi deprecation dynamic property di PHP 8.2 masih mungkin muncul dan perlu ditangani seperti dijelaskan di atas.

Cara memperbarui CodeIgniter 3 relatif sederhana karena kode aplikasi dan kode framework terpisah:

1. Backup seluruh proyek, termasuk database, sebelum mengubah apa pun.
2. Cek versi yang sedang dipakai di file system/core/CodeIgniter.php, cari baris define('CI_VERSION', ...).
3. Unduh CodeIgniter 3.1.13 dari situs resmi codeigniter.com atau repositori GitHub resminya.
4. Ganti seluruh isi folder system/ dengan folder system/ dari paket baru. Folder application/ tidak perlu disentuh.
5. Baca panduan upgrade di user guide CodeIgniter 3 untuk setiap versi yang Anda lewati. Kadang ada perubahan kecil pada file konfigurasi atau file view error yang perlu disesuaikan manual.
6. Uji fitur utama seperti login, form, upload, dan query database di lokal atau staging sebelum diunggah ke produksi.

Jika sebelumnya Anda pernah mengedit file di dalam folder system/, perubahan itu akan hilang. Itulah alasan penting untuk mencatat setiap modifikasi pada file inti.

Alternatif sementara yang sering dipakai jika pembaruan belum memungkinkan adalah menjalankan aplikasi di versi PHP yang lebih rendah, misalnya PHP 7.4 atau 8.1, lewat pengaturan versi PHP di panel hosting. Ini membeli waktu, tetapi bukan solusi jangka panjang karena versi PHP lama tidak lagi menerima pembaruan keamanan.

Kapan sebaiknya migrasi ke CodeIgniter 4?

CodeIgniter 3 tidak lagi dikembangkan secara aktif. Seiring PHP terus memperketat aturan, menambal CodeIgniter 3 akan semakin sering diperlukan. CodeIgniter 4 dibangun ulang untuk PHP modern, memakai namespace, mendukung Composer, dan versi terbarunya membutuhkan PHP 8.1 atau lebih baru.

Namun migrasi ke CodeIgniter 4 bukan sekadar upgrade. Struktur folder berubah (app/, public/, writable/), konfigurasi berpindah ke class dan file .env (mode lingkungan diatur lewat CI_ENVIRONMENT), cara memuat model dan library berbeda, dan Query Builder punya beberapa perbedaan sintaks. Dalam praktiknya, controller, model, dan view perlu ditulis ulang sebagian besar. Dokumentasi CodeIgniter 4 menyediakan panduan khusus "Upgrading from 3.x to 4.x" yang membahas perbedaan per komponen.

Sebagai patokan kasar:

• Aplikasi kecil dan masih aktif dikembangkan: migrasi ke CodeIgniter 4 layak dipertimbangkan, karena investasinya terbayar dalam jangka panjang.
• Aplikasi besar yang stabil dan jarang diubah: perbarui ke 3.1.13, tangani deprecation, dan rencanakan migrasi bertahap per modul.
• Proyek baru: jangan mulai dengan CodeIgniter 3. Gunakan CodeIgniter 4 atau framework lain yang aktif dikembangkan.

CodeIgniter 4 dipasang lewat Composer, jadi pastikan Anda sudah familiar dengan alat ini. Panduannya ada di artikel cara menggunakan Composer untuk package PHP.

Ringkasan langkah perbaikan

1. Baca baris Message dan Filename. Jika Filename ada di folder sistem, lihat Backtrace untuk menemukan kode Anda.
2. Cocokkan angka Severity: 8192 berarti deprecation, 2 berarti warning, 8 berarti notice.
3. Perbaiki error pertama di halaman lebih dulu, karena error berikutnya (terutama headers already sent) sering hanya akibatnya.
4. Untuk dynamic property, deklarasikan properti atau pakai #[\AllowDynamicProperties].
5. Untuk undefined index dan variable, gunakan isset(), ??, atau $this->input->post().
6. Perbarui folder system/ ke CodeIgniter 3.1.13.
7. Di produksi, set ENVIRONMENT ke production dan aktifkan log, lalu pantau isi application/logs/.

FAQ

Apa arti "A PHP Error was encountered Severity: 8192"?

Angka 8192 adalah nilai konstanta E_DEPRECATED di PHP. Artinya ada kode yang memakai fitur usang, misalnya dynamic property di PHP 8.2. CodeIgniter 3 menampilkannya sebagai angka karena level ini tidak ada di daftar nama severity bawaannya. Aplikasi biasanya tetap berjalan, tetapi sebaiknya diperbaiki.

Apakah cukup mengubah ENVIRONMENT ke production?

Itu menyembunyikan error dari pengunjung dan memang wajib untuk situs live, tetapi tidak memperbaiki penyebabnya. Deprecation bisa menjadi error fatal di versi PHP berikutnya, dan Warning bisa menandakan data yang hilang. Aktifkan log dan perbaiki errornya secara bertahap.

Apakah CodeIgniter 3 bisa berjalan di PHP 8.2 atau 8.3?

Bisa, dengan catatan. Gunakan CodeIgniter 3.1.13, lalu tangani deprecation dynamic property yang masih muncul, baik di kode Anda maupun di class inti. Uji menyeluruh di lingkungan lokal sebelum mengubah versi PHP di server produksi.

Kenapa error muncul setelah hosting upgrade PHP padahal kode tidak diubah?

Setiap versi PHP baru bisa menandai fitur lama sebagai usang atau menaikkan level suatu pesan. Contohnya, Undefined index (Notice) di PHP 7 berubah menjadi Undefined array key (Warning) di PHP 8. Kode yang sama dinilai lebih ketat, sehingga pesan yang dulu tidak tampil sekarang terlihat.

Bolehkah saya mengedit file di folder system?

Boleh sebagai solusi darurat, misalnya menambahkan #[\AllowDynamicProperties] pada class inti. Catat setiap perubahan, karena semuanya akan tertimpa saat Anda mengganti folder system/ dengan versi baru. Untuk logika aplikasi, selalu tulis di folder application/.