DEV Community: sunakshi Thakur

Integrating Claude/OpenAI API into a Laravel App: A Practical Guide

sunakshi Thakur — Thu, 02 Jul 2026 06:07:56 +0000

After 12+ years of building PHP applications, I recently added AI-powered features to a production Laravel dashboard — automatic report summaries generated from raw analytics data. What surprised me wasn't how hard it was. It was how little good PHP-focused content exists on this topic. Almost every LLM tutorial assumes you're writing Python.

So here's the guide I wish I had: integrating the Claude API and OpenAI API into a Laravel app, with a clean architecture you can actually ship to production.

What we'll build: a ReportSummaryService that takes raw data and returns a human-readable summary — with a driver pattern so you can switch between Claude and OpenAI with one config change.

Step 1: Get Your API Keys

Claude: Sign up at the Claude Console, generate a key under Account Settings.
OpenAI: Get a key from the OpenAI Platform.

Add them to your .env:

AI_PROVIDER=claude

ANTHROPIC_API_KEY=sk-ant-xxxxx
ANTHROPIC_MODEL=claude-sonnet-4-6

OPENAI_API_KEY=sk-xxxxx
OPENAI_MODEL=gpt-5-mini

⚠️ Never hardcode API keys. Never commit them. If you've ever pushed a key to Git, rotate it immediately. (You know this. I'm saying it anyway.)

Now register them in config/services.php — this is the Laravel way, so you can use config() everywhere and benefit from config caching:

'anthropic' => [
    'key' => env('ANTHROPIC_API_KEY'),
    'model' => env('ANTHROPIC_MODEL', 'claude-sonnet-4-6'),
],

'openai' => [
    'key' => env('OPENAI_API_KEY'),
    'model' => env('OPENAI_MODEL', 'gpt-5-mini'),
],

'ai' => [
    'provider' => env('AI_PROVIDER', 'claude'),
],

