Top 60 CodeIgniter Interview Questions (2026)

CodeIgniter is a light, fast PHP web framework built on the Model-View-Controller pattern. It ships with libraries for the tasks web apps repeat, routing, database access, form validation, sessions, and security, so you write far less boilerplate and spend your time on features instead of plumbing that every app needs.

Teams reach for it to build server-rendered web apps and APIs quickly, especially when they want a small footprint, little configuration, and a gentle learning curve rather than the deeper feature set of a heavier framework.

MVC splits an application into three parts with clear jobs. The Model handles data and database logic, the View handles presentation and produces the HTML sent back, and the Controller handles the request itself: it takes the input, calls the models it needs, and picks which view to render with the result.

The flow is: a route maps a URL to a controller method, the controller asks a model for data, then passes that data to a view. Keeping data, presentation, and request handling separate is what makes the code testable and easy to change.

CodeIgniter 4 is a full rewrite, not an incremental update. It requires PHP 7.4 or newer, adds namespaces and PSR-4 autoloading, introduces the spark command-line tool, and reworks the whole model layer. CodeIgniter 3, by contrast, feels procedural, runs on much older PHP, and loads things through $this->load.

Practically, in 4 you write classes with namespaces, load things through dependency helpers instead of $this->load, and use spark for migrations and generators. Most concepts carry over, but the syntax and structure are cleaner.

The folders that matter are app (all your code: Controllers, Models, Views, Config, Filters), public (the web root, holding index.php and static assets), writable (logs, cache, sessions, and uploads), system (the framework core you never edit), and tests. Requests only ever enter through public.

Requests hit public/index.php, which is the front controller. Everything you build lives in app. Keeping the web root at public means the rest of the code sits outside the browser's reach.

A controller is a class that handles incoming requests, and each of its public methods is an action a route can point to. Inside an action you read input from the request, call models or libraries to do the work, and then return either a rendered view or a response object back to the browser.

In CodeIgniter 4 a controller extends BaseController, lives in app/Controllers, and uses a namespace. You can generate one with spark to get the boilerplate right.

A view is the presentation layer: a PHP file, usually kept in app/Views, that holds the HTML sent back to the browser. The controller passes data into it as an associative array, and the view echoes those values into the markup, keeping display logic out of the controller where it doesn't belong.

In CodeIgniter 4 you render one with the view() helper, which returns the rendered string. You can pass data as a second argument and read it by key inside the view.

A model is a class that represents one database table and holds the data-access logic for it. In CodeIgniter 4 it extends CodeIgniter\Model, and you configure it by setting properties: the table name, the primary key, the allowed fields, and whether it manages timestamps automatically for you.

That base class hands you ready-made CRUD methods: find(), findAll(), insert(), update(), delete(), plus validation and the query builder scoped to the table. You get a working data layer with almost no code.

Routing maps an incoming URL and HTTP verb to a specific controller method. You define routes in app/Config/Routes.php using the verb as the method name: for example, $routes->get('products', 'Products::index') sends a GET request on /products to the index() method of the Products controller class.

You can capture URL segments with placeholders like (:num) or (:segment) and pass them as method arguments. Defined routes are explicit and preferred; there's also auto-routing that maps URLs to controllers by convention, off by default in newer versions.

The query builder is a fluent interface that assembles SQL for you: you chain methods like table(), select(), where(), and get() instead of writing raw SQL strings by hand. It escapes and binds values automatically as you chain, which is what protects your queries against SQL injection without any extra effort.

You use it because it's safer (automatic escaping and binding), more readable, and database-agnostic, so the same code works across MySQL, PostgreSQL, and others. Raw queries still exist for the rare case the builder can't express.

Helpers are files of standalone functions grouped by purpose: the form helper, url helper, text helper, and more. They're plain procedural functions, not classes, meant for small repeated tasks you don't want to rewrite in every controller and view across the app.

You load a helper before using its functions, either in a controller with helper('form') or globally in the BaseController. Once loaded, functions like form_open() or base_url() are available anywhere.

