Два ключевых недостатка ядра CodeIgniter 3

Если вы хоть немного знакомы с веб-разработкой, то первый вопрос который может у вас возникнуть а зачем вообще что-то делать на CodeIgniter 3 в 2026 году, однако в этом может быть какой-то смысл, и вот почему:

Это очень легкий и быстрый фреймворк.
Простая архитектура без многоуровневого наследования.
Проверенная годами технология (поддерживался до марта 2022).
Совместим с самыми последними версиями PHP 8 (с выключенными E_DEPRECATED).
Минимальный порог вхождения.
Отличная оффлайн документация (скачайте версию 3.1.11).
Компактный код без внешних зависимостей.

Я не буду советовать вам делать крупные коммерческие приложения с доступом из сети на устаревшей технологии, и сам этого не делаю, но небольшие админки для внутреннего использования, например для парсеров данных, и сами парсеры делать на нем достаточно удобно. Это первый фреймворк который я изучил, и чтобы не потерять навыки работы на нем, я иногда использую его в небольших приложениях. Хотя востребованность этих знаний не высокая, они ждут своего часа.

Какие же проблемы ядра CodeIgniter 3 я хочу выделить после нескольких лет работы на Laravel и Yii? На самом деле практически никаких. В прошлом, много лет назад, когда я делал что-то на этом фреймворке, то с каждым днем я открывал для себя новые недостатки этого фреймворка, расширял базовые классы, добавлял новую функциональность в ядро, писал модули, библиотеки, классы, и в итоге проект все дальше уходил от фреймворка, и все больше походил на самописный, что усложняло его поддержку. Не делайте так, используйте фреймворк из коробки, или используйте другой фреймворк, благо выбор есть.

Но несколько проблем в ядре я все-же решил:

CodeIgniter 3 кеширует все переменные которые передаются в отображения. Допустим у вас есть некоторый шаблон который пишет привет обычным черным цветом, и ещё в него опционально передается цвет.

$this->load->view('privet', array('color' => 'red'));
$this->load->view('privet');

Этот код выведет привет два раза. Первый раз определенно красного цвета, как вы думаете, какого цвета будет второй текст? Из предыдущего контекста, думаю что вы уже поняли что тоже красного. Фреймворк запоминает что переменная color передавалась, и при втором вызове шаблон не понимает что она не была передана, и использует предыдущее значение. Это источник просто огромного количества ошибок в коде. Это лучше исправить на уровне ядра.

<?php defined('BASEPATH') OR exit('No direct script access allowed');

class MY_Loader extends CI_Loader
{
    public function view($view, $vars = array(), $return = false)
    {
        $return = parent::view($view, $vars, $return);

        $this->clear_vars();

        return $return;
    }
}

Вторая проблема менее существенная, но это исправление требуется буквально для каждого приложения. Дело в том что штатная библиотека валидации может проверять что какого-то элемента нет в базе данных, например когда нужно добавить нового пользователя с уникальным адресом электронной почты, но при этом нет никакой возможности проверить уникальность этого адреса при редактировании этого пользователя. Штатный валидатор пишет что пользователь с таким адресом уже есть.

<?php defined('BASEPATH') OR exit('No direct script access allowed');

class MY_Form_validation extends CI_Form_validation
{
    public function is_unique($str, $field)
    {
        $res = sscanf($field, '%[^.,].%[^.,],%[^.,],%[^.,]', $table, $f, $pk, $id);

        if ($res == 4)
        {
            $where = [$f => $str, $pk . ' !=' => $id];

            return isset($this->CI->db)
                ? ($this->CI->db->limit(1)->get_where($table, $where)->num_rows() === 0)
                : FALSE;
        }

        return parent::is_unique($str, $field);
    }
}

Пример использования: