Cara Debug Website CodeIgniter: Panduan Lengkap 2026

Cerita Jumat Malam: Halaman Putih yang Bikin Klien Panik

Jam 11 malam, Jumat. Semua keliatan aman – CPU tenang, disk lega, MySQL jalan, tinggal menikmati weekend. Eh, tiba-tiba HP bergetar. Klien nelpon panik: “Mas, website saya jadi putih semua! Tadi pagi masih normal lho!” Aku login ke server, cek Apache, cek MySQL, cek resource – semua sehat. Process hidup, RAM masih sisa banyak. Tapi bener aja, websitenya kosong melompong. Putih bersih, kayak kanvas yang belum digambar. Dan dari insiden itu, aku nyusun pola cara debug website CodeIgniter yang ternyata gampang banget ditiru – dan itu yang bakal aku bagi di artikel ini.

Lha, kok iso? Nah, di situ aku inget pelajaran klasik: kalau infrastruktur sehat tapi aplikasi error, jangan cek server-nya – cek aplikasinya. Ternyata website itu dibangun pakai CodeIgniter, framework PHP yang sangat populer di kalangan developer Indonesia. Masalahnya, teknisi hosting kayak kita jago banget soal infrastruktur, tapi pas ketemu error dari dalam framework, kadang langsung blank juga. Padahal sebenarnya ada pola debug yang jelas, dan kita cuma butuh tahu mulai dari mana. Artikel ini buat itu – biar pas insiden berikutnya, sampeyan gak perlu panik dulu.

Debug Website CodeIgniter: Masalahnya Bukan Sekadar Halaman Putih

Masalahe gak mung soal halaman kosong doang. Nek website e-commerce, halaman putih artinya revenue ilang. Nek website portal berita, user yang kebuka malah ngira situsnya rusak permanen dan balik lagi nggak tahu kapan. Dan kalau ini website production dengan ribuan pengunjung, setiap menit downtime itu kerugian yang nggak bisa direcovery. Belum lagi kalau klien sampai buka ticket ke management – urusannya bisa panjang dan tegang.

Yang paling bikin pusing: framework itu punya lapisan error handling sendiri. Error yang muncul di browser bisa beda jauh sama yang keliatan di system log. Error PHP yang biasanya sampeyan lihat di error log Apache – bisa jadi nggak muncul di situ sama sekali. Karena CodeIgniter nyimpen errornya di folder sendiri, dan kalau konfigurasi log-nya mati, errornya ilang tanpa jejak. Nah, di sinilah banyak teknisi stuck, padahal clue-nya sebenarnya ada.

Gejala yang sering muncul: halaman 500 tanpa pesan apa-apa, halaman putih total (blank white page), redirect loop yang bikin browser ngasih error Too Many Redirects, atau website yang cuma error di halaman tertentu doang. Penyebabnya macam-macam – permission folder yang salah, koneksi database gagal karena password beda, PHP version yang nggak kompatibel, sampai error 500 internal server yang sebenarnya bukan salah server. Dan yang paling sering ketemu di lapangan: file config yang isinya masih nunjuk ke server lama. Kalau sampeyan udah pernah ngalamin minimal satu dari ini, artikel ini pas banget buat sampeyan.

CodeIgniter Itu Kayak Dapur Penuh Alat

Biar gampang, pahami dulu konsepnya dikit. CodeIgniter itu kayak dapur yang udah dilengkapi semua alat masak – koneksi database, routing URL, session, security – tinggal dipake developer buat bikin aplikasi. Developer tinggal ngambil resep dan alatnya. Nah, pas dapurnya rewel, kita sebagai teknisi hosting itu ibarat tukang servis alat dapur. Kita gak perlu bisa masak sampai jadi chef, tapi kita harus tahu bagian mana yang bermasalah, dan bisa kasih laporan yang jelas ke pemilik dapur.

Dan di sinilah uniknya: karena framework nyediain semua komponen secara terstruktur, debugging itu jadi punya urutan cek yang jelas. Ada pola. Kalau kita ngerti polanya, error apa pun bisa kita track dari gejala ke akar masalah. Penasaran? Lanjut terus, nanti aku tunjukin urutannya.

Kenapa Debugging CodeIgniter Beda dari Website PHP Biasa?