A helper is a set of standalone functions that are procedural and stateless, loaded and called directly. A library is a class with methods and often internal state, like the session library, the email library, or the validation library, which you use as an object rather than a loose function.

The rule of thumb: reach for a helper for a small utility function, and a library when you need an object that holds configuration or state across calls. Libraries are usually accessed as services in CodeIgniter 4.

Database settings live in app/Config/Database.php, and credentials usually come from the .env file so they stay out of version control. You get a live connection by calling \Config\Database::connect(), which reads that config and returns the default connection group defined there.

From that connection you use the query builder via table(), or run raw queries with query(). Models create their own connection automatically, so inside a model you rarely connect by hand.

spark is CodeIgniter 4's command-line tool, which you run with php spark from the project root. It starts a local development server, runs and rolls back database migrations, seeds data, clears caches, lists routes, and generates boilerplate classes like controllers and models so you don't write them by hand.

Common commands: php spark serve to run the app, php spark migrate to apply migrations, and php spark make:controller Name to scaffold a class. It saves you from writing boilerplate by hand.

You define rules per field and run them against the incoming request. Inside a controller, $this->validate() takes an array of field rules, returns false if any of them fail, and lets you read the failure messages with $this->validator->getErrors() so you can show them back on the form.

Rules are strings like 'required|min_length[3]|valid_email'. You can also centralize rule sets in app/Config/Validation.php and reference them by name, which keeps controllers clean.

The session library stores per-user data across requests. You get it with session() or service('session'), then set and read values like an array. By default data lives in files under writable, but you can switch the handler to the database, Redis, or Memcached.

Flashdata is a common feature: values that survive exactly one more request, ideal for a 'saved successfully' message after a redirect.

base_url() is a url-helper function that returns your application's root URL, optionally with a path appended to it. You use it to build links and asset URLs so they keep working no matter where the app is hosted, in a subfolder, on staging, or on the production domain.

It reads the baseURL setting from app/Config/App.php (commonly set through the .env file as app.baseURL). Setting it correctly matters because wrong base URLs break assets and links after deploy.

Read input through the request object rather than the raw PHP superglobals like $_GET and $_POST. Inside a controller, $this->request->getGet('key') reads query-string parameters, $this->request->getPost('key') reads submitted form fields, and $this->request->getVar('key') reads from either source when you don't care which one the value came from.

Going through the request object is the recommended way: it's consistent, testable, and keeps a single input path. Reaching straight into $_POST is discouraged.

Define a route with a placeholder and the framework captures that URL segment and passes it straight into your controller method as an argument. For example, $routes->get('user/(:num)', 'User::show/$1') matches a numeric segment and hands the number to show($id) as its first parameter.

Placeholders include (:num) for digits, (:alpha) for letters, (:alphanum), (:segment) for one segment, and (:any) for anything. Matching the right placeholder is both cleaner and a light validation on the URL.

CodeIgniter gives you several out of the box: CSRF protection for forms, automatic escaping in the query builder to block SQL injection, the esc() function and view escaping to defend against XSS, secure password hashing through PHP's own functions, and content-security and header controls you can apply through filters on your routes.

The point is that safe defaults are built in. You still have to use them correctly: escape output, keep CSRF on, and never trust input, but the framework gives you the tools rather than making you build them.

CodeIgniter 4 loads classes on demand through PSR-4 autoloading, using Composer's autoloader plus its own. A class is found by its namespace: the App namespace maps to the app folder, so App\Controllers\Blog resolves to the file app/Controllers/Blog.php without any manual include.

You register extra namespaces or classmaps in app/Config/Autoload.php. This replaced CodeIgniter 3's manual autoload lists; now files load on demand by namespace rather than being listed up front.

The .env file holds environment-specific settings like database credentials and the base URL, and it stays out of version control on purpose. Values there override the defaults baked into the Config classes at runtime, so the exact same code runs in development and production while pointing at different databases and URLs.

