Меню Рубрики

Установка codeigniter с помощью composer

Установка фреймворка с помощью Composer

Ну что, решил облегчить себе задачу и установить Codeigniter с помощью пакетного менеджера Composer? Отлично! Это хороший выбор!

Перед началом установки я настоятельно рекомендую ознакомиться с разделом инструкции по ручной установке фреймворка, т.к. там очень подробно описаны некоторые «особенности», связанные с путями размещения файлов и директорий. Ну, а если ты уже в курсе, тогда поехали.

Имена и описания всех возможных пакетов для установки приведены в разделе документации Официальные репозитории .

1. Создание нового проекта из «стабильной» ветки

Данный способ подойдет всем разработчикам, кто хочет начать реализовывать свой проект на CodeIgniter 4. Этот репозиторий содержит готовый каркас приложения, включая все зависимости, необходимые для начала полноценной работы. Прежде чем сразу выполнять приведенные команды в консоле, сначала полностью прочитай информацию, приведенную в этой главе, чтобы выбрать наиболее правильный вариант установки.

Перейди на один уровень выше корневой директории своего проекта и выполни в консоле команду:

В этой команде, в качестве третьего параметра ( public_html ), ты должнен указать имя директории над которой ты поднялся и она же соответствует корню твоего проекта. Если ты не планируешь использовать в своем проекте phpUnit тесты, тогда ты можешь отказаться от установки этой зависимости, добавив к команде выше аргумент —no-dev . В этом случае, будет установлен полноценный базовый каркас для начала работы только с тремя, наиболее важными зависимостями. Вот пример этой команды:

Если ты всё сделал правильно, то в корневой директории /public_html (у тебя она может быть своя) ты увидишь следующую структуру:

После этого тебе необходимо внести изменения в настройки своего web-сервера и назначить папку /public корнем своего проекта. В случае, если ты не имеешь прав для внесения изменений в конфигурацию web-сервера (например на виртуальном хостинге), тогда рекомендую ознакомиться с разделом документации по ручной установке фреймворка. Там описаны некоторые нюансы, связанные с путями размещения файлов и директорий.

Если вышло обновление!

При выходе новых обновлений тебе достаточно перейти в папку /public_html и выполнить всего одну команду composer update , однако помни, что если ты устанавливал свой проект с аргументом —no-dev , то в этом случае и команда по обновлению должна иметь данный аргумент composer update —no-dev .

Данный способ развёртывания нового проекта очень удобен тем, что позволяет проводить установку и обновление фреймворка буквально парой команд, однако важно всегда помнить, что после очередного обновления необходимо проверять файлы с настройками в директории /app/Config , т.к. они могут быть перезаписаны новыми версиями.

2. Создание нового проекта из «developer» ветки

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

Сам процесс установки абсолютно аналогичен инструкциям из раздела «стабильной» ветки. Здесь меняется лишь имя устанавливаемого пакета с codeigniter4/appstarter на codeigniter4/devstarter и полный вид команды будет следующим:

Не забывай про имя твоей корневой директории и ключ —no-dev . В остальном, все последующие действия полностью аналогичны разделу выше.

Теперь остался последний шаг — внести начальные изменения в конфигурационные файлы проекта! Сделать это можно очень просто, прочитав следующий раздел документации Необходимые начальные настройки. Удачи!

Комментарии к разделу:

Пока ещё никто не оставил своего комментария. Оставить свой!

источник

Установка фреймворка в ручном режиме

Не хочешь использовать Composer и решил попробовать установить фреймворк вручную? Тогда начинаем!

Итак, перед началом работ, тебе необходимо определиться, из какой ветки репозитория ты хочешь загрузить фреймворк. Существуют 2 основные ветки развития фреймворка — это стабильная (stable) версия и «девелопер» (developer) версия. Логически понятно, что stable-версия обеспечивает максимальную безопасность и стабильность работы всех основных компонентов системы. Это именно тот вариант, с которого я рекомендую начать работу. Используя developer-ветку ты получаешь доступ ко всем последним обновлениям и новым инструментам, но важно помнить, что в процессе работы ты можешь столкнуться с какими-либо проблемами. Что использовать — решать тебе.

Cамостоятельно загрузить последнюю stable-версию Codeigniter 4 из официального репозитория можно по этой ссылке, а если ты решил использовать developer-версию, тогда жми сюда.

1. Распакуй скачанный архив

Если ты скачал stable-версию, то после распаковки архива ты увидишь следующую структуру файлов и папок:

В developer-ветке количество директорий и файлов может отличаться, но сути это не меняет. В любом случае, из всей структуры директорий и файлов нам понадобятся только 4 папки и 1 файл: /app , /public , /system , /writable и .env . За что отвечает каждая из директорий, ты можешь узнать из этого раздела документации, а пока смело копируй эти папки на сервер, в корневую директорию своего проекта.

Немного остановимся на файле .env . Файл .env (обрати внимание на обязательную точку в начале и если её нет, тогда переименуй файл, поставив эту точку) содержит бо́льшую часть переменных окружения и параметров фреймворка. Помимо этого, ты самостоятельно можешь указать в нём различные параметры, необходимые для работы. Например, это могут быть переменные с информацией для подключения к базе данных (хост, логин, пароль). Конечно, тебе никто не запрещает задавать параметры в конфигурационных файлах самого фреймворка (это вполне нормально), но тогда этот файл тебе не нужен, хотя это реально становится удобным, когда все настройки перед глазами и в одном файле. В дальнейшем, в других разделах документации, ты будешь встречать рекомендации по размещению тех или иных переменных именно в этом файле. Его совсем не обязательно копировать сразу. По мере необходимости ты можешь скопировать его позднее или вообще создать самостоятельно, ведь это простой текстовый файл.

Читайте также:  Установка закабинного спальника на грузовиках

Также тебе может понадобиться папка /tests , но только в том случае, если ты планируешь проводить отладку и тестирование своего проекта на базе phpUnit тестов (такая возможность предусмотрена).

После того, как все папки скопированы, структура твоей корневой директории должна выглядеть так:

Казалось бы все в порядке, но логически встаёт вопрос: «А как будет выполнен запуск проекта, если в корневой директории отсутствует файл /index.php «? Спокойно, сейчас всё расскажу!

В Codeigniter 4 разработчики решили добавить дополнительную безопасность и закрыть доступ ко всем директориям фреймворка на уровне сервера, создав стартовый файл запуска в директории /public . Таким образом, чтобы твой проект начал работать, тебе необходимо в адресной строке браузера указать: http://твой-адрес.ru/public . Всё будет работать, но согласись, не очень красивое решение, верно? А как же быть? Самое правильное решение, которое рекомендуют разработчики — это изменить в настройках самого web-сервера путь к корневой директории, назначив корнем проекта папку /public .

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

Все файлы из директории /public перенеси в корень своего проекта. Чтобы получилось вот так:

После этого открой файл /index.php и практически в самом начале ты увидишь строку:

В этой строке тебе необходимо удалить «../», тем самым задав расположение директорий фреймворка на том же уровне, что и файл index.php . Конечно, это не лучший вариант, но рабочий!

Есть еще один вариант, более правильный. Все директории, кроме папки /public перенеси на один уровень выше корневой директории, а содержимое папки /public по-прежнему скопируй в корень. В этом случае файл /index.php редактировать НЕ НУЖНО!

Приведу пример для второго варианта. На моем хостинге структура, по умолчанию, выглядит так:

Я вынес все директории фреймворка ВЫШЕ корня и конечная (правильная) структура получилась такой:

Примечание автора: Если ты не совсем понимаешь, зачем нужен второй вариант, то я могу пояснить. Перемещая папки выше корневой директории, ты получаешь дополнительную защиту со стороны самого сервера. Злоумышленник, попытавшийся получить доступ к твоим файлам проекта через браузер, не сможет этого сделать, поскольку настройки сервера не дадут подняться выше корневой директории. В большинстве случаев это не требуется, но выбор остаётся за тобой.

Всё, на этом установка фреймворка Codeigniter завершена! Как видишь, из всей огромной инструкции тебе понадобилось лишь скопировать несколько директорий на сервер и разобраться с размещением директорий и файлов, но обрати внимание, выше я написал установка завершена, но я же нечего не сказал о первоначальной настройке, а она необходима!

Теперь остался последний шаг — внести начальные изменения в конфигурационные файлы проекта! Сделать это можно очень просто, прочитав следующий раздел документации Необходимые начальные настройки. Удачи!

