CodeIgniter *

О чем это я...

Да, действительно, все наверное уже забыли (а кто-то может и не вспоминал), что такое CodeIgniter и давно его не рассматривают как полноценный фреймворк. Все довольно таки в нём просто: контроллеры, модели, отображения — и в каждом элементе MVC почти «чистый PHP». Никаких тебе миграций, модулей, окружений и прочих прелестей для удобной работы.

Сам я молодой программист, всего лишь год программирую на php, и из этого времени довольно таки много работал с этим фреймворком. Но на самом деле он очень хорош для общего представления об архитектуре MVC и для новичков, по-моему, просто не заменим. Смею сказать, что работаю также на YII и Symfony, и на самом деле с них было бы мне, например, нереально начать бороздить возможности PHP-фреймворков.

Изучая все больше и больше php и технологии, в которых удобно разрабатывать веб-приложения, я все дальше и дальше (да-да, всего лишь год «службы») отходил от CI и восхищался красотой и эргономичным использованием Symfony. Но вот тут совсем недавно натолкнулся на Bonfire — мощное дополнение к CodeIgniter.

Добрый день!

Долгое время на просторах интернета я искал информацию о реализации AJAX загрузки файлов для CodeIgniter. Разные разработчики предлагали разные технологии и примеры реализации. Я перепробовал их все, но ни одна из них не была достаточно проста и функциональна одновременно. Лишь недавно я открыл для себя jQuery File Uploader. «Он ничем не отличается от остальных» — скажите вы, но это не так. Его главное отличие — это простота и хорошая документация с примерами. В документации разобраны все callback'и, описаны все options. Внедрение в любую систему не занимает много времени.

Сегодня я покажу как можно очень просто организовать multipart загрузку файлов на сервер + drug&drop в CodeIgniter.

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

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

Решение проблемы

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

Доброго времени суток, товарищи.

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

Проблема

Я занимаюсь разработкой ресурса для кросс-постинга в социальные сети. Изначально продукт был предназначен только для Вконтакте и Facebook и для работы с API было выделено по одному контроллеры и по одной модели, плюс модель для работы с cURL. Пока была необходимость работать только с двумя социальными сетями такая классовая структура проекта не выглядела удручающей. Но стоило добавить работу ещё с несколькими соц. сетями, стало очевидно что такая модель ведёт к хаосу и полному бардаку как на стороне работы с API так и на стороне клиента. Чего стоит ветвление из 10 else if для просмотра данных пользователя или 10 ajax запросов для отправки сообщений в социальные сети. Было принято решение отрефакторить весь этот ужас, воспользовавшись паттерном Фабрика. Всё представлялось просто: описываем интерфейс с общим функционалом работы с API, делаем фабричный класс и единственный контроллер, который будет реквайрить фабричный класс. Но как только начали переносить функционал на новую парадигму, нас осенило. Вся работа в бд, пользовательскими данными, логами и https держится на CI моделях и библиотеках. Тут то я понял как был неправ, когда писал в курсовой что CodeIgniter не накладывает ограничений на разработчика — ещё как накладывает. Стоит немного шагнуть в своём решении за рамки модели MVC, возникает проблема — как включить это решение в проект.

А мы используем внутренние стандарты. Они действительно полезны:
— стандартам совершенно не обязательно следовать;
— они позволяют быстрее и комфортнее осваиваться;
— они помогают меньше теряться при творческом процессе.

Исторически свершилось так, что мы активно используем CodeIgniter. Стандарт по разработке приложений на CodeIgniter предлагается вашему вниманию.

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

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

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

В данной статье я бы хотел поделиться знаниями о том, как устроены, для чего нужны и что из себя представляют packages(далее пакеты) в Fuelphp. Прошу помочь сравнить реализацию и возможности пакетов Fuelphp с аналогами из других фреймворков. Думаю всем будет интересно узнать мнение адептов Simfony2 и Yii по этому поводу, милости просим, кидайте свои выкладки в комменты. Далее в примерах будет рассмотрен пакет fuel-ninjauth

Последние пять лет в истории PHP отличаются впечатляющими изменениями. Этот язык программирования развивается гораздо быстрее в области веб-программирования — релиз РНР 5.4 имеет большинство функций, необходимых в работе с современным веб-языком. Обеспечение поддержки пространства имен — одна из них. Возможность не из новых (php 5.3), но мы использовали ее в своей работе впервые. Собственным практическим опытом и жаждем поделиться.

Общее описание

HyperActive Record – это надстройка над классом DB для фреймворка CodeIgniter 2.0 и выше, позволяющая получать значения полей связанных с записью объектов по внешним ключам (foreign keys) без дополнительного описания связей и данных. Такая недо-ORM
На гитхабе
Страница библиотеки

Добрый день, друзья,

Буквально недавно questman написал статью о новом-старом сервисе от Google под названием Google Cloud Messaging и привел пример приложения под android с его использованием.
Со своей колокольни я бы хотел продолжить тему с точки зрения server-side с оглядкой на опыт использования Apple Push Notifications.