CIEnvironment (development, testing, production) controls behavior like error display: development shows detailed errors, production hides them. Setting it correctly is a common source of 'why are errors leaking' bugs.

Use the response object rather than echoing JSON yourself. Calling return $this->response->setJSON($data) serializes the array or object to JSON and sets the correct content-type header for you, and you can chain setStatusCode() before it to control the HTTP status code the client receives.

This is the standard way to build API endpoints in CodeIgniter 4. The response object also handles headers, status codes, and other body formats when you need them.

A request first hits public/index.php, the single front controller for the whole app. The framework boots, the Router matches the URL against app/Config/Routes.php, and any before filters run: CSRF, auth, throttling. Then the matched controller method executes, usually calling models for data and rendering a view with the result.

The controller returns a Response object. After filters run on the way out (things like adding headers or CORS), and the response is sent to the browser. Understanding this order explains where to hook auth (a before filter) versus response tweaks (an after filter).

Filters are classes with before() and after() methods that run around controllers. Before filters can short-circuit a request (return a redirect or a 401); after filters can modify the response. They handle cross-cutting concerns: authentication, CSRF, rate limiting, CORS, logging.

You register aliases in app/Config/Filters.php and apply them globally, by route, or by group. This is cleaner than repeating auth checks in every controller method.

The base Model gives you find($id) and findAll() to read, insert($data) to create a row, update($id, $data) to modify one, and delete($id) to remove one. On top of those, save($data) is smart: it inserts when the data has no primary key and updates when it does, so one call handles both create and edit.

You also chain query builder methods before these: $model->where('active', 1)->findAll(). Only fields listed in $allowedFields are mass-assignable, which is a guard against unexpected columns being written.

$allowedFields is a property on the model that lists exactly which columns it may write during insert() and update() calls. Any field you pass that isn't on that list is silently dropped from the mass-assignment, so only the columns you explicitly named ever reach the database.

It matters for security: without it, a user could submit extra form fields (like is_admin or role) that get written straight to the database, a mass-assignment vulnerability. The allowlist is the fix, and forgetting to add a legitimate field is also the reason 'my update isn't saving' bugs happen.

The join() method adds a SQL join, taking the table, the on condition, and an optional join type. To control boolean grouping, groupStart() and groupEnd() wrap a set of conditions in parentheses, and orWhere() adds an OR condition alongside the where() calls in the chain.

The builder still escapes values, so you get safe, readable SQL. For conditions the builder can't express, you can drop a raw fragment, but reach for that rarely.

Migrations are versioned PHP files that describe database schema changes: creating tables, adding columns, adding indexes. Each one has an up() method to apply the change and a down() method to reverse it, so the full history of your schema lives in code alongside the app and travels with it through version control.

You generate one with spark, then run php spark migrate to apply pending migrations and php spark migrate:rollback to undo. This keeps every environment's schema in sync without hand-run SQL.

Seeders are classes that populate the database with rows: either reference data the app needs to run (countries, roles, default settings) or fake data for development and testing. You run one from the command line with php spark db:seed ClassName, and a seeder can call other seeders to build a full data set.

You use them to make a fresh clone of the app usable immediately and to give tests a known starting state. Migrations shape the schema; seeders fill it.

A model can carry its own $validationRules and $validationMessages as properties. When you insert() or update() through that model, it runs those rules automatically and fails the write if any rule doesn't pass, and you read what went wrong through $model->errors() afterward instead of validating by hand.

This keeps data rules next to the data, so every write path enforces them, not just the one controller that remembered to validate. It's a layer beyond controller-level $this->validate(), useful when the same model is written from several places.

Write a method that returns true or false, place it in a class under app/Validation, and register that class in app/Config/Validation.php under the $ruleSets property. Once it's registered, you reference the rule by its method name in any rules string, right alongside the built-in rules like required.

Custom rules cover checks the built-ins don't, like 'must be a valid coupon code' or a cross-field comparison. The signature receives the value and can receive parameters and the whole data array.

