CodeIgniter 4. Основы. Установка

Скоро планируется релиз CodeIgniter 4 и я подготовил несколько статьей, посвященных этому php-фреймворку. Обычно, когда речь заходит о CodeIgniter, то возникают двоякие чувства: с одной стороны это легендарный фреймворк, который послужил хорошим стартом для многих проектов, а с другой, его история показывает, что случается с теми разработками, которые не получают должной поддержки и развития.

CodeIgniter 4 — это совершенно новая разработка, поэтому не стоит её рассматривать в связке со старыми 1/2/3 версиями. Команда разработчиков хорошо потрудилась — получился современный и качественный php-фреймворк.

История CodeIgniter

Нужно немного затронуть тему истории и особенностей CodeIgniter, потому что невольно он сравнивается с другими фреймворками.

История CodeIgniter берёт начало в 2006 году. Тогда только вышел PHP 5.1. Это наложило отпечаток на архитектуру проекта. К слову сказать, она оказалась продуманной, поэтому такой подход стали использовать в других php-разработках.

CodeIgniter проще всего сравнивать с Laravel. Ирония в том, что именно из-за прекращения развития CodeIgniter и появился Laravel и изначально очень сильно на него походил. Если будет желание, поищите Laravel 1, 2, 3 или 4-й версии — уверен, вам понравится. :-)

Вторая версия CodeIgniter появилась в 2011 году, где была прекращена поддержка PHP 4. Минимальной стала PHP 5.1.6, хотя уже вышла 5.3, но на хостингах это всё еще было редкостью.

Дальше мы не знаем что именно случилось, но CodeIgniter фактически прекратил свое развитие и где-то с 2012 года стали выходить только мелкие фиксы. До 2014 года особых проблем это не создавало, пока не вышел PHP 5.4, после 5.5 где уже были реализованы те самые возможности, которых так не хватало в PHP, и которые были реализованы на уровне самого CodeIgniter.

Потом, как мы помним, EllisLab хватило мужества отдать разработку CodeIgniter студентам из British Columbia Institute of Technology, после чего вышел CodeIgniter 3 (2015 год), который по сути оставался всё той же старой 2-й версией. Разрыв с PHP 5.6, а чуть позже и 7.0 стал критичным.

Несколько лет назад в BCIT осознали, что студентов нужно учить современным фреймворкам, и они объявили о начале работ над CodeIgniter 4, который по сути и был переписан с нуля. Нужно отдать должное разработчикам, это не просто гигантский объем работ, но они умудрились сохранить ту простоту кода, которой CodeIgniter всегда и славился.

Я упомянул Laravel не зря. Это хороший пример того, как основной разработчик дал слабину и его фреймворк свернул с пути простоты и удобства к сложному и запутанному коду (как это когда-то произошло с Symfony). Изначально Laravel использовал идеологию CodeIgniter — просто установить и просто использовать. Но в 5-й версии Laravel решили отказаться от этого в пользу «модульности». Теперь чтобы даже элементарно установить фреймворк требуется выполнить миллион загадочных действий с использованием Композера и консольных artisan-команд. Более того, разработчики Laravel вообще предлагают использовать отдельную виртуальную машину под своё детище...

Когда-то в Laravel 3 был такой about:

A PHP Framework For Web Artisans
Laravel is a clean and classy framework for PHP web development. Freeing you from spaghetti code, Laravel helps you create wonderful applications using simple, expressive syntax. Development should be a creative experience that you enjoy, not something that is painful. Enjoy the fresh air.