Вот уже третий год мы предлагаем изначально созданный на базе Codeigniter проект ImageCMS. За это время на рынке фреймворков многое поменялось, особенно заставляет задуматься кажущееся понижение активности поддержки фреймворка Codeigniter и большой рост популярности фреймворка Yii. Споры о преимуществах разных фреймворков не затихают. Давайте попробуем соотнести вопрос о выборе фрейморка с ImageCMS и разобраться почему мы работаем с CI.
Несколько причин, которые мы считаем существенными для того, чтобы продолжать работу с Codeigniter:

Как вы наверное знаете, в php есть интересная функция для обработки данных, поступающих из командной строки: getopt. Но есть одна маленькая проблема — она неправильно работает в CodeIgniter, да и не совсем удобная.

А так как у меня было немного свободного времени, желание написать что-нибудь своё опен сорсное, попробовать в деле github (сижу на hg+bitbucket), и наконец сделать что-то полезное для тухнущего CodeIgniter и его сообщества, я решил написать свой костыль, призванный немного скрасить написание cli скриптов на данном фреймворке.
Оно умеет самый минимум — искать заданные аргументы, производить их валидацию (если не указаны обязательные) и выводить подсказки по использованию вашего скрипта, а при желании легко может быть допилено для использования без привязки к CodeIgniter:

Добрый день, ХабраСообщество!
Уже почти месяц веду разработку проекта на CodeIgniter 2.0 и к середине написания столкнулся с проблемой при написании администраторской части. Так сложилось что с «CI» знаком уже более 2-х лет, и еще не разу CodeIgniter меня не подвел в своих возможностях.
Сам проект у меня исчисляется 35 таблицами и писать администраторскую панель мне необходимо для «хомячков». Подсчитав приблизительные человеко-часы необходимые на разработку интерфейса + программной части, я пришел в дикий ужас. Энтузиазм немного поутих (проект мой личный). Вспоминая добрым словом хоть какой-то CRUD в старых версиях, я рискнул «спросить Гугл», авось повезет… И повезло!

Доброй ночи, хабралюди.
Хотел бы поделиться с вами самодельной библиотекой для codeigniter под названием Notify.
Она создана для вывода сообщений пользователю.

Друзья, прошло уже 2,5 года, как мы выпустили в свет ImageCMS и за это время она существенно изменилась. Мы решили создать свой корпоративный блог на Хабре, чтобы держать вас в курсе наших новостей и предоставить более удобный способ следить за ходом развития системы для всех хабрапользователей.

ImageCMS как и раньше продолжает развиваться в первую очередь как бесплатный OpenSource проект, мы заинтересованы в большом количестве партнеров и активных пользователей, которые развивали бы ее вместе с нашей командой.

ImageCMS постоянно развивается и совершенствуется, регулярно выходят новые релизы, которые увеличивают удобство и быстроту работы системы. Для того, чтобы сделать систему еще более интересной для разработчиков, появится магазин модулей, шаблонов и плагинов, в котором наши партнеры смогут предлагать свои разработки. Мы считаем, что это станет серьезным шагом на пути развития нашей системы.

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

Как вы уже могли прочесть, недавно вышла новая версия CodeIgniter, одним из нововведений которого является библиотека Migration. Один из главных ее разработчиков, Phil Sturgeon был настолько воодушевлен удобством управления версиями баз данных для Rails, что решил создать аналог такого метода для CodeIgniter, и вот, в конце-концов вы можете видеть эту библиотеку в официальной поставке.
Из этой статьи вы получите общее представление о миграциях, а также научитесь их создавать. Во второй же части, мы с вами увидим, как легко они могут быть интегрированы в ваше приложение.
Данная статья будет полезна начинающим пользователям CodeIgniter, но я надеюсь что и более продвинутые коллеги узнают об этой чудесной библиотеке и подчерпнут для себя что-нибудь новое.

Кроме всего прочего, данная библиотека совсем не сложна, и реализовать ее при желании для любой другой платформы не составит большого труда!

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

Итак драйвер — это особый тип библиотеки, которая состоит из одного родительского класса и нескольких дочерних. Дочерние классы получают доступ только к родительскому классу, но не имеют доступа к свои собратьям. Термин «дочерний» на самом деле не наследует поля родителя, а лишь получает к ним доступ.

Драйверы служат для разбиения ваших библиотек на отдельные классы и в CodeIgniter представляют собой реализацию структурного шаблона проектирования Декоратор.

Сессии в Codeigniter хороши всем. Правда, очень удобно сделаны, особенно когда вы храните сессии в БД (что я считаю единственно верным). Куки шифрованные, в куках ничего, кроме идентификатора нету. Они привязываются к user_agent и, опционально, к IP. Красиво, безопасно.

Но есть у них очень существенный недостаток: жизнь сессии считается от поля last_activity. Это значит, что если у вас стоит expire сессии в двое суток, то при обращении к сессии, у которой last_activity < time()-172800, она ликвидируется и начинется новая. Следственно, для того что бы пользователям не приходилось каждый раз логиниться на сайт, last_activity нужно поддерживать в акутальном состоянии.
Поле last_activity обновляется в двух случаях: когда вы записываете что-то новое в сессию, либо когда сессия обновляется (по-умолчанию каждые 5 минут, опять же, относительно last_activity; указывается в конфиге). И вот главная проблема в том, что при обновлении сессии меняется session_id и текущая сессия у пользователя сессия прерывается, стартует новая.

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

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

Но голь, как известно, на выдумки хитра, поэтому простое решение таки нашлось.