Kalau website PHP polos, error-nya biasanya langsung nyangkut di error log server. Tinggal buka, baca baris terakhir, fix, selesai. Tapi CodeIgniter nambah beberapa lapisan yang bikin prosesnya beda:

• Error handling berlapis. Framework nangkep error dulu, terus mutusin mau ditampilkan apa nggak berdasarkan environment mode-nya. Di mode production, detail error disembunyiin sengaja.
• Config file yang banyak dan tersebar. database.php, config.php, routes.php, autoload.php, dan lain-lain – masing-masing bisa jadi biang kerok.
• Folder khusus yang wajib writable. Kalau folder cache atau logs nggak bisa ditulis, aplikasi error tapi kadang nggak ngasih pesan yang jelas.
• Base URL dan .htaccess. Kalau salah set, asset broken dan route berantakan, walau kode PHP-nya sendiri sehat-sehat aja.
• Versi PHP yang bervariasi. CodeIgniter 3 dan 4 punya requirement beda, dan PHP 8 tuh nggak selembut PHP 7 soal error deprecated – banyak fungsi lama yang tinggal nggak jalan.

Jadi kalau sampeyan biasa nanganin website PHP sederhana, anggap aja ini level berikutnya. Bukan berarti lebih susah – cuma butuh checklist yang lebih lengkap. Dan itu yang bakal kita bahas sekarang.

Persiapan: Akses Apa Saja yang Dibutuhkan?

Sebelum mulai, pastikan akses ini ada dulu. Kalau kurang, minta ke client atau admin server:

• SSH ke server (paling enak buat ngecek log dan permission), atau minimal File Manager di cPanel.
• Lokasi file aplikasi – biasanya di public_html langsung, atau di subfolder kayak public_html/app atau public_html/ci.
• Nama database, user, dan password – ini sering dilupain, padahal wajib buat ngecek config database.
• Versi PHP yang aktif di website (di cPanel: Software → MultiPHP Manager).
• Clue perubahan terakhir – kapan terakhir website normal, dan apa aja yang berubah sejak itu.

Kalau aksesnya udah lengkap, kita mulai. Semua step di bawah aman kalau urutannya bener. Tapi selalu siapin backup config sebelum ngubah apa-apa – biar kalau salah langkah, gampang balik lagi.

Step 1: Aktifkan Mode Development

Step pertama, dan ini paling penting. CodeIgniter punya dua mode: production dan development. Di mode production, framework sengaja nyembunyiin detail error – yang muncul cuma halaman 500 polos, kadang putih doang. Nah, kita perlu aktifkan mode development biar error-nya keliatan jelas.

CodeIgniter 3: buka file index.php di root aplikasi, cari baris ini:

define('ENVIRONMENT', 'production');

Ubah jadi:

define('ENVIRONMENT', 'development');

CodeIgniter 4: buka file .env di root aplikasi (kalau nggak ada, buat salinan dari env.example), lalu cari atau ubah baris ini:

CI_ENVIRONMENT = development

Nah, untuk CI4, kalau nggak ada file .env, biasanya ada file env.example yang bisa direname jadi .env. Setelah itu, refresh website. Kalau sekarang muncul pesan error yang detail – nama file, nomor baris, deskripsi error lengkap – selamat, itu kabar bagus. Itu clue utama yang lagi kita cari.

Step 2: Tampilkan Error PHP di Browser

Kadang mode development aja nggak cukup. Di CodeIgniter 3, error PHP bisa tetap disembunyiin kalau setting error_reporting-nya dibatasi. Cek di file index.php (CI3) bagian ini:

error_reporting(E_ALL);
ini_set('display_errors', 1);

Artinya: tampilkan semua jenis error, dan jangan disembunyiin. Untuk CodeIgniter 4, kalau environment-nya sudah development, dua setting ini otomatis aktif. Tapi ada satu hal yang sering kelewat: kalau PHP di server dikonfigurasi dengan display_errors off (di php.ini), error tetap nggak muncul. Solusi cepatnya, set via .htaccess:

php_flag display_errors On
php_value error_reporting E_ALL

Tapi ingat, directive php_flag cuma ngefek kalau server pakai mod_php. Kalau pakai PHP-FPM (kebanyakan cPanel modern pakai ini), cara ini nggak ngefek – lebih aman set di MultiPHP INI Editor di cPanel, atau edit php.ini langsung kalau pegang VPS. Kalau nggak yakin server-nya pakai apa, tanya dulu ke admin, atau cek dengan file phpinfo.