Step 2: Understand the Two APIs (They're 95% Similar)

Both are simple REST APIs. You POST JSON, you get JSON back.

Claude (Messages API):

POST https://api.anthropic.com/v1/messages
Headers:
  x-api-key: YOUR_KEY
  anthropic-version: 2023-06-01
  content-type: application/json

OpenAI (Chat Completions API):

POST https://api.openai.com/v1/chat/completions
Headers:
  Authorization: Bearer YOUR_KEY
  content-type: application/json

The key differences that trip people up:

	Claude	OpenAI
Auth header	`x-api-key`	`Authorization: Bearer`
Extra header	`anthropic-version` required	—
`max_tokens`	Required	Optional
System prompt	Top-level `system` field	A message with `role: system`
Response text	`content[0].text`	`choices[0].message.content`

That's it. Once you know these five differences, you know both APIs.

Step 3: Build the Contract + Drivers

Instead of scattering Http::post() calls across controllers (we've all seen that codebase), let's define a contract:

<?php
// app/Services/AI/AiClientInterface.php

namespace App\Services\AI;

interface AiClientInterface
{
    public function complete(string $systemPrompt, string $userMessage, int $maxTokens = 1024): string;
}

The Claude driver

Laravel's HTTP client makes this beautifully clean — no cURL boilerplate:

<?php
// app/Services/AI/ClaudeClient.php

namespace App\Services\AI;

use Illuminate\Support\Facades\Http;
use RuntimeException;

class ClaudeClient implements AiClientInterface
{
    public function complete(string $systemPrompt, string $userMessage, int $maxTokens = 1024): string
    {
        $response = Http::withHeaders([
                'x-api-key' => config('services.anthropic.key'),
                'anthropic-version' => '2023-06-01',
            ])
            ->timeout(60)
            ->retry(2, 500, function ($exception) {
                // Only retry on rate limits (429) or server errors (5xx)
                return $exception->response?->status() >= 429;
            })
            ->post('https://api.anthropic.com/v1/messages', [
                'model' => config('services.anthropic.model'),
                'max_tokens' => $maxTokens, // required by Claude
                'system' => $systemPrompt,
                'messages' => [
                    ['role' => 'user', 'content' => $userMessage],
                ],
            ]);

        if ($response->failed()) {
            throw new RuntimeException(
                'Claude API error: ' . $response->json('error.message', 'Unknown error')
            );
        }

        return $response->json('content.0.text', '');
    }
}

The OpenAI driver

<?php
// app/Services/AI/OpenAiClient.php

namespace App\Services\AI;

use Illuminate\Support\Facades\Http;
use RuntimeException;

class OpenAiClient implements AiClientInterface
{
    public function complete(string $systemPrompt, string $userMessage, int $maxTokens = 1024): string
    {
        $response = Http::withToken(config('services.openai.key'))
            ->timeout(60)
            ->retry(2, 500, function ($exception) {
                return $exception->response?->status() >= 429;
            })
            ->post('https://api.openai.com/v1/chat/completions', [
                'model' => config('services.openai.model'),
                'max_completion_tokens' => $maxTokens,
                'messages' => [
                    ['role' => 'system', 'content' => $systemPrompt],
                    ['role' => 'user', 'content' => $userMessage],
                ],
            ]);

        if ($response->failed()) {
            throw new RuntimeException(
                'OpenAI API error: ' . $response->json('error.message', 'Unknown error')
            );
        }

        return $response->json('choices.0.message.content', '');
    }
}

Notice how much heavy lifting Laravel does here: timeout(), retry() with a conditional callback, withToken(), and dot-notation access into the JSON response. This is why I love this framework.

Step 4: Bind the Driver in a Service Provider

Now the magic — one config value decides which provider your entire app uses:

<?php
// app/Providers/AppServiceProvider.php

use App\Services\AI\AiClientInterface;
use App\Services\AI\ClaudeClient;
use App\Services\AI\OpenAiClient;

public function register(): void
{
    $this->app->bind(AiClientInterface::class, function () {
        return match (config('services.ai.provider')) {
            'openai' => new OpenAiClient(),
            default  => new ClaudeClient(),
        };
    });
}

Switch providers by changing one line in .env. No code changes. If one provider has an outage or a price change, you flip a switch. This alone is worth the abstraction.

Step 5: Build a Real Feature

Here's a realistic use case from my own work: summarizing daily analytics data into a readable report for management.

<?php
// app/Services/ReportSummaryService.php

namespace App\Services;

use App\Services\AI\AiClientInterface;

class ReportSummaryService
{
    public function __construct(
        private AiClientInterface $ai
    ) {}

    public function summarize(array $reportData): string
    {
        $systemPrompt = <<<PROMPT
        You are a business analyst. Summarize the analytics data you receive
        into 3-4 concise sentences for a non-technical manager.
        Highlight the most important trend first. Do not use bullet points.
        PROMPT;

        return $this->ai->complete(
            systemPrompt: $systemPrompt,
            userMessage: 'Summarize this data: ' . json_encode($reportData),
            maxTokens: 500
        );
    }
}

And the controller — thin, as it should be:

<?php
// app/Http/Controllers/ReportController.php

namespace App\Http\Controllers;

use App\Services\ReportSummaryService;
use Illuminate\Http\JsonResponse;

class ReportController extends Controller
{
    public function summary(ReportSummaryService $summaryService): JsonResponse
    {
        $data = [
            'total_visitors' => 12480,
            'conversion_rate' => '3.2%',
            'top_store' => 'Hyderabad Main Branch',
            'change_vs_last_week' => '+14%',
        ];

        return response()->json([
            'summary' => $summaryService->summarize($data),
        ]);
    }
}

Laravel's container injects everything. Your controller doesn't know or care whether Claude or OpenAI wrote the summary.

Step 6: Production Hardening (The Part Tutorials Skip)

Cache aggressively

LLM calls are slow (1–10 seconds) and cost money. If the input hasn't changed, don't call the API again:

use Illuminate\Support\Facades\Cache;

public function summarize(array $reportData): string
{
    $cacheKey = 'report-summary:' . md5(json_encode($reportData));

    return Cache::remember($cacheKey, now()->addHours(6), function () use ($reportData) {
        return $this->ai->complete(/* ... */);
    });
}

In my case this cut API costs by roughly 70% — most users request the same report multiple times a day.

Move long tasks to queues

Never make a user's HTTP request wait 10 seconds for an LLM. Dispatch a queued job, store the result, notify when ready:

GenerateReportSummary::dispatch($reportId);

If you're already running Laravel queues (Redis/database driver), this is a 15-minute change.

Handle failures gracefully

LLM APIs will fail sometimes — rate limits, overloaded servers, timeouts. The retry() calls in our drivers handle transient errors, but always wrap the feature so your app degrades gracefully:

try {
    $summary = $summaryService->summarize($data);
} catch (RuntimeException $e) {
    Log::warning('AI summary failed', ['error' => $e->getMessage()]);
    $summary = null; // UI shows the raw data table instead
}

The AI feature should be an enhancement, not a single point of failure.

Control your costs

Set max_tokens deliberately. It caps your output cost per request.
Use smaller models for simple tasks. Summaries, classification, and extraction rarely need the flagship models — Claude Haiku or a mini-tier OpenAI model is often 10x cheaper and plenty good.
Set spend limits in both provider dashboards before you ship. Trust me on this one.
Log token usage. Both APIs return a usage object in the response — store it, so you know exactly what each feature costs.

What About the Official SDKs?

Everything above uses Laravel's HTTP client so you can see exactly what's happening on the wire. For bigger projects, consider:

Anthropic's official PHP SDK: composer require anthropic-ai/sdk guzzlehttp/guzzle (requires PHP 8.1+) — handles streaming, pagination, and retries for you
openai-php/laravel: a popular community package with a Laravel-native facade

I'd still recommend writing the raw version once, like we did here. Understanding the actual API makes debugging SDK issues far easier later.

Wrapping Up

The full picture:

Keys in .env, referenced via config/services.php
An AiClientInterface contract with a driver per provider
Container binding so one env variable switches providers
Thin controllers, logic in services
Cache + queues + graceful failure for production

None of this is exotic — it's the same clean Laravel architecture you already use, applied to a new kind of API. That's the real takeaway: you don't need to learn Python to build AI features. Your PHP skills transfer directly.

In an upcoming post, I'll cover streaming responses to the browser (so summaries appear word-by-word, ChatGPT-style) using Laravel and Server-Sent Events. Follow me if you'd like to catch that one.

Have you added AI features to a PHP app? What did you use — raw HTTP, an SDK, or something else? I'd love to hear about it in the comments. 👇

CodeIgniter 4 vs Laravel — When to Choose Which (From a Dev Who Uses Both)

sunakshi Thakur — Wed, 01 Jul 2026 08:46:16 +0000

12+ years in PHP. I still ship production code in both Laravel and CodeIgniter 4 today — Laravel runs a surveillance analytics dashboard I maintain, CodeIgniter sits under a CRM I've customized for years.

This isn't a "which is better" post. It's "which one for what," with actual code so you can see the difference instead of just reading opinions about it.

The Core Difference in Code

Same task — fetch active users with their related orders — in both frameworks.

Laravel (Eloquent):

$users = User::where('status', 'active')
    ->with('orders')
    ->get();

CodeIgniter 4 (Query Builder):

$users = $this->userModel
    ->where('status', 'active')
    ->findAll();

foreach ($users as $user) {
    $user->orders = $this->orderModel
        ->where('user_id', $user->id)
        ->findAll();
}

Laravel abstracts the relationship. CodeIgniter makes you handle it explicitly. Neither is "wrong" — one hides complexity, the other keeps you close to the SQL.

When I Reach for Laravel

Complex, evolving business logic. Queues, events, scheduled jobs, multiple integrations talking to each other. Example — dispatching a queued job for a report export:

ProcessReportExport::dispatch($report)->onQueue('exports');

Built-in queue infrastructure. No wiring this up yourself.

Teams over solo work. Convention over configuration means a new dev can predict where things live — Form Requests, Policies, Resource Controllers. Onboarding time drops noticeably on multi-dev projects.

Nested relational data. Eager loading avoids N+1 problems with almost no extra code:

Store::with(['cameras', 'alerts.rules'])->get();

Try that by hand in raw queries and you'll write triple the code.

Long-term products. First-party packages (Sanctum for auth, Horizon for queue monitoring) mean less custom tooling as the product grows.

When I Reach for CodeIgniter 4

Budget/shared hosting constraints. Lighter footprint, lower server requirements. Real factor when a client isn't paying for premium infrastructure.

Extending an existing CodeIgniter system. If you're customizing something already built on CodeIgniter (Perfex CRM is a common one), you work within that architecture. Bolting Laravel onto a CodeIgniter codebase to add one module is a bad trade.

Full visibility into execution. No facades, no magic methods hiding what's actually running. When you're debugging a production issue at 11pm, seeing the literal query helps:

$builder = $db->table('orders');
$builder->where('status', 'pending');
$query = $builder->get();
echo $db->getLastQuery(); // see exactly what ran

Simple, bounded scope. A ticketing module, a lead-tracking add-on — CodeIgniter ships this fast without the overhead of a fuller framework you won't use most of.

Decision Checklist

Is this extending an existing stack?        → match it, don't fight it
Will complexity grow over 2+ years?          → Laravel
Tight hosting budget / minimal DevOps?       → CodeIgniter
Multiple devs, long-term maintenance?        → Laravel
Small, well-defined, single-purpose module?  → CodeIgniter

Takeaway

Both are production-grade. Both scale further than most projects need. The developers who struggle aren't using "the wrong framework" — they don't understand PHP deeply enough to make either one work well.

Learn both. Let the project decide.

What's your framework decision tree look like? Curious if others weigh hosting constraints as heavily as I do.

Bootstrap Selectpicker with CodeIgniter — Dynamic Rows & Refresh

sunakshi Thakur — Tue, 30 Jun 2026 08:24:31 +0000

Fix the most common Bootstrap Selectpicker issues in CodeIgniter — dropdowns not initializing on dynamic rows, DataTables conflicts, AJAX-loaded data, and the refresh pattern that actually works.

Difficulty: Beginner–Intermediate | Read time: 9 min | Framework: CodeIgniter 4

The Problem Everyone Hits

Bootstrap Selectpicker (the bootstrap-select plugin) looks great — searchable dropdowns, multi-select, clean UI. Then you add it to a table that loads rows dynamically (via AJAX, DataTables, or a PHP loop after page load) and... nothing. The dropdown shows as a plain unstyled <select>.

This happens because Selectpicker only styles elements that exist when the page first loads. Anything added after that needs to be manually told to initialize.

I've hit this in almost every CRM and dashboard project — staff assignment dropdowns, status filters, multi-select tags. Here's every scenario and the fix for each.

What we'll cover: Basic setup, the core refresh problem, fixing it for AJAX-loaded rows, DataTables integration, multi-select with search, and a reusable helper function for any project.

Basic Setup

<!-- CDN includes -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap-select@1.13.18/dist/css/bootstrap-select.min.css">
<script src="https://cdn.jsdelivr.net/npm/bootstrap-select@1.13.18/dist/js/bootstrap-select.min.js"></script>

<!-- Basic select -->
<select class="selectpicker" data-live-search="true" title="Choose staff...">
    <?php foreach ($staff as $s): ?>
        <option value="<?= $s['staffid'] ?>"><?= esc($s['name']) ?></option>
    <?php endforeach; ?>
</select>

<script>
$(document).ready(function() {
    $('.selectpicker').selectpicker();
});
</script>

This works fine for static content. The trouble starts the moment rows are added dynamically.

The Core Problem — Why Refresh Is Needed

Selectpicker converts your <select> into a styled <div> structure once, at initialization. If you then:

Add new <select> elements via AJAX
Change <option> values inside an existing select with JS
Reload a table with DataTables

...the new/changed elements are invisible to Selectpicker until you explicitly tell it to refresh.

// The fix — re-initialize after any DOM change
$('.selectpicker').selectpicker('refresh');

This is the single most important line in this entire tutorial. Memorize it.

Scenario 1 — Rows Added via AJAX

Real example: assigning staff to tickets in a table, where rows are loaded by AJAX.

<!-- app/Views/tickets/index.php -->
<table id="ticketsTable" class="table">
  <thead>
    <tr>
      <th>Subject</th>
      <th>Assign To</th>
    </tr>
  </thead>
  <tbody id="ticketsBody">
    <!-- Rows injected here via AJAX -->
  </tbody>
</table>

function loadTickets() {
    $.get('<?= base_url('tickets/list') ?>', function(html) {
        $('#ticketsBody').html(html);

        // CRITICAL: refresh selectpicker after injecting new HTML
        $('.selectpicker').selectpicker('refresh');
    });
}

loadTickets();

<!-- app/Views/tickets/_rows.php (returned by AJAX) -->
<?php foreach ($tickets as $ticket): ?>
<tr>
    <td><?= esc($ticket['subject']) ?></td>
    <td>
        <select class="selectpicker assign-staff"
                data-ticket="<?= $ticket['id'] ?>"
                data-live-search="true"
                title="Assign...">
            <?php foreach ($staff as $s): ?>
                <option value="<?= $s['staffid'] ?>"><?= esc($s['name']) ?></option>
            <?php endforeach; ?>
        </select>
    </td>
</tr>
<?php endforeach; ?>

Key point: if Selectpicker hasn't been initialized on these elements at all yet (first load), call .selectpicker() not .selectpicker('refresh'). Refresh only works on already-initialized elements.

// Safer pattern — handles both first-time init AND refresh
function initSelectpickers() {
    $('.selectpicker').each(function() {
        if ($(this).data('selectpicker')) {
            $(this).selectpicker('refresh');
        } else {
            $(this).selectpicker();
        }
    });
}

Scenario 2 — DataTables Integration

This is where it gets tricky. DataTables redraws rows on pagination, search, and sort — Selectpicker needs to reinitialize on every redraw.

var table = $('#ticketsTable').DataTable({
    ajax: '<?= base_url('tickets/datatable') ?>',
    columns: [
        { data: 'subject' },
        { data: 'assign_dropdown' }  // server returns HTML for the select
    ],
    drawCallback: function() {
        // Runs after every redraw — pagination, search, sort
        $('.selectpicker').selectpicker('refresh');
    }
});

If you're building the dropdown HTML server-side (common in CI4 with columns.render), make sure each row has a unique identifier:

columns: [
    { data: 'subject' },
    {
        data: null,
        render: function(data, type, row) {
            return '<select class="selectpicker assign-staff" data-ticket="' + row.id + '">' +
                   '<option value="">Unassigned</option>' +
                   staffOptionsHtml +  // pre-built options string
                   '</select>';
        }
    }
],
drawCallback: function() {
    $('.selectpicker').selectpicker('refresh');
}

Scenario 3 — Changing Options Dynamically (Cascading Dropdowns)

Common pattern: selecting a State filters the City dropdown. This needs refresh too — not just on the changed select, but sometimes you need a full re-render with selectpicker('destroy') first if option count changes drastically.

$('#state').on('change', function() {
    var stateId = $(this).val();

    $.get('<?= base_url('ajax/cities') ?>/' + stateId, function(cities) {
        var $citySelect = $('#city');

        // Clear and rebuild options
        $citySelect.empty();
        $citySelect.append('<option value="">Select City</option>');

        $.each(cities, function(i, city) {
            $citySelect.append(
                $('<option>', { value: city.id, text: city.name })
            );
        });

        // Refresh AFTER options are rebuilt
        $citySelect.selectpicker('refresh');
    });
});

If refresh alone doesn't reflect the changes properly (rare, but happens with some Selectpicker versions), use the nuclear option:

$citySelect.selectpicker('destroy').selectpicker();

Scenario 4 — Multi-Select With Search (Common in Filters)

Used heavily for store/region filters in dashboards:

<select class="selectpicker" multiple
        data-live-search="true"
        data-selected-text-format="count > 3"
        title="Select Stores...">
    <?php foreach ($stores as $store): ?>
        <option value="<?= $store['id'] ?>"><?= esc($store['name']) ?></option>
    <?php endforeach; ?>
</select>

$('.selectpicker').selectpicker({
    liveSearch: true,
    selectedTextFormat: 'count > 3',  // shows "5 selected" instead of listing all
    actionsBox: true                  // adds "Select All / Deselect All" buttons
});

To pre-select values when editing a record (e.g. edit form):

// Set multiple selected values dynamically and refresh
var assignedStoreIds = [12, 45, 78]; // from PHP/JSON
$('.selectpicker').val(assignedStoreIds).selectpicker('refresh');

Reusable Helper — Drop This in Every Project

This pattern handles 90% of real-world cases safely:

/**
 * Universal Selectpicker initializer/refresher.
 * Safe to call after ANY DOM change.
 */
function refreshSelectpickers(selector) {
    selector = selector || '.selectpicker';

    $(selector).each(function() {
        var $el = $(this);
        if ($el.data('selectpicker')) {
            $el.selectpicker('refresh');
        } else {
            $el.selectpicker();
        }
    });
}

// Call this after:
// - AJAX content load
// - DataTables drawCallback
// - Modal opening (Bootstrap modal 'shown.bs.modal' event)
// - Tab switching ('shown.bs.tab' event)

$(document).on('shown.bs.modal', '.modal', function() {
    refreshSelectpickers();
});

$(document).on('shown.bs.tab', 'a[data-bs-toggle="tab"]', function() {
    refreshSelectpickers();
});

Common Pitfalls

⚠️ 1. Calling `.selectpicker()` again on already-initialized elements

This causes duplicate dropdowns to stack visually. Always use refresh, not re-init, unless it's truly the first time.

⚠️ 2. Selectpicker inside a hidden element (modal, tab)

If the <select> is inside a display: none container when initialized, Selectpicker calculates wrong widths. Always refresh after the container becomes visible:

$('#myModal').on('shown.bs.modal', function() {
    $(this).find('.selectpicker').selectpicker('refresh');
});

⚠️ 3. Selectpicker breaking inside Bootstrap tabs

Same root cause as modals — hidden tab content has zero width when Selectpicker initializes. Use the shown.bs.tab event shown above.

⚠️ 4. Values not syncing with the actual `<select>` element

If you're using a JS framework alongside jQuery, remember Selectpicker creates a visual clone — the underlying <select> element still holds the real value. Always read/write via jQuery ($('.selectpicker').val()), not by manipulating the DOM directly.

Conclusion

Bootstrap Selectpicker is a great UI upgrade, but it has one rule you must never forget: anything that changes the DOM needs a refresh call afterward. Build the habit of calling refreshSelectpickers() after every AJAX load, modal open, or tab switch, and you'll never see a plain unstyled dropdown again.

Follow me for more CodeIgniter production tutorials — 3 new articles every week. 🙌

Senior PHP Developer · 12+ years building production systems on CodeIgniter, Laravel & WordPress

CodeIgniter 4 CSRF Protection in AJAX Forms — The Complete Fix

sunakshi Thakur — Mon, 29 Jun 2026 05:09:54 +0000

Difficulty: Intermediate | Read time: 12 min | Framework: CodeIgniter 4

Why CSRF Breaks Your AJAX Forms

You build a perfectly working AJAX form. It works fine in testing. Then suddenly — "Page Expired" or a 419 error. You refresh, it works once, then breaks again.

This is CodeIgniter 4's CSRF protection doing its job — but if you don't handle it correctly in AJAX, it will drive you crazy.

In this tutorial I'll show you exactly why it happens and give you production-ready patterns to fix it permanently — for single forms, multiple forms, and even global AJAX setups.

What we'll cover: How CI4 CSRF works, why AJAX breaks it, token refresh after every request, global jQuery fix, Fetch API fix, and real-world examples from CRM and ticket system projects.

How CI4 CSRF Works (Quick Recap)

Every form submission needs a valid CSRF token. CI4 generates a token, stores it in a cookie, and expects it back in every POST request.

// app/Config/Security.php — default settings
public string $tokenName  = 'csrf_test_name';  // field name
public string $headerName = 'X-CSRF-TOKEN';    // header name for AJAX
public bool   $regenerate = true;              // ← THIS causes most AJAX issues
public bool   $redirect   = true;             // redirects on failure (not great for AJAX)

The problem: when $regenerate = true, the token changes after every single request. So if your AJAX doesn't update the token after each call, the second request will fail.

The 3 Most Common CSRF AJAX Mistakes

❌ Mistake 1 — Not sending the token at all

// WRONG — no CSRF token
$.post('/tickets/assign', {
    ticket_id: 1,
    staff_id: 5
}, function(res) { ... });

❌ Mistake 2 — Sending it once, never updating

// WRONG — token sent but never refreshed after response
$.post('/tickets/assign', {
    ticket_id: 1,
    staff_id: 5,
    csrf_test_name: '<?= csrf_hash() ?>'  // gets stale after first request
}, function(res) { ... });

❌ Mistake 3 — Wrong config for AJAX (redirect on failure)

// WRONG for AJAX — CI4 redirects instead of returning JSON error
public bool $redirect = true;

The Complete Fix — Step by Step

Step 1 — Update Security Config for AJAX

// app/Config/Security.php
public string $csrfProtection = 'cookie';  // or 'session'
public string $tokenName      = 'csrf_test_name';
public string $headerName     = 'X-CSRF-TOKEN';
public bool   $regenerate     = true;   // keep true for security
public bool   $redirect       = false;  // IMPORTANT: false for AJAX apps
public bool   $samesite       = 'Lax';

Setting $redirect = false means CI4 will return a proper response instead of redirecting — so your AJAX error handlers can catch it.

Step 2 — Return New Token in Every AJAX Response

In every controller method that handles AJAX, return the new token:

<?php
// app/Controllers/Tickets.php

public function assign(): \CodeIgniter\HTTP\ResponseInterface
{
    if (!$this->request->isAJAX()) {
        return $this->response->setStatusCode(403);
    }

    $ticketId = (int) $this->request->getPost('ticket_id');
    $staffId  = (int) $this->request->getPost('staff_id');

    $assigned = $this->ticketModel->assignTicket($ticketId, $staffId);

    // Always return new CSRF token in response
    return $this->response->setJSON([
        'success'    => $assigned,
        'message'    => $assigned ? 'Ticket assigned!' : 'Assignment failed.',
        'csrf_token' => csrf_hash(),  // ← send new token back
        'csrf_name'  => csrf_token(), // ← send token name too
    ]);
}

Step 3A — jQuery Global AJAX Fix (Recommended)

Set this up once in your main layout — it handles CSRF for ALL jQuery AJAX requests automatically:

// Put this in your main layout or app.js — runs once, fixes everything

var csrfName  = '<?= csrf_token() ?>';
var csrfToken = '<?= csrf_hash() ?>';

// Add CSRF to every jQuery AJAX request automatically
$.ajaxSetup({
    beforeSend: function(xhr, settings) {
        if (settings.type === 'POST' || settings.type === 'PUT' || settings.type === 'DELETE') {
            // Add as header (works with CI4 headerName config)
            xhr.setRequestHeader('X-CSRF-TOKEN', csrfToken);

            // Also add to data if it's a form POST
            if (typeof settings.data === 'string') {
                settings.data += '&' + csrfName + '=' + csrfToken;
            } else if (typeof settings.data === 'object' && settings.data !== null) {
                settings.data[csrfName] = csrfToken;
            }
        }
    }
});

// After every AJAX response, update the token
$(document).ajaxComplete(function(event, xhr, settings) {
    try {
        var response = JSON.parse(xhr.responseText);
        if (response.csrf_token) {
            csrfToken = response.csrf_token;
            csrfName  = response.csrf_name || csrfName;
        }
    } catch(e) {
        // Not a JSON response — that's fine
    }
});

With this setup, you never need to manually add the token to individual AJAX calls again.

Step 3B — Individual AJAX Call Fix

If you prefer per-call control:

// Single AJAX call with CSRF — with token refresh
function assignTicket(ticketId, staffId) {
    var data = {
        ticket_id: ticketId,
        staff_id:  staffId
    };

    // Add CSRF token
    data[csrfName] = csrfToken;

    $.post('<?= base_url('tickets/assign') ?>', data, function(res) {
        if (res.csrf_token) {
            // Update token for next request
            csrfToken = res.csrf_token;
            csrfName  = res.csrf_name || csrfName;
        }

        if (res.success) {
            toastr.success(res.message);
        } else {
            toastr.error(res.message);
        }
    }).fail(function(xhr) {
        if (xhr.status === 403) {
            toastr.error('Session expired. Please refresh the page.');
        }
    });
}

Step 3C — Fetch API Fix (No jQuery)

If you're using vanilla JS or React:

// CSRF with Fetch API
let csrfToken = document.querySelector('meta[name="csrf-token"]').getAttribute('content');
let csrfName  = document.querySelector('meta[name="csrf-name"]').getAttribute('content');

async function postData(url, payload) {
    const body = new FormData();
    body.append(csrfName, csrfToken);

    Object.entries(payload).forEach(([key, value]) => {
        body.append(key, value);
    });

    const response = await fetch(url, {
        method: 'POST',
        headers: {
            'X-CSRF-TOKEN': csrfToken,
            'X-Requested-With': 'XMLHttpRequest'
        },
        body: body
    });

    const data = await response.json();

    // Update token from response
    if (data.csrf_token) {
        csrfToken = data.csrf_token;
    }

    return data;
}

// Usage
const result = await postData('/tickets/assign', { ticket_id: 1, staff_id: 5 });

Add these meta tags in your layout <head>:

<!-- app/Views/layouts/main.php -->
<meta name="csrf-token" content="<?= csrf_hash() ?>">
<meta name="csrf-name"  content="<?= csrf_token() ?>">

Real-World Example — Lead Send Email Form

Here's a complete real-world example — a modal form that sends emails to leads with CSRF handled properly:

<!-- View: leads/send_email_modal.php -->
<div class="modal fade" id="sendEmailModal">
  <div class="modal-dialog modal-lg">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Send Email to Lead</h5>
        <button type="button" class="btn-close" data-bs-dismiss="modal"></button>
      </div>
      <div class="modal-body">
        <div class="mb-3">
          <label class="form-label">To</label>
          <input type="email" id="lead_email" class="form-control" />
        </div>
        <div class="mb-3">
          <label class="form-label">CC</label>
          <input type="text" id="lead_cc" class="form-control" placeholder="Comma separated emails" />
        </div>
        <div class="mb-3">
          <label class="form-label">Subject</label>
          <input type="text" id="email_subject" class="form-control" />
        </div>
        <div class="mb-3">
          <label class="form-label">Message</label>
          <textarea id="email_body" class="form-control" rows="5"></textarea>
        </div>
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-secondary" data-bs-dismiss="modal">Cancel</button>
        <button type="button" class="btn btn-primary" id="sendEmailBtn">
          <span class="spinner-border spinner-border-sm d-none" id="sendSpinner"></span>
          Send Email
        </button>
      </div>
    </div>
  </div>
</div>

<script>
$('#sendEmailBtn').on('click', function() {
    var $btn = $(this);
    var $spinner = $('#sendSpinner');

    // Basic validation
    if (!$('#lead_email').val()) {
        toastr.error('Please enter recipient email.');
        return;
    }

    // Show loading state
    $btn.prop('disabled', true);
    $spinner.removeClass('d-none');

    var data = {
        to:      $('#lead_email').val(),
        cc:      $('#lead_cc').val(),
        subject: $('#email_subject').val(),
        body:    $('#email_body').val()
    };

    // CSRF added automatically by $.ajaxSetup (from global fix above)
    $.post('<?= base_url('leads/send_email') ?>', data, function(res) {

        // Update CSRF token
        if (res.csrf_token) {
            csrfToken = res.csrf_token;
        }

        if (res.success) {
            toastr.success('Email sent successfully!');
            $('#sendEmailModal').modal('hide');
        } else {
            toastr.error(res.message || 'Failed to send email.');
        }

    }).fail(function(xhr) {
        if (xhr.status === 403) {
            toastr.error('CSRF token expired. Please refresh the page.');
        } else {
            toastr.error('Something went wrong. Try again.');
        }
    }).always(function() {
        $btn.prop('disabled', false);
        $spinner.addClass('d-none');
    });
});
</script>

What If You Want to Disable CSRF for Specific Routes?

Sometimes you need to exclude API endpoints from CSRF (like webhooks). Do it in the filter config:

// app/Config/Filters.php
public array $globals = [
    'before' => [
        'csrf' => ['except' => [
            'api/*',           // exclude all /api/ routes
            'webhooks/stripe', // exclude specific webhook
        ]],
    ],
];

Common Pitfalls

⚠️ 1. Using the same token for multiple rapid requests

If you fire multiple AJAX calls in quick succession and $regenerate = true, only the first one will succeed. Solution: either set $regenerate = false (less secure) OR queue your requests so they run one at a time.

⚠️ 2. Token in URL (GET request CSRF)

Never put CSRF tokens in GET request URLs. CSRF protection is only needed for state-changing requests — POST, PUT, DELETE.

⚠️ 3. SameSite cookie issues on some browsers

If your app is embedded in an iframe or served cross-origin, set:

public string $samesite = 'None'; // requires HTTPS

⚠️ 4. AJAX response is HTML instead of JSON

If CI4 redirects instead of returning JSON, it means $redirect = true in Security.php. Change it to false for AJAX apps.

What to Build Next

CodeIgniter 4 REST API — build and secure endpoints with token auth
CodeIgniter 4 File Upload to AWS S3 — AJAX file upload with progress bar
CodeIgniter 4 + jQuery AJAX CRUD — full CRUD without page reload

Conclusion

CSRF protection in CodeIgniter 4 is solid — but it requires a small amount of setup to work properly with AJAX. The global $.ajaxSetup + ajaxComplete pattern is the cleanest solution — set it up once and never worry about it again.

Follow me for more CodeIgniter production tutorials — 3 new articles every week. 🙌

Senior PHP Developer · 12+ years building production systems on CodeIgniter, Laravel & WordPress

Role-Based Access Control in CodeIgniter 4 — A Practical Guide

sunakshi Thakur — Sat, 27 Jun 2026 10:53:16 +0000

Difficulty: Intermediate | Read time: 14 min | Framework: CodeIgniter 4

Why RBAC Matters in Real Projects

Every project I've built beyond a simple blog has needed access control. Not just "is the user logged in?" — but "can this user do this specific thing?"

Without a proper RBAC system you end up with scattered if ($user->is_admin) checks everywhere, and one missed check means a security hole.

In this tutorial I'll show you how I built a clean, reusable RBAC system for an internal CRM — covering roles, permissions, middleware, and view-level gating.

What we're building: A role and permission system where each user has a role (Admin, Manager, Staff), each role has specific permissions, and access is enforced at the route, controller, and view level.

Database Structure

Three tables — users, roles, and permissions.

CREATE TABLE `tblroles` (
  `id`          INT AUTO_INCREMENT PRIMARY KEY,
  `name`        VARCHAR(100) NOT NULL UNIQUE,
  `description` VARCHAR(255),
  `created_at`  DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE `tblpermissions` (
  `id`          INT AUTO_INCREMENT PRIMARY KEY,
  `name`        VARCHAR(100) NOT NULL UNIQUE,
  `module`      VARCHAR(100),
  `description` VARCHAR(255)
);

CREATE TABLE `tblrole_permissions` (
  `role_id`       INT NOT NULL,
  `permission_id` INT NOT NULL,
  PRIMARY KEY (`role_id`, `permission_id`),
  FOREIGN KEY (`role_id`)       REFERENCES `tblroles`(`id`) ON DELETE CASCADE,
  FOREIGN KEY (`permission_id`) REFERENCES `tblpermissions`(`id`) ON DELETE CASCADE
);

-- Add role_id to your staff/users table
ALTER TABLE `tblstaff` ADD COLUMN `role_id` INT NULL REFERENCES `tblroles`(`id`);

Seed Some Default Data

-- Roles
INSERT INTO `tblroles` (`name`, `description`) VALUES
('Admin',   'Full access to everything'),
('Manager', 'Can manage staff and view reports'),
('Staff',   'Limited access to assigned tasks only');

-- Permissions
INSERT INTO `tblpermissions` (`name`, `module`) VALUES
('view_dashboard',   'dashboard'),
('manage_users',     'users'),
('view_reports',     'reports'),
('export_reports',   'reports'),
('manage_tickets',   'tickets'),
('view_tickets',     'tickets'),
('manage_leads',     'leads'),
('view_leads',       'leads');

-- Assign all permissions to Admin (role_id = 1)
INSERT INTO `tblrole_permissions` (`role_id`, `permission_id`)
SELECT 1, id FROM `tblpermissions`;

-- Manager gets view + manage reports + view leads
INSERT INTO `tblrole_permissions` (`role_id`, `permission_id`)
SELECT 2, id FROM `tblpermissions`
WHERE `name` IN ('view_dashboard','view_reports','export_reports','view_leads','view_tickets');

-- Staff gets minimal access
INSERT INTO `tblrole_permissions` (`role_id`, `permission_id`)
SELECT 3, id FROM `tblpermissions`
WHERE `name` IN ('view_dashboard','view_tickets','view_leads');

The Permission Helper

This is the core of the system — a single function you'll call everywhere.

<?php
// app/Helpers/permission_helper.php

/**
 * Check if the currently logged-in user has a specific permission.
 */
function has_permission(string $permission): bool
{
    $session     = session();
    $permissions = $session->get('permissions') ?? [];

    return in_array($permission, $permissions);
}

/**
 * Check if the user has ANY of the given permissions.
 */
function has_any_permission(array $permissions): bool
{
    foreach ($permissions as $permission) {
        if (has_permission($permission)) {
            return true;
        }
    }
    return false;
}

/**
 * Abort with 403 if user doesn't have permission.
 */
function require_permission(string $permission): void
{
    if (!has_permission($permission)) {
        throw \CodeIgniter\Exceptions\PageNotFoundException::forPageNotFound();
    }
}

Load it in app/Config/Autoload.php:

public $helpers = ['url', 'form', 'permission'];

Load Permissions Into Session at Login

After the user logs in, load their permissions into the session so every check is fast (no DB query per request).

<?php
// app/Controllers/Auth.php (your login controller)

private function loadUserPermissions(int $staffId): void
{
    $db = \Config\Database::connect();

    $permissions = $db->table('tblrole_permissions rp')
        ->select('p.name')
        ->join('tblpermissions p', 'p.id = rp.permission_id')
        ->join('tblstaff s',       's.role_id = rp.role_id')
        ->where('s.staffid', $staffId)
        ->get()
        ->getResultArray();

    $permissionNames = array_column($permissions, 'name');

    session()->set([
        'staff_id'    => $staffId,
        'permissions' => $permissionNames,
        'role'        => $this->getUserRole($staffId),
    ]);
}

private function getUserRole(int $staffId): string
{
    $db = \Config\Database::connect();

    $row = $db->table('tblstaff s')
        ->select('r.name')
        ->join('tblroles r', 'r.id = s.role_id')
        ->where('s.staffid', $staffId)
        ->get()->getRowArray();

    return $row['name'] ?? 'Staff';
}

Call $this->loadUserPermissions($staffId) right after successful login verification.

The RBAC Middleware (Filter)

Create a filter that protects entire route groups.

<?php
// app/Filters/RBACFilter.php
namespace App\Filters;

use CodeIgniter\HTTP\RequestInterface;
use CodeIgniter\HTTP\ResponseInterface;
use CodeIgniter\Filters\FilterInterface;

class RBACFilter implements FilterInterface
{
    public function before(RequestInterface $request, $arguments = null)
    {
        // Not logged in at all
        if (!session()->get('staff_id')) {
            return redirect()->to(base_url('login'));
        }

        // No permission argument passed — just check login
        if (empty($arguments)) {
            return;
        }

        // Check each required permission
        $userPermissions = session()->get('permissions') ?? [];

        foreach ($arguments as $required) {
            if (!in_array($required, $userPermissions)) {
                // Redirect to 403 page
                return redirect()->to(base_url('errors/permission_denied'));
            }
        }
    }

    public function after(RequestInterface $request, ResponseInterface $response, $arguments = null)
    {
        // Nothing needed after
    }
}

public array $aliases = [
    'csrf'     => CSRF::class,
    'toolbar'  => DebugToolbar::class,
    'honeypot' => Honeypot::class,
    'rbac'     => \App\Filters\RBACFilter::class,  // <-- add this
];

Protect Routes With the Filter

// app/Config/Routes.php

// Anyone logged in
$routes->group('dashboard', ['filter' => 'rbac'], function ($routes) {
    $routes->get('/', 'Dashboard::index');
});

// Only users with manage_users permission
$routes->group('users', ['filter' => 'rbac:manage_users'], function ($routes) {
    $routes->get('/',        'Users::index');
    $routes->get('create',   'Users::create');
    $routes->post('store',   'Users::store');
    $routes->get('edit/(:num)',   'Users::edit/$1');
    $routes->post('update/(:num)', 'Users::update/$1');
    $routes->post('delete/(:num)', 'Users::delete/$1');
});

// Reports — needs view_reports
$routes->group('reports', ['filter' => 'rbac:view_reports'], function ($routes) {
    $routes->get('/',       'Reports::index');
    $routes->get('export',  'Reports::export', ['filter' => 'rbac:export_reports']);
});

// Tickets
$routes->group('tickets', ['filter' => 'rbac:view_tickets'], function ($routes) {
    $routes->get('/', 'Tickets::index');
    $routes->get('manage', 'Tickets::manage', ['filter' => 'rbac:manage_tickets']);
});

Controller-Level Check

For finer control inside a controller method:

<?php
// app/Controllers/Reports.php
namespace App\Controllers;

class Reports extends BaseController
{
    public function export(): \CodeIgniter\HTTP\ResponseInterface
    {
        // Extra check at controller level
        if (!has_permission('export_reports')) {
            return redirect()->to(base_url('errors/permission_denied'));
        }

        // ... export logic
    }

    public function delete(int $id): \CodeIgniter\HTTP\ResponseInterface
    {
        // Use the helper shortcut — throws 404 if no permission
        require_permission('manage_reports');

        // ... delete logic
    }
}

View-Level Gating

Hide buttons and menu items the user can't access:

<!-- Sidebar navigation — show only what the user can access -->
<ul class="sidebar-menu">

    <li>
        <a href="<?= base_url('dashboard') ?>">
            <i class="fas fa-home"></i> Dashboard
        </a>
    </li>

    <?php if (has_permission('manage_users')): ?>
    <li>
        <a href="<?= base_url('users') ?>">
            <i class="fas fa-users"></i> Users
        </a>
    </li>
    <?php endif; ?>

    <?php if (has_permission('view_reports')): ?>
    <li>
        <a href="<?= base_url('reports') ?>">
            <i class="fas fa-chart-bar"></i> Reports
        </a>
    </li>
    <?php endif; ?>

    <?php if (has_permission('view_tickets')): ?>
    <li>
        <a href="<?= base_url('tickets') ?>">
            <i class="fas fa-ticket-alt"></i> Tickets
        </a>
    </li>
    <?php endif; ?>

</ul>

<!-- Hide export button from users without permission -->
<?php if (has_permission('export_reports')): ?>
<a href="<?= base_url('reports/export') ?>" class="btn btn-success">
    <i class="fas fa-download"></i> Export CSV
</a>
<?php endif; ?>

The 403 Permission Denied Page

Create a clean error page instead of crashing:

<?php
// app/Controllers/Errors.php
namespace App\Controllers;

class Errors extends BaseController
{
    public function permissionDenied(): string
    {
        return view('errors/permission_denied');
    }
}

<!-- app/Views/errors/permission_denied.php -->
<div class="container text-center py-5">
    <div class="mb-4">
        <i class="fas fa-lock fa-4x text-danger"></i>
    </div>
    <h2 class="fw-bold">Access Denied</h2>
    <p class="text-muted">
        You don't have permission to view this page.<br>
        Contact your administrator if you think this is a mistake.
    </p>
    <a href="<?= base_url('dashboard') ?>" class="btn btn-primary mt-3">
        Go to Dashboard
    </a>
</div>

Add the route:

$routes->get('errors/permission_denied', 'Errors::permissionDenied');

Common Pitfalls

⚠️ 1. Checking permissions on every request with a DB query

Don't query the DB on every request to check permissions — it kills performance. Load permissions into the session at login and check from there. That's what we did above with session()->get('permissions').

⚠️ 2. Forgetting to refresh permissions after role change

If an admin changes a user's role, that user's session still has old permissions until they log out. Fix this by forcing a session refresh when role changes:

// In your Users controller — after updating role
if ($userId == session()->get('staff_id')) {
    $this->loadUserPermissions($userId); // Refresh own session
}

⚠️ 3. Hiding buttons is NOT enough security

Never rely on just hiding buttons in the view. Always check permissions in the controller or filter too. A user can manually type a URL and bypass view-level checks.

⚠️ 4. Route filter not applying

If your filter isn't working, make sure the filter is registered in Filters.php AND CodeIgniter's filters are enabled. Check app/Config/Filters.php for the $globals or $methods array too.

What to Build Next

ABAC (Attribute-Based Access Control) — go beyond roles, add conditions like "manager can only see their own team's data"
Role management UI — let admins create/edit roles and assign permissions from a dashboard
Permission audit log — track who accessed what and when
API route protection — extend the filter to check Bearer tokens with permissions

Conclusion

A solid RBAC system isn't hard to build in CodeIgniter 4 — it just needs to be done right from the start. Load permissions into the session, use a filter for route groups, and gate at the view level for UI polish.

Your controllers stay clean, your routes are self-documenting, and you never have another scattered is_admin check again.

Follow me for more CodeIgniter production tutorials — 3 new articles every week. 🙌

Senior PHP Developer · 12+ years building production systems on CodeIgniter, Laravel & WordPress

CodeIgniter 4 Pagination — Custom Styling with Bootstrap 5

sunakshi Thakur — Fri, 26 Jun 2026 13:38:55 +0000

Difficulty: Beginner–Intermediate | Read time: 10 min | Framework: CodeIgniter 4

The Problem with Default CI4 Pagination

CodeIgniter 4 has built-in pagination — but the default output looks nothing like Bootstrap 5. You get plain links with no styling, no active states, no prev/next arrows.

In every real project I've worked on, I end up customizing it. This tutorial shows you exactly how — from basic setup to a fully styled Bootstrap 5 paginator with AJAX support.

What we're building: A paginated list of records styled with Bootstrap 5, with custom prev/next buttons, active page highlighting, and optional AJAX loading.

Basic Setup First

Let's say you have a products table and want to paginate results.

1. The Model

<?php
// app/Models/ProductModel.php
namespace App\Models;

use CodeIgniter\Model;

class ProductModel extends Model
{
    protected $table      = 'products';
    protected $primaryKey = 'id';
    protected $allowedFields = ['name', 'price', 'category', 'created_at'];

    public function getProducts(int $perPage = 10): array
    {
        return $this->paginate($perPage);
    }
}

2. The Controller

<?php
// app/Controllers/Products.php
namespace App\Controllers;

use App\Models\ProductModel;

class Products extends BaseController
{
    public function index(): string
    {
        $model   = new ProductModel();
        $perPage = 10;

        $data['products'] = $model->getProducts($perPage);
        $data['pager']    = $model->pager;
        $data['perPage']  = $perPage;

        return view('products/index', $data);
    }
}

3. Basic View (before styling)

<!-- app/Views/products/index.php -->
<?php foreach ($products as $product): ?>
    <div><?= esc($product['name']) ?> — ₹<?= $product['price'] ?></div>
<?php endforeach; ?>

<!-- Default pagination (unstyled) -->
<?= $pager->links() ?>

This works — but looks terrible. Let's fix that.

Custom Bootstrap 5 Pagination Template

CI4 lets you create a custom pagination template. This is the proper way to style it.

Step 1 — Create the template file

<!-- app/Views/pager/bootstrap_5.php -->
<?php $pager->setSurroundCount(2) ?>

<nav aria-label="Page navigation">
  <ul class="pagination justify-content-center mb-0">

    <?php if ($pager->hasPreviousPage()): ?>
      <li class="page-item">
        <a class="page-link" href="<?= $pager->getPreviousPageURI() ?>" aria-label="Previous">
          <span aria-hidden="true">&laquo;</span>
        </a>
      </li>
    <?php else: ?>
      <li class="page-item disabled">
        <span class="page-link">&laquo;</span>
      </li>
    <?php endif ?>

    <?php foreach ($pager->links() as $link): ?>
      <li class="page-item <?= $link['active'] ? 'active' : '' ?>">
        <?php if ($link['active']): ?>
          <span class="page-link">
            <?= $link['title'] ?>
            <span class="visually-hidden">(current)</span>
          </span>
        <?php else: ?>
          <a class="page-link" href="<?= $link['uri'] ?>">
            <?= $link['title'] ?>
          </a>
        <?php endif ?>
      </li>
    <?php endforeach ?>

    <?php if ($pager->hasNextPage()): ?>
      <li class="page-item">
        <a class="page-link" href="<?= $pager->getNextPageURI() ?>" aria-label="Next">
          <span aria-hidden="true">&raquo;</span>
        </a>
      </li>
    <?php else: ?>
      <li class="page-item disabled">
        <span class="page-link">&raquo;</span>
      </li>
    <?php endif ?>

  </ul>
</nav>

Step 2 — Register the template in config

// app/Config/Pager.php
public array $templates = [
    'default_full'   => 'CodeIgniter\Pager\Views\default_full',
    'default_simple' => 'CodeIgniter\Pager\Views\default_simple',
    'bootstrap_5'    => 'App\Views\pager\bootstrap_5',  // <-- add this line
];

Step 3 — Use it in your view

<!-- Now use your custom template -->
<?= $pager->links('default', 'bootstrap_5') ?>

That's it — fully Bootstrap 5 styled pagination! ✅

Extra Styling — Make It Look Even Better

Add this CSS to make the active page and hover states pop:

/* Custom pagination styling */
.pagination .page-link {
    color: #6610f2;
    border-color: #dee2e6;
    padding: 8px 14px;
    font-size: 14px;
    transition: all 0.2s ease;
}

.pagination .page-item.active .page-link {
    background-color: #6610f2;
    border-color: #6610f2;
    color: #fff;
}

.pagination .page-link:hover {
    background-color: #f0ebff;
    color: #6610f2;
    border-color: #6610f2;
}

.pagination .page-item.disabled .page-link {
    color: #adb5bd;
    pointer-events: none;
}

Show Record Count (Very Useful in Real Projects)

Users want to know "Showing 1–10 of 154 records". Here's how:

// In your controller — add these to $data
$data['total']       = $model->countAllResults();
$data['currentPage'] = $model->pager->getCurrentPage();
$data['perPage']     = $perPage;

<!-- In your view -->
<?php
  $start = (($currentPage - 1) * $perPage) + 1;
  $end   = min($currentPage * $perPage, $total);
?>

<div class="d-flex justify-content-between align-items-center mb-3">
    <small class="text-muted">
        Showing <?= $start ?>–<?= $end ?> of <?= $total ?> records
    </small>
    <?= $pager->links('default', 'bootstrap_5') ?>
</div>

Output: Showing 1–10 of 154 records with pagination on the right. Clean and professional!

AJAX Pagination (No Page Reload)

For a smoother experience, load pages via AJAX:

<!-- In your view -->
<div id="products-wrapper">
    <?= view('products/_table', ['products' => $products]) ?>
</div>

<div id="pagination-wrapper">
    <?= $pager->links('default', 'bootstrap_5') ?>
</div>

<script>
$(document).on('click', '#pagination-wrapper .page-link', function (e) {
    e.preventDefault();

    const url = $(this).attr('href');
    if (!url || url === '#') return;

    $.get(url, function (response) {
        const html    = $(response);
        $('#products-wrapper').html(html.find('#products-wrapper').html());
        $('#pagination-wrapper').html(html.find('#pagination-wrapper').html());

        // Scroll to top of table smoothly
        $('html, body').animate({ scrollTop: $('#products-wrapper').offset().top - 80 }, 300);
    });
});
</script>

Common Pitfalls

⚠️ 1. Pagination not working with WHERE filters

If you apply filters before paginate(), always use $model->where() before calling it:

// WRONG — filter applied after, pagination counts wrong
$data['products'] = $model->paginate($perPage);
$model->where('category', 'electronics');

// CORRECT — filter first, then paginate
$data['products'] = $model->where('category', $category)
                           ->paginate($perPage);
$data['pager'] = $model->pager;

⚠️ 2. Template not found error

Make sure the path in Pager.php config matches exactly:

'bootstrap_5' => 'App\Views\pager\bootstrap_5'
// File must be at: app/Views/pager/bootstrap_5.php

⚠️ 3. Page resets to 1 on form submit

When using search + pagination together, pass the current page in your form:

<input type="hidden" name="page" value="<?= $currentPage ?>">

And in controller:

$page = $this->request->getGet('page') ?? 1;
$data['products'] = $model->where('name LIKE', "%{$search}%")
                           ->paginate($perPage, 'default', $page);

Full Working Example — Products Page

Here's everything together in one clean view:

<!-- app/Views/products/index.php -->
<div class="container py-4">

    <div class="d-flex justify-content-between align-items-center mb-4">
        <h4 class="mb-0">Products</h4>
        <small class="text-muted">
            Showing <?= $start ?>–<?= $end ?> of <?= $total ?> records
        </small>
    </div>

    <div class="table-responsive" id="products-wrapper">
        <table class="table table-hover align-middle">
            <thead class="table-light">
                <tr>
                    <th>#</th>
                    <th>Product Name</th>
                    <th>Category</th>
                    <th>Price</th>
                </tr>
            </thead>
            <tbody>
                <?php foreach ($products as $p): ?>
                <tr>
                    <td><?= $p['id'] ?></td>
                    <td><?= esc($p['name']) ?></td>
                    <td><span class="badge bg-secondary"><?= esc($p['category']) ?></span></td>
                    <td>₹<?= number_format($p['price'], 2) ?></td>
                </tr>
                <?php endforeach; ?>
            </tbody>
        </table>
    </div>

    <div id="pagination-wrapper" class="mt-3">
        <?= $pager->links('default', 'bootstrap_5') ?>
    </div>

</div>

Conclusion

CI4's pagination is powerful once you know how to configure it. A custom Bootstrap 5 template + the record count display makes your app look polished and professional — exactly what clients expect.

Follow me for more CodeIgniter production tutorials — 3 new articles every week. 🙌

Senior PHP Developer · 12+ years building production systems on CodeIgniter, Laravel & WordPress

How to Build a Support Ticket System in CodeIgniter 4 — With Role-Based Visibility and Email Notifications

sunakshi Thakur — Fri, 26 Jun 2026 13:08:02 +0000

Difficulty: Intermediate | Read time: 12 min | Framework: CodeIgniter 4

Why Build This?

Most tutorials show you CRUD forms. But real client projects need more — things like:

Tickets visible only to the right people (admin vs staff vs customer)
Auto-assigning tickets to staff and notifying them by email
Status history so you can audit what happened and when

I built exactly this for an internal CRM at my company. This tutorial walks you through the key parts so you can adapt it to your own projects.

What we're building: A ticket module where non-admin users only see tickets assigned to them, admins see everything, and staff get an email when assigned.

Database Structure

Start with two tables — tickets and a status history log.

CREATE TABLE `tblsupport_tickets` (
  `id`          INT AUTO_INCREMENT PRIMARY KEY,
  `subject`     VARCHAR(255) NOT NULL,
  `description` TEXT,
  `status`      ENUM('open','in_progress','resolved','closed') DEFAULT 'open',
  `priority`    ENUM('low','medium','high','critical') DEFAULT 'medium',
  `assigned_to` INT NULL,
  `created_by`  INT NOT NULL,
  `created_at`  DATETIME DEFAULT CURRENT_TIMESTAMP,
  `updated_at`  DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE `tblticket_status_history` (
  `id`         INT AUTO_INCREMENT PRIMARY KEY,
  `ticket_id`  INT NOT NULL,
  `old_status` VARCHAR(50),
  `new_status` VARCHAR(50),
  `changed_by` INT NOT NULL,
  `note`       TEXT,
  `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (`ticket_id`) REFERENCES `tblsupport_tickets`(`id`) ON DELETE CASCADE
);

The Model — Role-Based Ticket Fetching

This is where the real logic lives. The key insight: one method, different queries depending on who's asking.

<?php
// app/Models/Support_model.php
namespace App\Models;

use CodeIgniter\Model;

class Support_model extends Model
{
    protected $table = 'tblsupport_tickets';

    /**
     * Fetch tickets based on user role.
     * Admins see all. Staff see only their assigned tickets.
     */
    public function getTicketsForUser(int $userId, bool $isAdmin): array
    {
        $builder = $this->db->table('tblsupport_tickets t')
            ->select('t.*, s.name as assigned_name, c.name as created_by_name')
            ->join('tblstaff s', 's.staffid = t.assigned_to', 'left')
            ->join('tblstaff c', 'c.staffid = t.created_by', 'left')
            ->orderBy('t.created_at', 'DESC');

        if (!$isAdmin) {
            // Non-admins only see their own assigned tickets
            $builder->where('t.assigned_to', $userId);
        }

        return $builder->get()->getResultArray();
    }

    /**
     * Assign a ticket to a staff member and log the change.
     */
    public function assignTicket(int $ticketId, int $staffId, int $assignedBy): bool
    {
        $this->db->table('tblsupport_tickets')
            ->where('id', $ticketId)
            ->update(['assigned_to' => $staffId, 'status' => 'in_progress']);

        // Log the assignment in history
        $this->db->table('tblticket_status_history')->insert([
            'ticket_id'  => $ticketId,
            'old_status' => 'open',
            'new_status' => 'in_progress',
            'changed_by' => $assignedBy,
            'note'       => 'Ticket assigned to staff #' . $staffId,
        ]);

        return $this->db->affectedRows() > 0;
    }
}

💡 Note:
Why this approach works: Keeping the visibility logic in the model means your controller stays clean. If you ever need to change the rules (e.g. team leads see their team's tickets), you change it in one place.

The Controller — Listing and Assigning

<?php
// app/Controllers/Support_tickets.php
namespace App\Controllers;

use App\Models\Support_model;

class Support_tickets extends BaseController
{
    protected Support_model $supportModel;

    public function __construct()
    {
        $this->supportModel = new Support_model();
    }

    public function index(): string
    {
        $session = session();
        $userId  = $session->get('staff_id');
        $isAdmin = $session->get('is_admin') == 1;

        $data['tickets'] = $this->supportModel->getTicketsForUser($userId, $isAdmin);
        $data['isAdmin'] = $isAdmin;

        return view('support_tickets/index', $data);
    }

    /**
     * AJAX endpoint — assign ticket to a staff member.
     */
    public function assign(): \CodeIgniter\HTTP\ResponseInterface
    {
        if (!$this->request->isAJAX()) {
            return $this->response->setStatusCode(403);
        }

        $ticketId   = (int) $this->request->getPost('ticket_id');
        $staffId    = (int) $this->request->getPost('staff_id');
        $assignedBy = session()->get('staff_id');

        $assigned = $this->supportModel->assignTicket($ticketId, $staffId, $assignedBy);

        if ($assigned) {
            $this->_sendAssignmentEmail($ticketId, $staffId);
            return $this->response->setJSON(['success' => true]);
        }

        return $this->response->setJSON(['success' => false, 'message' => 'Assignment failed']);
    }

    /**
     * Send email to the assigned staff member.
     */
    private function _sendAssignmentEmail(int $ticketId, int $staffId): void
    {
        $staffRow = $this->db->table('tblstaff')
            ->where('staffid', $staffId)
            ->get()->getRowArray();

        if (!$staffRow) return;

        $ticket = $this->db->table('tblsupport_tickets')
            ->where('id', $ticketId)
            ->get()->getRowArray();

        $email = \Config\Services::email();
        $email->setTo($staffRow['email']);
        $email->setSubject('New Ticket Assigned: ' . $ticket['subject']);
        $email->setMessage(
            "Hi {$staffRow['name']},\n\n" .
            "A ticket has been assigned to you:\n\n" .
            "Subject: {$ticket['subject']}\n" .
            "Priority: {$ticket['priority']}\n\n" .
            "Please log in to review and action it.\n\n" .
            "Regards,\nSupport System"
        );

        $email->send();
    }
}

The View — DataTable with Inline Assignment

<!-- app/Views/support_tickets/index.php -->
<table id="ticketsTable" class="table table-hover">
  <thead>
    <tr>
      <th>#</th>
      <th>Subject</th>
      <th>Priority</th>
      <th>Status</th>
      <?php if ($isAdmin): ?>
        <th>Assign To</th>
      <?php endif; ?>
      <th>Created</th>
    </tr>
  </thead>
  <tbody>
    <?php foreach ($tickets as $ticket): ?>
    <tr>
      <td><?= $ticket['id'] ?></td>
      <td><?= esc($ticket['subject']) ?></td>
      <td>
        <span class="badge bg-<?= $ticket['priority'] === 'critical' ? 'danger' : 'warning' ?>">
          <?= ucfirst($ticket['priority']) ?>
        </span>
      </td>
      <td><?= ucfirst(str_replace('_', ' ', $ticket['status'])) ?></td>
      <?php if ($isAdmin): ?>
      <td>
        <select class="selectpicker assign-staff"
                data-ticket="<?= $ticket['id'] ?>"
                data-live-search="true"
                title="Assign...">
          <!-- Populated via AJAX or PHP loop over tblstaff -->
        </select>
      </td>
      <?php endif; ?>
      <td><?= date('d M Y', strtotime($ticket['created_at'])) ?></td>
    </tr>
    <?php endforeach; ?>
  </tbody>
</table>

<script>
// Inline assignment via AJAX
$(document).on('changed.bs.select', '.assign-staff', function () {
    const ticketId = $(this).data('ticket');
    const staffId  = $(this).val();

    $.post('<?= base_url('support_tickets/assign') ?>', {
        ticket_id: ticketId,
        staff_id:  staffId,
        '<?= csrf_token() ?>': '<?= csrf_hash() ?>'
    }, function (res) {
        if (res.success) {
            toastr.success('Ticket assigned and staff notified!');
        } else {
            toastr.error('Assignment failed. Try again.');
        }
    });
});
</script>

Common Pitfalls (and How I Fixed Them)

⚠️ 1. CSRF "Page Expired" on AJAX POST

Make sure you're sending csrf_token() and csrf_hash() with every POST. If you're using CodeIgniter's auto-regenerate CSRF, update the hash in the response and swap it client-side so the next request doesn't fail.

⚠️ 2. Bootstrap selectpicker not initializing on dynamic rows

Call $('.selectpicker').selectpicker('refresh') after any DOM update. If you're loading rows via DataTables, hook into drawCallback.

⚠️ 3. Email not sending on local dev

Set protocol = smtp in app/Config/Email.php and test with a real SMTP like Gmail or Mailtrap. Never debug with sendmail locally — it silently fails every time.

What to Build Next

This is a solid foundation. Here's what you can layer on top:

File attachments — store in S3 or local uploads, link to ticket ID
Customer-facing portal — external users submit and track their own tickets
SLA tracking — flag tickets that breach response time thresholds
Canned replies — let staff insert pre-written responses

Conclusion

A real support ticket system isn't complicated — but the details matter. Role-based visibility, status history, and email notifications are what separate a toy demo from something you can actually ship to a client.

If you found this useful, follow me for more CodeIgniter production tutorials — I publish new ones every week. 🙌

Senior PHP Developer with 12+ years building production systems on CodeIgniter, Laravel, and WordPress.

DEV Community: sunakshi Thakur

Integrating Claude/OpenAI API into a Laravel App: A Practical Guide

Step 1: Get Your API Keys

Step 2: Understand the Two APIs (They're 95% Similar)

Step 3: Build the Contract + Drivers

The Claude driver

The OpenAI driver

Step 4: Bind the Driver in a Service Provider

Step 5: Build a Real Feature

Step 6: Production Hardening (The Part Tutorials Skip)

Cache aggressively

Move long tasks to queues

Handle failures gracefully

Control your costs

What About the Official SDKs?

Wrapping Up

CodeIgniter 4 vs Laravel — When to Choose Which (From a Dev Who Uses Both)

The Core Difference in Code

When I Reach for Laravel

When I Reach for CodeIgniter 4

Decision Checklist

Takeaway

Bootstrap Selectpicker with CodeIgniter — Dynamic Rows & Refresh

The Problem Everyone Hits

Basic Setup

The Core Problem — Why Refresh Is Needed

Scenario 1 — Rows Added via AJAX

Scenario 2 — DataTables Integration

Scenario 3 — Changing Options Dynamically (Cascading Dropdowns)

Scenario 4 — Multi-Select With Search (Common in Filters)

Reusable Helper — Drop This in Every Project

Common Pitfalls

⚠️ 1. Calling .selectpicker() again on already-initialized elements

⚠️ 2. Selectpicker inside a hidden element (modal, tab)

⚠️ 3. Selectpicker breaking inside Bootstrap tabs

⚠️ 4. Values not syncing with the actual <select> element

What to Read Next

Conclusion

CodeIgniter 4 CSRF Protection in AJAX Forms — The Complete Fix

Why CSRF Breaks Your AJAX Forms

How CI4 CSRF Works (Quick Recap)

The 3 Most Common CSRF AJAX Mistakes

❌ Mistake 1 — Not sending the token at all

❌ Mistake 2 — Sending it once, never updating

❌ Mistake 3 — Wrong config for AJAX (redirect on failure)

The Complete Fix — Step by Step

Step 1 — Update Security Config for AJAX

Step 2 — Return New Token in Every AJAX Response

Step 3A — jQuery Global AJAX Fix (Recommended)

Step 3B — Individual AJAX Call Fix

Step 3C — Fetch API Fix (No jQuery)

Real-World Example — Lead Send Email Form

What If You Want to Disable CSRF for Specific Routes?

Common Pitfalls

⚠️ 1. Using the same token for multiple rapid requests

⚠️ 2. Token in URL (GET request CSRF)

⚠️ 3. SameSite cookie issues on some browsers

⚠️ 4. AJAX response is HTML instead of JSON

What to Build Next

Conclusion

Role-Based Access Control in CodeIgniter 4 — A Practical Guide

Why RBAC Matters in Real Projects

Database Structure

Seed Some Default Data

The Permission Helper

Load Permissions Into Session at Login

The RBAC Middleware (Filter)

Protect Routes With the Filter

Controller-Level Check

View-Level Gating

The 403 Permission Denied Page

Common Pitfalls

⚠️ 1. Checking permissions on every request with a DB query

⚠️ 2. Forgetting to refresh permissions after role change

⚠️ 3. Hiding buttons is NOT enough security

⚠️ 4. Route filter not applying

What to Build Next

Conclusion

CodeIgniter 4 Pagination — Custom Styling with Bootstrap 5

The Problem with Default CI4 Pagination

⚠️ 1. Calling `.selectpicker()` again on already-initialized elements

⚠️ 4. Values not syncing with the actual `<select>` element