How to Debug a CodeIgniter Website: Step-by-Step Guide 2026

The White Screen That Launched a Thousand Tickets

3:47 PM on a Tuesday. The ticket pops in: “URGENT – website down, white screen.” You log in, check Apache, MySQL, disk – everything’s green. But the site? Blank. Not even an error message. Just nothing. If you’ve worked hosting support for more than a week, you’ve seen this exact case. And here’s the thing most techs miss: if the app is built on CodeIgniter, the problem is probably not your server. Once you learn how to debug a CodeIgniter website the right way, tickets like this stop being scary.

I’ve lost count of how many times I’ve jumped on a server expecting a resource problem, only to find the box was perfectly healthy while the app quietly died on its own. The scary part? The logs you’re used to reading – Apache’s error.log, PHP-FPM’s output – often have nothing useful. The framework keeps its own secrets, in its own folders. So here’s the deal: this guide is written for hosting technicians who are not CodeIgniter developers. You don’t need to know PHP inside out. You need a repeatable workflow and the right clues to hand off to a developer or to search for. That’s what we’re building here.

Debugging a CodeIgniter Website: What You’re Really Up Against

A blank page might not sound serious, but think about it from the client’s side. If it’s a webshop, every minute of downtime is lost revenue. If it’s a news portal, readers assume the site is dead and they don’t come back. And if this is a production environment serving thousands of visitors, a broken page doesn’t just mean a support ticket – it means an angry client, maybe a formal complaint, and a very long night. That’s the stakes, and why it pays to solve these fast.

The reason CodeIgniter trips up hosting techs is that it sits on top of PHP with its own layer of error handling. Normal PHP apps write fatal errors straight to the server log. CodeIgniter catches them first, decides what to show based on its environment mode, and keeps a log of its own – in a folder you might not even know exists. If that logging is switched off, the error just vanishes. No trace. That’s why you’ll sometimes stare at a healthy server and a blank site with zero clues. And when clues are missing, techs start guessing – and guessing is slow.

Here are the symptoms you’ll actually see in tickets: a full 500 error with no message, a completely white page, a redirect loop that makes the browser give up with “too many redirects”, or a site that only breaks on certain pages. The causes are usually a short list: wrong folder permissions, database credentials that don’t match, a PHP version too new for the framework, a missing or corrupted .htaccess, or a config file that still points at the old server after a migration. If at least one of these rings a bell, keep reading – the fix is closer than you think.

CodeIgniter, Explained for People Who Don’t Build Apps

Here’s a mental model that’s served me well. CodeIgniter is like a fully stocked kitchen. It comes with every tool already on the shelf – database connections, URL routing, sessions, security helpers. A developer just picks a recipe and cooks. Now imagine that kitchen starts making a weird noise. You’re the appliance repair person. You don’t need to be a chef. You need to know which part of the kitchen is making the noise, and you need to describe it clearly to the owner.

The good news? Because everything is structured, debugging follows a pattern. Same symptoms, same checklist. Once you learn the order, you can trace almost any error from symptom to root cause. That’s the checklist we’re building now.

What You Need Before You Start

Grab these first. Missing one means you’ll be blocked halfway through:

• SSH access (easiest), or at least cPanel File Manager.
• The app’s file location – usually public_html, sometimes a subfolder like public_html/app.
• Database name, user, and password – you’ll need them to verify the config.
• The site’s current PHP version (cPanel: Software → MultiPHP Manager).
• A one-line answer to “what changed recently?” – this is worth more than any command.

One rule before we start: back up any config file before you edit it. It takes ten seconds and saves you an hour. Now let’s work through the steps in the order that catches the most problems first.

Step 1: Flip the Environment to Development

The single most useful thing you can do. CodeIgniter has two personalities: production (which hides error details on purpose) and development (which spills everything). That white page you’re staring at is CodeIgniter being polite in production mode. Let’s make it talk.

CodeIgniter 3 – open index.php at the app root and find this line:

define('ENVIRONMENT', 'production');

Change it to:

define('ENVIRONMENT', 'development');

CodeIgniter 4 – look for a .env file at the app root. If it doesn’t exist, rename env.example to .env. Then set:

CI_ENVIRONMENT = development

Refresh the page. If you now see a real error message – file name, line number, what went wrong – that’s your golden clue. Congratulations, you just turned a mystery into a to-do list. If the page is still white after this, move on to step 2.

Step 2: Force PHP Errors Onto the Screen

Sometimes dev mode alone isn’t enough. On CodeIgniter 3, PHP error reporting can still be clamped down. Check index.php for these two lines:

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

That means: show every error, hide nothing. CodeIgniter 4 does this automatically in development mode. But here’s the catch I see people hit: if the server’s php.ini has display_errors set to off, your app-level setting won’t matter – errors stay hidden. You can try the .htaccess route:

php_flag display_errors On
php_value error_reporting E_ALL

Important: php_flag only works with mod_php. Modern cPanel setups usually run PHP-FPM, where these directives are silently ignored. In that case, use the MultiPHP INI Editor in cPanel, or edit php.ini directly on a VPS. Not sure which handler you have? Ask the server admin, or check with a quick phpinfo() file.