Dan satu lagi: jangan cuma ngarepin error muncul di browser. Error yang ketulis di log itu lebih lengkap – ada timestamp, ada stack trace. Log itu saksi bisu yang gak pernah bohong. Jadi kombinasi terbaik: tampilkan di layar buat identifikasi cepat, plus baca log buat detail.

Step 3: Baca Log CodeIgniter

Kalau error di layar tetap nggak muncul, atau sampeyan pengen detail lebih, beralih ke log. CodeIgniter nyimpen log sendiri di folder khusus, bukan di log Apache:

• CodeIgniter 3: application/logs/log-YYYY-MM-DD.php
• CodeIgniter 4: writable/logs/log-YYYY-MM-DD.log

Format nama filenya pakai tanggal, misalnya log-2026-07-31.php. Tinggal buka file yang tanggalnya sesuai sama kejadian error. Contoh isi log CodeIgniter 3 yang asli bentuknya gini:

ERROR - 2026-07-31 23:15:01 --> Severity: error --> Exception: Unable to connect to the database.
ERROR - 2026-07-31 23:15:02 --> Severity: warning --> mysql_real_escape_string(): Argument #1 must be of type string.
ERROR - 2026-07-31 23:15:05 --> 404 Page Not Found: /blog/detail/12

Nih, gatekna baik-baik – tiga baris error ini udah ngasih banyak clue:

• Baris pertama: koneksi database gagal. Kemungkinan besar config database salah, atau MySQL-nya down.
• Baris kedua: ada fungsi lama yang nggak cocok sama versi PHP sekarang. Ini masalah kompatibilitas versi.
• Baris ketiga: 404 Page Not Found. Ini masalah routing – biasanya karena base_url atau .htaccess bermasalah.

Tapi biar log-nya mau ngisi, pastikan threshold logging-nya aktif. CodeIgniter 3, di application/config/config.php:

$config['log_threshold'] = 4;

Nilai 4 artinya log semua error. Untuk CodeIgniter 4, di app/Config/Logger.php:

public $threshold = 9;

Sama, nilainya biarin maksimal biar semua error kegaris. Setelah diset, refresh website-nya, terus buka lagi log-nya. Error terbaru biasanya muncul di baris paling bawah file. Kalau log-nya tetap kosong, cek dulu apakah folder logs-nya bisa ditulis – iya, balik lagi ke masalah permission.

Step 4: Cek Permission Folder

Satu penyebab error yang paling sering bikin teknisi garuk-garuk kepala: folder yang nggak writable. CodeIgniter butuh nulis cache dan log ke folder tertentu. Kalau foldernya nggak bisa ditulis, bisa muncul error aneh – mulai dari halaman blank, sampai fitur yang tiba-tiba rusak sendiri.

Folder yang wajib writable: application/cache dan application/logs (CI3), atau seluruh folder writable/ (CI4). Cara cek dan fix via SSH:

cd /home/nama-user/public_html
chmod -R 755 writable/   # CI4
chmod -R 755 application/cache application/logs   # CI3

Nah, kalau setelah chmod 755 masih error, coba upgrade ke 775. Tapi hindari 777 – itu mode paling longgar, dan di shared hosting rawan dimasukin script jahat. Kenapa 755 biasanya cukup? Karena di shared hosting, user cPanel biasanya jadi owner folder. Mode 755 artinya owner boleh baca-tulis, group dan lainnya cuma baca. Kalau error-nya nggak ilang, besar kemungkinan bukan masalah permission, lanjut ke step berikutnya.

Kalau di cPanel dan nggak punya SSH, bisa lewat File Manager: masuk ke folder public_html, klik kanan folder yang mau diubah → Change Permissions, terus set angkanya. Jangan lupa, kalau abis migrasi, cek juga ownership folder-nya – kadang pas di-restore, ownership-nya jadi beda.

Step 5: Cek Konfigurasi Database

Ini penyebab 500 error paling umum kedua. Gejalanya: website tampil “Unable to connect to the database”, atau blank page. Dan pas dibongkar, ternyata config database-nya masih nunjuk ke server lama. Ini paling sering terjadi pas migrasi hosting. Kalau sampeyan butuh pemahaman lebih soal error log MySQL, cek juga panduan error log MySQL kita.