Сейчас это читается как издевательство. ;-(

В чём здесь проблема? Laravel стал развиваться за счёт сторонних модулей. Через Композер подтягивается еще несколько десятков сторонних проектов, включая множество модулей Symfony. То есть понять как работает фреймворк невозможно, поскольку всё не просто спрятано «под капотом», но и очень хитро переплетено с помощью искусственных «фасадов». Теперь недостаточно знать PHP, нужно ещё под рукой держать талмуд хелпов для каждого «чиха», а умение работать с artisan вообще является верхом шаманства.

Что в CodeIgniter 4? Вот тут они дают фору расспиаренным php-фреймворкам.

  • Просто установить — не нужны никакие дополнительные программы, Композер (хотя можно и через него) и виртуальные машины — достаточно даже zip-архив распаковать — все будет работать из коробки.
  • Просто пользоваться — автозагрузка классов, типовой web-вариант MVC, где известно расположение каждого файла.
  • Только свои модули — нет каталога vendor (а-а-а-а-а!!!), то есть всё своё — родное. Но при этом нет проблем воспользоваться Композером — ставь любые сторонние библиотеки сколько душе угодно.
  • Высокая функциональность, которая покрывает большинство задач по созданию сайтов.
Строго говоря, CodeIgniter 4 использует три сторонних библиотеки: ZendEscaper для функции экранирования, Psr\Log для поддержки PSR 3 (протоколирование) и Kint для вывода отладочной информации.

Когда говорят, что CodeIgniter — только для новичков, то это ложь. Простота здесь как раз и есть признак хорошего кода. Возможностей CodeIgniter хватит для 80% задач любого сайтостроителя. А если не хватит, то можно воспользоваться сторонними разработками, как это делают другие фреймворки.

Впрочем, перейдем к практике. :-)

Установка CodeIgniter

Можно установить через Composer или git. Например так:

git clone https://github.com/codeigniter4/CodeIgniter4.git ci4

Будет создан каталог ci4, где окажутся все файлы дистрибутива. Там их довольно много, многие из них просто не нужны, поэтому мы сразу удалим лишнее. Получится вот так:

app/
public/
system/
writable/
spark — это файл

Теперь важный момент. CodeIgniter 4 предлагает размещать в публичной директории сервера (обычно это public_html) только фронт-контролёр (корневой index.php) и прочие web-файлы (стили, скрипты, изображения и т.п.). Это имеет смысл, если вы делаете что-то сверхсекретное и боитесь, что кто-то взломает сервер и похитит ваш супер-код. На практике это не имеет смысла (об этом чуть позже), поэтому мы будем размещать всё в одном web-каталоге.

Ещё раз подчеркиваю, что это не принципиально — для CodeIgniter всё равно каково будет расположение. Это мы делаем для себя.

Для этого содержимое public перенесем в корень ci4, а каталог public можно удалить. Получится так:

app/
system/
writable/
 
.htaccess
favicon.ico
index.php
robots.txt
spark

Теперь нужно открыть index.php и найти строчки:

// Location of the Paths config file.
// This is the line that might need to be changed, depending on your folder structure.
$pathsPath = FCPATH . '../app/Config/Paths.php';
// ^^^ Change this if you move your application folder

Уберем точки в пути:

$pathsPath = FCPATH . 'app/Config/Paths.php';

Всё, запускаем в браузере: http://localchost/ci4 (у вас может быть другой адрес) и видим приветствие CodeIgniter.

Welcome to CodeIgniter 
bla-bla-bla...

Что такое spark?

Сразу здесь об этом расскажу, чтобы после не возвращаться. Это консольная php-программа. Как artisan в Laravel. C помощью spark можно выполнять некоторые операции, например накатывать миграции или запустить локальный php-сервер. Поскольку мы поменяли расположение public, то в файле sparkнужно указать корректный путь:

Вместо

define('FCPATH', __DIR__ . '/public' . DIRECTORY_SEPARATOR);

Указать

define('FCPATH', __DIR__ . DIRECTORY_SEPARATOR);

Проверить spark можно прямо в консоли:

php spark

Будет выведена информация о командах.

MVC

CodeIgniter используется модель MVC, где входящий url-запрос после роутинга попадает в контролёр.

Отмечу, что на самом деле CodeIgniter используется не «настоящий» MVC, а скорее MVP, или разновидность, которая называется MVC с пассивной моделью. Конечно же дело не в названии: просто на сегодняшний день это фактически единственная схема построения приложений для web (почти во всех php-фреймворках), где контролёр управляет моделью и представлением.

Все контролёры располагаются в каталоге app/Controllers. Откройте файл Home.php— это контролер для главной страницы (так настроено по умолчанию).

namespace App\Controllers;
 
class Home extends BaseController
{
    public function index()
    {
        return view('welcome_message');
    }
}

Обратите внимание, что класс Home расширяет BaseController. При этом BaseController находится в этом же каталоге. Сделано это для упрощения кода. Иначе пришлось бы расширяться от системного класса Controller и выполнять его инициализацию (parent::initController). В данном случае BaseController — это «базовый» контролёр для вашего приложения.