One more thing: don’t rely only on on-screen errors. The written log gives you a timestamp and a stack trace – way more detail. Screen for speed, logs for depth. Use both.

Step 3: Read the Framework’s Own Log

If nothing shows on screen, go read CodeIgniter’s log. It keeps its own, completely separate from Apache’s. This is the part most techs never find:

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

The filename contains the date, so open the one matching the incident. A real CodeIgniter 3 log looks like this:

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

Read it line by line – each line is a clue:

• Line one: database connection failed. Check the DB config or MySQL’s status.
• Line two: an old PHP function that no longer fits the installed PHP version. A compatibility issue.
• Line three: a 404. That’s routing – usually base_url or .htaccess.

But logs only fill if logging is on. CodeIgniter 3, in application/config/config.php:

$config['log_threshold'] = 4;

4 means log everything. CodeIgniter 4, in app/Config/Logger.php:

public $threshold = 9;

Then refresh the site and reopen the log. Fresh errors land at the bottom. If it’s still empty, the log folder probably isn’t writable – which brings us to step 4.

Step 4: Check the Writable Folders

A top cause of weird, silent failures: folders the app can’t write to. CodeIgniter needs to write cache and log files to function. If it can’t, you get blank pages or features that quietly die. And the error message is usually nowhere to be found.

Folders that must be writable: application/cache and application/logs (CI3), or the whole writable/ folder (CI4). From SSH:

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

If 755 doesn’t fix it, try 775. Avoid 777 – it’s wide open and a magnet for malware on shared hosting. Why is 755 usually enough? Because on cPanel, the site owner is typically the folder owner, and 755 gives the owner full write access. If the site is still broken after that, it’s not a permission problem – move on.

No SSH? Use File Manager, right-click the folder, choose Change Permissions, and type the number. And after any migration, double-check folder ownership – restores can silently change it, and a wrong owner behaves exactly like wrong permissions.

Step 5: Verify the Database Configuration

The second most common cause of 500s. Symptom: “Unable to connect to the database”, or a blank page. Open the config, and nine times out of ten you’ll find credentials pointing at the old server. If you need a deeper refresher on database-side logs, we have a full guide to reading MySQL error logs.

CodeIgniter 3 – application/config/database.php:

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

CodeIgniter 4 – usually in the .env file:

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

Cross-check every value against cPanel. Passwords love to change during migrations, and configs hate being updated. Quick test from the shell:

mysql -u user_db -p -h localhost nama_db

Login works? The credentials are fine – the app config is the problem. Login fails? Fix the credentials, or grant the user access under cPanel → MySQL Databases.

One more that catches people: an empty database causes the same symptoms. The site loads, then errors the moment it asks for data. Compare table counts against the old server before you go digging into code.

Step 6: base_url, .htaccess, and Routing

If the database checks out but errors persist, look at URL handling. Common signs: homepage loads but inner pages 404, assets (CSS, JS, images) broken, or a redirect loop. These three config points cause almost all of it.

Base URL. CodeIgniter 3 – application/config/config.php:

$config['base_url'] = 'https://yourdomain.com/';

I keep finding base_url stuck on an old domain, or on http after the site moved to https. Result: every link and asset is wrong, sometimes a redirect loop. CodeIgniter 4 usually reads baseURL from .env (app.baseURL). If it’s unset, it auto-detects from the request – but detection can be wrong behind proxies, so setting it explicitly is safer.

.htaccess. This file makes pretty URLs work without index.php. If it’s missing or corrupt, inner pages 404. A standard CodeIgniter 3 version looks like this:

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

Homepage fine but inner pages 404? Check that the .htaccess exists and matches the pattern above. Confirm mod_rewrite is enabled – cPanel usually has it, VPS installs often forget it. And a sneaky one: AllowOverride must not be None in the Apache config, or .htaccess is ignored entirely. For a deeper dive on this exact symptom, see our guide to fixing 500 internal server errors.

Step 7: Use the Debug Toolbar

CodeIgniter 4 gives you the best debugging toy for free: the Debug Toolbar. In development mode, a bar appears at the bottom of the page with database queries, memory usage, execution time, session info, and errors. No install, no config – just click around. It’s the fastest way to spot a failing query or a painfully slow one.

CodeIgniter 3 has no built-in toolbar, but you can enable the profiler to dump query and timing info under the page. Add this line in a controller (or ask the developer to):

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

Then check the Database tab. You’ll see which queries error and which are slow – a massive shortcut compared to reading hundreds of log lines.

Step 8: last_query for Manual Testing

Sometimes the connection is fine but one specific query fails. Ask the developer to print the last executed query, or if you’re in the controller, add:

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

You’ll get the full SQL. Run it in phpMyAdmin or from the CLI and the error shows up immediately. I once traced a bug to a query hitting the wrong table because the database prefix wasn’t set in config. One line of output, root cause found, fixed in five minutes.

Step 9: Check PHP Version Compatibility