CodeIgniter 3, config ada di application/config/database.php:

$db['default'] = array(
    'hostname' => 'localhost',
    'username' => 'user_db',
    'password' => 'password_db',
    'database' => 'nama_db',
    'dbdriver' => 'mysqli',
);

CodeIgniter 4, config bisa di file .env (paling umum):

database.default.hostname = localhost
database.default.database = nama_db
database.default.username = user_db
database.default.password = password_db
database.default.DBDriver = MySQLi

Yang perlu dicek: apakah hostname, username, password, dan database-nya cocok sama yang ada di cPanel? Sering banget password berubah pas migrasi, tapi config-nya nggak diupdate. Cara cek cepat koneksi dari command line:

mysql -u user_db -p -h localhost nama_db

Kalau bisa masuk, berarti kredensialnya bener – masalahnya di config aplikasi. Kalau ditolak, berarti kredensial di cPanel emang salah, atau user-nya nggak punya akses ke database itu. Di cPanel, cek bagian MySQL Databases buat pastiin user terdaftar dan dapet akses penuh.

Dan jangan lupa, kalau database-nya masih kosong (belum di-import), itu juga bikin error. Website kebuka, tapi pas minta data – bengong, terus error. Cek jumlah tabelnya, bandingin sama database di server lama.

Step 6: Cek Base URL, .htaccess, dan Routing

Kalau database udah aman tapi masih error, sekarang cek bagian URL dan routing. Gejala yang umum: halaman utama kebuka tapi halaman dalam error 404, asset (gambar, CSS, JS) nggak muncul, atau redirect loop.

Base URL. CodeIgniter 3, di application/config/config.php:

$config['base_url'] = 'https://nama-domain.com/';

Sering kejadian: base_url masih pakai domain lama, atau masih http padahal website udah pindah ke https. Efeknya: semua link dan asset jadi salah, dan bisa muncul redirect loop yang bikin browser error “too many redirects”. CodeIgniter 4 biasanya baca baseURL dari .env (app.baseURL). Kalau nggak diset, otomatis dideteksi dari request – tapi hasil deteksinya kadang beda sama yang diharapkan, apalagi kalau di belakang reverse proxy.

.htaccess. File ini yang ngatur supaya URL tanpa index.php tetap kebuka. Kalau file ini ilang atau isinya rusak, halaman dalam bisa 404 semua. Ini contoh isi .htaccess standar untuk CodeIgniter 3:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

Kalau halaman utama kebuka tapi halaman lain 404, prioritas cek: apakah file .htaccess ada, dan isinya mirip kayak di atas. Pastikan juga mod_rewrite aktif – di cPanel biasanya otomatis, tapi di VPS sering lupa diaktifkan. Satu lagi yang sering kelewat: AllowOverride di konfigurasi Apache. Kalau diset None, .htaccess bakal diabaikan total, dan semua rewrite nggak jalan. Buat referensi lengkap soal error 500, baca artikel 500 internal server error kita.

Step 7: Pakai Debug Toolbar

Untuk CodeIgniter 4, ini hadiah paling enak: Debug Toolbar built-in. Pas environment development, di bagian bawah website muncul toolbar berisi info lengkap: query database, memori, durasi eksekusi, session, dan error yang terjadi. Nggak perlu install apa-apa – tinggal klik-klik aja. Ini cara tercepat buat liat query yang gagal atau query yang pelan banget.

Untuk CodeIgniter 3, nggak ada toolbar bawaan. Tapi bisa minta developer pasang library Debug Toolbar dari pihak ketiga, atau pakai cara manual: aktifkan profiler biar muncul info query dan timing di bawah halaman. Caranya tambahkan baris ini di controller atau di hook:

$this->output->enable_profiler(TRUE);

Kalau toolbar muncul, perhatiin tab Database. Di situ keliatan query mana yang error, query mana yang lambat, dan berapa banyak query yang dijalankan per halaman. Ini shortcut banget buat nemuin root cause tanpa baca ratusan baris log.

Step 8: Gunakan last_query Buat Test Query Manual

Kadang masalahnya bukan di koneksi, tapi di query tertentu yang gagal. Minta developer menampilkan query terakhir yang dijalankan, atau kalau sampeyan pegang controller-nya, bisa tambahin ini buat debug:

echo $this->db->last_query();

Hasilnya berupa query SQL lengkap yang tinggal dicoba di phpMyAdmin atau command line, biar kelihatan error-nya apa. Contoh kasus yang pernah kutemui: query yang nunjuk ke nama tabel yang beda karena prefix database nggak diset di config. Dengan last_query, langsung kelihatan nama tabel aslinya, dan ketahuan kalau prefix-nya hilang. Dari situ ketemu solusinya dalam lima menit.

Step 9: Cek Kompatibilitas Versi PHP

Ini yang makin sering terjadi akhir-akhir ini. Server baru biasanya default PHP 8.1 atau lebih baru. Tapi aplikasi CodeIgniter lama yang dibangun di zaman PHP 5.6 bisa langsung jebol. Gejalanya: halaman blank, error deprecated yang numpuk, atau fungsi yang tadinya jalan sekarang ilang.

Cek dulu requirement-nya: CodeIgniter 3 resminya jalan di PHP 5.6+, dan butuh perhatian ekstra di PHP 8 karena banyak fungsi lama yang deprecated (contoh: mysql_real_escape_string dan teman-temannya). CodeIgniter 4 butuh PHP 7.4+, dan baru support PHP 8 penuh di versi 4.1 ke atas.

Cara cek versi PHP yang aktif: php -v via SSH, atau cPanel → Software → MultiPHP Manager. Kalau aplikasinya tua dan server-nya PHP 8, dua pilihan: turunkan versi PHP website ke 7.4 (di shared hosting biasanya bisa per website), atau bawa ke developer buat update kode. Jangan dipaksain, karena deprecated function di PHP 8 bisa bikin blank page tanpa pesan yang jelas. Kalau sampeyan juga nemu server-nya lagi lemot, sekalian cek artikel cara cek high load server.

Error Message Umum dan Artinya

Biar makin pede, kenalin dulu error message yang paling sering muncul di website CodeIgniter dan artinya:

• “Unable to connect to the database” – config database salah: username, password, hostname, atau nama database nggak cocok. Yang pertama dicek selalu ini.
• “A Database Error Occurred” – error pas eksekusi query. Baca baris SQL-nya, biasanya langsung ketahuan tabel atau kolom mana yang bermasalah.
• “Message: Undefined property / Undefined variable” – bug di kode, biasanya karena controller atau model nggak nge-load library dengan bener. Ini ranahnya developer, tapi clue-nya bagus buat dilaporin.
• “404 Page Not Found” – route nggak ketemu. Cek .htaccess, base_url, dan file routes.
• “Call to undefined function” – biasanya masalah versi PHP: fungsi lama yang udah dihapus di PHP versi baru.
• “An Error Was Encountered” – error generik CodeIgniter. Biasanya diikuti penjelasan di bawahnya, jangan cuma baca judulnya.
• “Class not found / File not found” – file ilang atau autoload nggak bener. Sering terjadi pas migrasi, file nggak ikut terpindah.

Nih, tip sederhana: salin pesan error-nya apa adanya, terus tempel ke Google atau tanya ke chatbot AI. Sertain versi CodeIgniter dan versi PHP-nya. Framework sepopuler ini errornya udah banyak yang ngalamin, jadi peluang besar ada yang udah nulis solusinya.

Tabel Troubleshooting Cepat

Biar makin gampang di lapangan, aku rangkum gejala umum, penyebab paling sering, dan cara cek cepat-nya:

Gejala	Penyebab Paling Umum	Cara Cek Cepat
Halaman putih total (blank page)	Error fatal yang disembunyiin, permission folder, PHP version deprecated	Aktifkan CI_ENVIRONMENT=development, baca log CodeIgniter
Error 500 tanpa pesan	Config database salah, .htaccess rusak, file ilang	Cek config database, tes koneksi MySQL
Halaman dalam 404	.htaccess ilang, base_url salah, mod_rewrite mati	Cek .htaccess dan RewriteEngine
“Unable to connect to the database”	Password berubah, database belum di-import, hostname salah	mysql -u user -p, cek config database.php
Asset (CSS/JS/gambar) rusak	base_url masih domain lama atau http	Cek $config[‘base_url’] atau app.baseURL
Website error cuma di halaman tertentu	Query spesifik gagal, bug di controller	Debug toolbar / last_query, baca log error