Из кода понятно, что контролёр использует представление (View) «welcome_message».

Все представления («вьюшки») хранятся в app/Viewsв своих php-файлах. В нашем случае это welcome_message.php. Откройте его и увидите привычный html-код, который можно править.

CodeIgniter в подкаталогах

Можно разместить CodeIgniter в подкаталоге. Это особенно актуально для виртуального хостинга, где в одном аккаунте может быть несколько сайтов. Что для этого нужно? Да в общем-то ничего. :-) Просто размещаете файлы в подкаталоге как обычно, CodeIgniter автоматом всё подхватит.

И это одна из причин, по которой мы отказались от каталога public. Иначе на сервере возникнет жуткая путаница, когда где-то в корне сервера располагается множество каталогов, которые даже не понятно к чему относятся.

Ну и «любовь» к отдельному public наблюдается в тех фреймворках, которые не заботятся о безопасности. Например в Laravel секретную информацию (база, почта и т.п.) размещают в текстовом файле .env. В CodeIgniter вся информация хранится в php-файлах (это же php-фреймворк!), поэтому даже если вызвать файл напрямую, то ничего не произойдёт.

Сообщения об ошибках

По умолчанию CodeIgniter подавляет сообщения о PHP-ошибках. Это полезно на готовом сайте, но плохо подходит для написания кода. Чтобы изменить это поведение, следует в корневом index.php(в начале файла) задать константу ENVIRONMENT, которая может принимать варианты:

  • development— режим отладки, где выводится вся подробная информация.
  • testing— режим вывода обычных php-ошибок.
  • production— это и есть режим по умолчанию.

Наиболее удобный режим development.

define('ENVIRONMENT', 'development');

Кроме этого CodeIgniter по-умолчанию создаёт лог ошибок, который располагается в каталоге writable/logs. Отключить ведение лога можно в файле app/Config/Exceptions.php, указав $log = false;

Неточности в документации

CodeIgniter 4 пока ещё не вышел, поэтому в его документации пока ещё много ошибок и неточностей.

ps Статьи о CodeIgniter 4 я разделил на несколько циклов. Пока готов первый до использования базы данных.

Комментариев: 9 RSS

1Александр Соловей15-08-2019 10:21

Привет! Столкнулся с проблемой вывода данных в view в Codeigniter 4. Хочу через цикл foreach вывести массив данных полученный из БД. Но вместо вывода получаю в браузере закомментированный РНР-код:

Что нужно настроить, чтобы заработал РНР-код во view?

2MAX15-08-2019 10:42

Вообще странно — в view можно использовать php-код без ограничений. Может какая-то ошибка во время выполнения. Посмотрите лог или включите режим отладки, будет понятней что за ошибка.

3Аноним15-08-2019 11:41

Нашел!

Хотя лог молчал. Дебагер тоже.

В браузере выводило вот так:

Оказалось: что при выводе переменных можно использовать короткие теги PHP, а вот при использовании другого кода РНР - нужно использовать длинные теги.

4MAX15-08-2019 12:39

Кроткие php-тэги давно уже не используются. Нужно либо полные, либо альтернативный синтаксис.

5Аноним15-08-2019 13:18

Странно, короткие теги используют в welcome_message.php для вывода переменных.

6MAX15-08-2019 13:38

Нет, это альтернативный синтаксис PHP. Его можно и нужно использовать. А короткий это <? Вместо него нужно использовать <?php

7Георгий13-10-2019 17:10

Спасибо!

Интересно.

Ждем цикл статей=)

8Павел19-01-2020 14:09

Желание перейти с CI3 на CI4 появилось уже давно, но пока, как-то все времени не хватает, по этому процесс перехода идет медленно.

Статья очень хорошая, благодарю.

Так может потому разработчики перенесли index.php в public, что б можно было спокойно работать с .env файлом?

Ведь как не крути, но все же удобнее, когда у тебя все функциональные настройки находятся в корне в одном файле, а не разбросаны по всему проекту.

9MAX19-01-2020 15:44

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

Оставьте комментарий!

Комментарий будет опубликован после проверки. Вы соглашаетесь с правилами сайта.

(обязательно)