Комментарии к разделу:

Пока ещё никто не оставил своего комментария. Оставить свой!

источник

Обновление старых проектов до CodeIgniter 3

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

Дело в том, что последняя стабильная версия фреймворка была выпущена очень давно и многие даже успели его похоронить. Однако разработка, хоть и медленно, но продолжается. Более того, версия 3.0 достаточно стабильна, чтобы ее можно было использовать на живих проектах.

Несмотря на то, что ничего революционного в новой версии не появилось, полезных доработок достаточно, чтобы обновить свой проект, тем более, что обратная совместимость практически не пострадала.

CodeIgniter как зависимость

Рассмотрим процесс обновления на примере. Допустим у нас есть проект, со следующей структурой:

Для удобного контроля над версией фреймворка, добавим его в качестве зависимости в composer.json , благо такая возможность предусмотрена. Для этого в директории с проектом нужно выполнить комманду:

Composer скачает последнюю ревизию из ветки develop в директорию vendor/ellislab/codeigniter .

Таким образом структура нашего проекта будет выглядеть так:

Миграция конфигурационных файлов

Так как в версии 3.0 конфигурационные файлы и структура директории application/ несколько изменились — обновление нужно производить поэтапно.

Для начала сделаем резервную копию нашего проекта. Переименуем файл index.php в index_old.php , а директорию application/ в application_old/ .

После чего скопируем новые index.php и application/ из директории vendor/ellislab/codeigniter/ .

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

Когда конфигурация выполнена, можно начинать перенос контроллеров, моделей, шаблонов и т.д. Важная особенность: для того, чтобы CodeIgniter мог загрузить нужный класс (контроллер, модель или библиотеку), имя файла должно совпадать с именем класса который он содержит, с учетом регистра. Например, класс Main должен находится в файле Main.php , а не main.php как раньше.

Читайте также:  Установка подсветки для клавиатуры ноутбука

Итак, перенос практически завершен, остался последний штрих. В файле index.php нужно изменить значение переменной $system_path с system на vendor/ellislab/codeigniter/system . Таким образом наше приложение будет использовать версию CodeIgniter предоставленную Composer-ом.

Теперь можно открыть проект в браузере. Если он успешно открылся и проблем не наблюдается, то можно удалить index_old.php , application_old/ и system/ . Они нам больше не нужны.

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

Как подружить CodeIgniter и Composer

Теперь, чтобы используемая версия фреймворка была всегда актуальной, достаточно время от времени выполнять composer update .

Если вы захотите остановиться на стабильном релизе 3.0 , как только он выйдет в свет, то вам просто нужно будет в composer.json изменить dev-develop на

Обратите внимание, что хоть теперь в проекте и используется Composer, воспользоваться всеми его преимуществами не получится, так как для этого нужно подключить его автозагрузчик.

Исправить это можно и нужно, достаточно просто указать:

Вывод

В итоге наш проект теперь не только работает, на самой свежей версии CodeIgniter, но и использует всю мощь Composer-а. Надеюсь, после такого апгрейда работать с вашими старыми проектами станет удобнее и интереснее, а сами проекты смогут зажить новой жизнью.

источник

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 вообще является верхом шаманства.

Читайте также:  Установка полки уаз 469

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

  • Просто установить — не нужны никакие дополнительные программы, Композер (хотя можно и через него) и виртуальные машины — достаточно даже zip-архив распаковать — все будет работать из коробки.
  • Просто пользоваться — автозагрузка классов, типовой web-вариант MVC, где известно расположение каждого файла.
  • Только свои модули — нет каталога vendor (а-а-а-а-а. ), то есть всё своё — родное. Но при этом нет проблем воспользоваться Композером — ставь любые сторонние библиотеки сколько душе угодно.
  • Высокая функциональность, которая покрывает большинство задач по созданию сайтов.

Строго говоря, CodeIgniter 4 использует три сторонних библиотеки: ZendEscaper для функции экранирования, Psr\Log для поддержки PSR 3 (протоколирование) и Kint для вывода отладочной информации.

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

Впрочем, перейдем к практике. 🙂

Установка CodeIgniter

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

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

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

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

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

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

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

Что такое spark?

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

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

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

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

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

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

Обратите внимание, что класс 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 .

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

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

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

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

источник

Добавить комментарий

Adblock
detector