Simpan tabel ini, soale ini shortcut yang paling sering kepake di lapangan.

Studi Kasus: Website Retail Error Setelah Update PHP

Biar gamblang, ini studi kasus yang pernah aku tangani. Klien website toko online menelepon jam 3 sore, website-nya blank semua. Dari cek cepat: server sehat, MySQL jalan, disk normal. Ternyata sehari sebelumnya, tim klien baru aja update PHP dari 7.4 ke 8.1 lewat cPanel, karena disuruh bank buat sertifikat SSL/TLS yang lebih baru.

Langkah pertama, aku cek error log CodeIgniter di application/logs. Ketemu baris ini:

ERROR - 2026-07-22 15:42:11 --> Severity: error --> Error: Call to undefined function mysql_real_escape_string()

Nah, dari satu baris ini langsung kelihatan masalahnya: kode masih pakai fungsi mysql_real_escape_string yang udah dihapus dari PHP 7 ke atas. Bukan masalah server – masalah kompatibilitas versi. Solusinya dua opsi: turunin versi PHP website ke 7.4, atau suruh developer ganti fungsi lama itu dengan mysqli_real_escape_string atau pindah pakai query builder bawaan CodeIgniter.

Yang keren, dalam 30 menit website balik normal cuma dengan nge-tweak versi PHP. Nggak ada yang namanya “server lemot” atau “resource abis”. Kadang jawabannya memang segampang itu – asal kita nggak panik dan ikutin urutan cek yang bener.

Kalau Nggak Punya SSH?

Banyak shared hosting yang nggak kasih akses SSH ke user biasa. Nggak masalah – semua step di atas tetep bisa dilakukan lewat cPanel:

• File Manager: buat buka index.php, .htaccess, file config, dan folder logs.
• MultiPHP INI Editor: buat set display_errors dan error_reporting.
• MultiPHP Manager: buat ganti versi PHP per website.
• phpMyAdmin: buat tes query SQL dan cek isi database.
• Error Logs (di bawah Metrics): buat liat error log PHP di cPanel. Ingat, ini beda sama log CodeIgniter – dua-duanya perlu dicek.

Nah, kalau lewat File Manager nggak bisa ngubah permission folder, minta tolong support hosting sampeyan. Kadang support-nya bisa bantu, apalagi kalau sampeyan udah punya diagnosis yang jelas kayak “folder writable yang permission-nya salah”.

Pro Tips dari Pengalaman

• Pertanyaan pertama yang harus ditanya ke klien: “Baru ngubah apa?” Sembilan dari sepuluh kasus, jawabannya ada di situ – baru deploy, baru ganti password DB, baru pindah server, baru update PHP.
• Jangan cuma liat baris terakhir error log. Sering error yang pertama cuma efek samping dari error sebelumnya. Baca dari atas, pahami urutannya. Error yang paling kelihatan nggak selalu akar masalahnya.
• Kalau website habis dipindah dari server lama, prioritasin cek tiga hal: config database, base_url, dan .htaccess. Tiga-tiganya biang kerok utama migrasi CodeIgniter.
• Salin error message-nya apa adanya sebelum nyari solusi. Clue yang sampeyan dapet dari log itu emas – jangan diilangin.
• Selalu catat tanggal dan jam error pertama kali muncul. Ini yang bikin sampeyan bisa cocokin sama perubahan yang terjadi di waktu yang sama.

FAQ

Kesimpulan

Jadi, debugging CodeIgniter itu bukan soal bisa coding atau nggak – tapi soal tahu urutan cek yang bener. Ringkasnya: aktifkan development mode, tampilkan error PHP, baca log CodeIgniter, pastikan permission folder aman, cek config database, cek base_url dan .htaccess, terus kalau masih buntu, pakai debug toolbar atau last_query. Terakhir, jangan lupa cek versi PHP.

Monggo dipraktekno step-step di atas di server sampeyan. Nek isih stuck, tinggal catet pesan error-nya, terus explore di Google atau tanya ke chatbot AI dengan clue versi CodeIgniter dan versi PHP-nya. Mugi-mugi sampeyan gak sampai ngalamin malam Jumat panik kayak aku. Kalau nanti nemu kasus yang menarik, share di komentar ya – sopo ngerti, iso bantu kanca-kanca teknisi liyane. Good luck!