When CSRF protection is on, CodeIgniter generates a token and expects it back on every non-GET request. In HTML forms, form_open() or the csrf_field() helper inserts a hidden field with the token; the framework validates it and rejects requests without a valid one.

You enable it through the csrf filter or the Security config, and pick between cookie-based and session-based token storage. For AJAX, you send the token in a header. It stops a third-party site from forging state-changing requests as your logged-in user.

Escape on output. The esc() function encodes a value for the context it lands in: esc($value) does HTML by default, with separate contexts for attributes, JavaScript, CSS, and URLs. You wrap any user-supplied value in esc() before echoing it into a page, so injected markup renders as text instead of running.

The rule is escape on output, not on input, because the safe encoding depends on where the value lands. Storing raw and escaping at render keeps the data clean and the page safe.

Services are a central registry for framework objects: the router, request, response, session, validation, and many more. You fetch a shared instance with service('name'), or ask for a brand-new one by passing false as the shared argument. In effect, Services is CodeIgniter's lightweight dependency container.

The value is swappability: because everything comes through Services, you can override a service in app/Config/Services.php to return your own subclass, and the whole framework uses it. It's how CodeIgniter stays extensible without hard-coding classes.

The View layout system lets a child view extend a shared parent layout. The layout defines named holes with renderSection(), and a child view fills each hole using section() and endSection(). This replaces copy-pasting the same header and footer into every page, keeping the page shell defined in exactly one file.

You mark a view as extending a layout with extend(), then define only the parts that change. This keeps a consistent page shell in one file.

A view cell is a small, self-contained piece of a page rendered by a method that returns its own markup: a shopping-cart summary, a recent-posts widget, a login box. You invoke it from any view with view_cell(), and the cell method fetches whatever data it needs on its own rather than relying on the page's controller.

They're useful for reusable fragments that need their own logic without cluttering the controller. The cell method fetches its own data, so the page's controller doesn't have to know about every widget on the page.

CodeIgniter has a central exception handler that behaves differently by environment. In development it shows a detailed debug page with the full stack trace, while in production it shows a generic error page and quietly logs the details instead. The CI_ENVIRONMENT setting is what decides which of those you get.

You throw framework exceptions like PageNotFoundException to trigger a 404, and you can register custom handlers. Logs go to writable/logs at a threshold you set. Getting the environment right is what keeps stack traces out of production responses.

The Model has a built-in paginate() method: calling $model->paginate(20) returns just one page of results and sets up a pager object behind the scenes. Then in the view, $pager->links() renders the numbered page links, reading which page to show from the query string automatically.

This wires the limit, offset, and link generation together so you don't compute page math by hand. You control per-page count, the page-number parameter, and the link template.

Get the uploaded file from the request with $this->request->getFile('field'), confirm it's valid and hasn't already been moved, then call move() to store it in a writable folder. Validate the size and type first, either through validation rules or by inspecting the file object, before you trust anything a user uploaded.

Using a generated random name with getRandomName() avoids collisions and hides original filenames. Always validate the MIME type and extension, since trusting the client-supplied name is a common upload hole.

Wrap the writes between $db->transStart() and $db->transComplete(): if any query inside fails, the framework rolls the whole set back automatically, and it commits only when everything succeeded. For manual control, use transBegin() and then transCommit() or transRollback() yourself based on your own application logic.

Transactions matter when several writes must all succeed or all fail together, like deducting stock and recording an order. Without one, a mid-operation failure leaves the database half-updated.

Configuration in CodeIgniter 4 is class-based. Each config file in app/Config is a PHP class with public properties, like App, Database, or one you write yourself. You read one with config('App') or new \Config\App(), and any property can be overridden by a matching value in the .env file at runtime.

This is different from CodeIgniter 3's config arrays: type hints, IDE autocomplete, and a clear place for defaults. Environment-specific values go in .env so secrets stay out of the repo.