This one is on the rise. Fresh servers default to PHP 8.1 or newer, but older CodeIgniter apps built for PHP 5.6 can die on contact. Symptoms: blank page, a pile-up of deprecation notices, or functions that used to exist and are now gone.

Know the requirements: CodeIgniter 3 officially runs on PHP 5.6+, with extra care needed on PHP 8 (old functions like mysql_real_escape_string were removed entirely). CodeIgniter 4 needs PHP 7.4+, with full PHP 8 support from version 4.1 onward. If the app is old and the server is on PHP 8, you have two options: drop the site’s PHP version to 7.4 (shared hosting usually allows per-site), or hand the code to a developer for an update. Don’t force it – a deprecated function in PHP 8 can blank a page with no message at all. If the server itself is also running hot, check our high load server troubleshooting guide.

Common Error Messages and What They Mean

To feel more confident, memorize these messages you’ll see over and over on CodeIgniter sites:

• “Unable to connect to the database” – credentials mismatch. Check username, password, hostname, and database name. Always check this first.
• “A Database Error Occurred” – the query itself failed. Read the SQL below it; the offending table or column is usually right there.
• “Message: Undefined property / Undefined variable” – a code bug, usually a library not loaded in a controller. Developer territory, but a great clue to report.
• “404 Page Not Found” – routing issue. Check .htaccess, base_url, and the routes file.
• “Call to undefined function” – a PHP version problem. An old function that was removed in the current PHP.
• “An Error Was Encountered” – CodeIgniter’s generic error. Read what follows it; don’t stop at the heading.
• “Class not found / File not found” – a missing file or broken autoload. Common after a migration when files didn’t make the trip.

Pro tip: copy the exact error string and search it together with your CodeIgniter and PHP versions. This framework is everywhere – someone, somewhere, has hit your exact error and written about it.

Quick Troubleshooting Table

Here’s the cheat sheet I keep on my desk – symptom, most likely cause, and where to look:

Symptom	Most Likely Cause	Quick Check
Total blank page	Fatal error hidden, folder permissions, deprecated PHP	Set CI_ENVIRONMENT=development, read the CodeIgniter log
500 error with no message	DB config wrong, .htaccess broken, missing file	Verify DB config, test MySQL connection
Inner pages 404	Missing .htaccess, wrong base_url, mod_rewrite off	Check .htaccess and RewriteEngine
“Unable to connect to the database”	Changed password, empty database, wrong hostname	mysql -u user -p, check database.php
Broken CSS/JS/images	base_url still on old domain or http	Check $config[‘base_url’] or app.baseURL
Errors only on certain pages	Failing specific query, controller bug	Debug toolbar / last_query, check log

Keep this table handy – it resolves most cases before you even open a file.

Real Case: A Retail Site Dies After a PHP Upgrade

Here’s one I handled recently. A retail client called at 3 PM – site completely blank. Server checks: healthy. MySQL: up. Disk: fine. The tell? A day earlier, they’d upgraded the site’s PHP from 7.4 to 8.1 in cPanel, nudged by their bank’s SSL requirements.

First stop: the CodeIgniter log. One line said it all:

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

That’s not a server fault – it’s a compatibility fault. mysql_real_escape_string was removed in PHP 7. Two options: drop the site back to PHP 7.4, or have the developer swap to mysqli_real_escape_string (or better, the query builder). We chose the quick option. Site back online in 30 minutes. No panic, no hardware talk, just a checklist followed in the right order.

No SSH? No Problem

Not every host gives shell access on shared plans. That’s fine – every step above works from cPanel:

• File Manager: edit index.php, .htaccess, and config files; read the log folders.
• MultiPHP INI Editor: set display_errors and error_reporting.
• MultiPHP Manager: switch the PHP version per site.
• phpMyAdmin: test queries and verify database contents.
• Error Logs (under Metrics): read Apache’s log – different from CodeIgniter’s, so check both. We have a dedicated write-up on reading PHP error logs in cPanel if you want more.

Stuck changing folder permissions in File Manager? Open a ticket with your host and give them a specific ask: “the writable folder has wrong permissions.” Specific diagnoses get faster help.

Pro Tips From the Field

• First question to any client: “What changed?” Nine times out of ten, the answer contains the root cause – a deploy, a password change, a server move, a PHP update.
• Don’t just read the last line of a log. Earlier errors often cause the later ones. Read top to bottom; the flashiest error isn’t always the root cause.
• After any migration, check three things first: DB config, base_url, .htaccess. They cause most post-move breakage.
• Copy error messages verbatim before searching. The exact wording matters – a single word difference changes the search results.
• Write down when the error first appeared. Matching it to a change at the same time closes cases fast.

FAQ

Wrapping Up

Here’s the whole workflow compressed: flip to development mode, surface PHP errors, read the framework log, check writable folders, verify the DB config, check base_url and .htaccess, then use the debug toolbar or last_query. Finally, check the PHP version. That order has rescued me from more “impossible” tickets than I can count.

Next time a CodeIgniter ticket lands in your queue, run this list before you call the developer. And if you hit a case that doesn’t fit the pattern, drop a comment – that’s how the community gets smarter. Happy debugging!