A model represents a table and handles the queries against it. An entity, by contrast, represents a single row as a typed object, where you define type casts, computed properties, and small business methods that belong to that record. A model can hand back entities instead of plain arrays by setting its $returnType property.

The split is data access (model) versus data behavior (entity). Entities give you things like automatic type casting, a full_name accessor from first and last name, and mutators that transform values on set, keeping row logic out of controllers.

CodeIgniter uses the Services layer as a lightweight service locator rather than a full auto-wiring container like Symfony's. You register how to build an object once in Services, then pull it anywhere with service('name'), and overriding that one method replaces the object everywhere the framework and your code use it.

The honest senior take: it's a service locator, not constructor auto-wiring like Symfony's container. That keeps it simple and fast but means you wire dependencies explicitly through Services or pass them in yourself. For most CodeIgniter apps that's enough; teams needing full DI sometimes add a container.

Events let code publish a named signal that any number of listeners subscribe to, decoupling the thing that happens from the reactions to it. Events::on('user_registered', $callback) registers a listener, and Events::trigger('user_registered', $user) fires it. The framework also emits its own events like 'pre_system' and 'post_controller_constructor'.

Use them to hang side effects off a moment without wiring them into the main flow: send a welcome email on registration, invalidate a cache after a save. The trade-off is indirection, so keep listeners discoverable or the control flow gets hard to follow.

The Cache library puts several storage handlers (file, Redis, Memcached, and others) behind a single interface, so your code doesn't change when the backend does. You store a value with cache()->save($key, $value, $ttl) and read it back with cache()->get($key), and CodeIgniter also offers query caching and full-page caching on top.

Choose the handler by deployment: file cache for a single server, Redis or Memcached when several servers share cache. The real work is invalidation: cache computed or expensive reads, set a sensible TTL, and clear the key when the underlying data changes so you don't serve stale results.

Extend ResourceController, which maps HTTP verbs to methods (index, show, create, update, delete) and gives helpers like respond() and failNotFound() for JSON responses with the right status codes. Register it with $routes->resource() to wire the verb-to-method mapping in one line.

Layer filters for auth and rate limiting, use models for data, and return consistent JSON with proper status codes. For versioning, group routes under a prefix. This gives you a clean REST surface without hand-writing every route.

The N+1 happens when you fetch a list, then loop and run one more query per row (one query for posts, then one per post to get its author). It looks fine on ten rows and falls over on a thousand.

Spot it by watching the query count: enable the debug toolbar or log queries and count them per request. Fix it by fetching related data in one query with a join, or by loading the parent set and then all children in a single WHERE IN query, then stitching them in PHP.

CodeIgniter is built to be extended rather than edited. To swap a core piece, you subclass it and override the matching factory method in app/Config/Services.php, so the framework hands out your version everywhere it uses that object. For controllers, you put shared logic in BaseController and have your controllers extend it.

This is cleaner than editing the system folder, which you never touch because updates would overwrite it. The Services override point is the sanctioned seam for changing framework behavior.

Define extra named connection groups in app/Config/Database.php beyond the default one: a reporting connection, a read replica, or a legacy database, each with its own credentials. You then open a specific one by passing its name to \Config\Database::connect('groupName') instead of taking the default.

Models can point at a group through $DBGroup. Common uses are read/write splitting (writes to primary, reads to a replica) and talking to a second database. The connection is lazily opened, so naming a group doesn't cost you until you query it.

CodeIgniter 4 ships with PHPUnit integration and test helpers. You extend CIUnitTestCase, and traits add abilities: DatabaseTestTrait for migrations and a test database, FeatureTestTrait to call routes and assert on the response, and ControllerTestTrait to test a controller in isolation.

The pattern is feature tests that hit a route and check status and body, plus unit tests on models and services. A separate test database plus migrations gives each run a known state.

The Throttler service is a token-bucket rate limiter backed by the cache. You call $throttler->check($key, $capacity, $seconds), passing a key like the caller's IP; it returns false once that caller has used up its allowance in the window, and at that point you return a 429 Too Many Requests response.

You usually wire it into a before filter keyed by IP or user so it protects an endpoint without touching controller logic. Because it's cache-backed, it works across processes; with Redis it works across servers too.

For non-form requests, CodeIgniter still expects the CSRF token, so you send it in a header or request body. Read the current token name and value with csrf_token() and csrf_hash(), and attach it to each request. With cookie-based tokens you can read it from the cookie the framework sets.

The subtlety is token regeneration: if regenerate is on, the token rotates per request, so your front end must read the new token from each response rather than reusing a stale one. Getting that wrong causes intermittent 403s that only show up under real traffic.

Create a class under app/Commands that extends BaseCommand, set its $group, $name, and $description properties, and implement the run() method with your logic. It then shows up automatically in the php spark list, and you invoke it by name, with any arguments and options parsed and handed to run() for you.

Custom commands are how you script one-off maintenance and scheduled jobs: nightly cleanup, importing a feed, backfilling a column. Pairing them with the system cron gives you background tasks without extra infrastructure.

The response object can format by content type, and the API response traits pick a format based on the request's Accept header or a configured default. respond() serializes to JSON or XML depending on the negotiated format, so one action can serve both.

You set the allowed formats in the config and let negotiation choose, or force one with setJSON()/setXML(). This keeps a single endpoint serving a JSON client and an XML client without branching logic in the controller body.

The default file session handler stores data on local disk, so behind a load balancer a user's requests can land on a server that doesn't have their session, and they appear logged out at random. That's the classic multi-server session bug.

The fix is a shared session handler: point the session config at the database, Redis, or Memcached so every server reads the same store. Sticky sessions at the balancer are a workaround, but a shared handler is the durable answer and also survives a single server dying.

Drop to raw SQL when the builder can't express the query cleanly: window functions, complex CTEs, database-specific features, or a hand-tuned query the optimizer needs. The builder covers most work, so raw SQL should be the exception with a reason.

Keep it safe by binding every user value with query bindings rather than concatenating: $db->query('... WHERE id = ?', [$id]). Never interpolate input into the string. Binding gives you raw SQL's control with the builder's injection protection.

Measure first, always. Turn on the debug toolbar to see the query count, query time, and memory used per request, and log the slow requests so you have real data. Intuition about where the bottleneck lives is usually wrong, so profile a realistic path with production-like data before you change a single line.

Then fix in order of impact: kill N+1 queries with joins or batched loads, add indexes for the columns you filter and join on, cache expensive computed reads with a sensible TTL, and only then reach for infrastructure. The escalation ladder ends at 'scale out', not begins there.

There's no in-place upgrade; version 4 is a rewrite, so it's a migration, not a bump. Stand up a fresh CodeIgniter 4 app and port piece by piece: rewrite controllers into namespaced classes, move models onto the new Model base, translate $this->load calls to services and helpers, and convert config arrays to config classes.

The honest plan is incremental: run the two apps side by side, move routes across a feature at a time, and reuse the database as-is since schema doesn't change. A big-bang rewrite of a large app is where these migrations stall.

Observe before you touch anything: check writable/logs and your application logs, confirm the environment really is production so you aren't leaking stack traces, and correlate the failure with recent deploys or config changes. Then reproduce the failing request path and watch the query count and the timings on the debug toolbar.

Then form a hypothesis and verify it: the usual suspects are N+1 queries, a missing index, a wrong .env value after deploy, file-based sessions behind a balancer, or an uncaught exception hidden by a generic error page. Fix at the right layer and confirm with a measurement, not a hope.

The official path is CodeIgniter Shield, the framework's own authentication and authorization library. It handles login, registration, password hashing, both session and token-based auth, and role or permission checks, so you don't hand-roll the security-sensitive parts that are easy to get subtly wrong on your own.

You install it via Composer, run its migrations, and wire its filters into your routes. Rolling your own auth is possible with the session library and password_hash(), but for anything real the guidance is to use Shield rather than reinvent login and forgot-password flows that are easy to get subtly wrong.