ГлавнаяCmsCms на codeigniter

[content-management-system] CMS на основе CodeIgniter. Cms на codeigniter


MaxSite CMS и CodeIgniter

В последнее время почему-то активизировалась тема о том, что якобы MaxSite CMS идеологически неверно построена. Нужно было делать по туториалу CodeIgniter, а я, подлец, сделал по-другому и теперь, якобы нельзя совместно с MaxSite CMS делать «классические» CodeIgniter-приложения.

Основные претензии сводятся к тому, что в MaxSite CMS используется единый контролер, что не нравится фанатам CodeIgniter, которые не в состоянии продвинуться дальше прочтения хелпов.

Я решил, вместо того чтобы крутить пальцем у виска, объяснить и продемонстрировать использование MaxSite CMS с «классическим» CodeIgniter-приложением.

Но, для начала немного объяснялок.

Устройство CodeIgniter таково, то методы с контролерами определяются из URL вот по такой схеме:

example.com/class/function/id

Контролер - это файл с классом, который ассоциируется с URL. Например  

example.com/blog/

Будет вызван файл controllers/blog.php в котором должен быть класс Blog. Если мне нужно вызвать контролер с явно указанным методом, то вызываем так:

example.com/blog/page

То есть контролер/класс Blog, в нем метод page. Еще можно указать прочие параметры, например id:

example.com/blog/page/id

В данном случае id будет передан как параметр метода page.

Это «классическая» схема работы CodeIgniter, где контролеры и их методы имеют жесткую структуру и, соответственно, предопределенный набор URL.

Любой, мало-мальски мыслящий человек понимает, что при таком подходе невозможно задать произвольные URL. Например я хочу, чтобы

example.com/hello

Выводилась страница с короткой ссылкой hello. А также

example.com/contact

Подгружался файл contact.php.

Потом появится другой клиент и скажет, что его не устраивает hello, пусть это будет about, а contact заменить на you_message. Потом появится третий и скажет вообще всё поменять к чёртовой матери и убрать этот contact, как источник спама.

Таким образом уже на этапе разработки необходимо предусмотреть возможнось произвольных методов/контролеров. Именно по этой причине в MaxSite CMS используется _remap(), метод который перекрывает «стандартное» определение методов контролера.

То есть мы можем определить один контролер и в его _remap() получать вызываемый метод. Дальше мы анализируем этот метод и решаем что с ним нужно делать.

Также в CodeIgniter можно задать дефолтный контролер. То есть вместо того, чтобы вызывать  

example.com/blog/page/id

Мы можем указать в качестве дефолтного контролера - blog и тогда запросы сократятся до вида:

example.com/page/id

Делается это через роутинг в файле конфигурации routes.php. Для MaxSite CMS указан дефолтный контролер maxsite. Соответственно у нас есть и controllers/maxsite.php. В нем уже используется _remap(), дальше идет инициализация ядра системы и т.д.

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

Продемонстрирую.

В комплекте CodeIgniter есть контролер welcome. Соответственно скопируем файл welcome.php в application/controllers и welcome_message.php в application/views. Я понятия не имею (условно) как и что там реализовано, но мне нужно вызвать по адресу example.com «содержимое» welcome.

Идем в routes.php и пишем:

$route['default_controller'] = "welcome";

Обновляем наш example.com и вуаля!, видим «Welcome to CodeIgniter! бла-бла-бла».

Ок, скажете вы, но теперь мы хотим получить доступ к MaxSite CMS! И будете правы, потому что роутер для MaxSite CMS настроен так, что если адрес содержит несколько сегментов, разделенных слэшем «/», то управление передается в контролер maxsite. Вы можете набрать example.com/admin и убедиться, что прекрасно попадает в админку MaxSite CMS.

Видите, изменили одну строчку, и уже какой результат!

Но, если вы делаете свое CodeIgniter-приложение, то скорее всего у вас должен быть другой роутер, например могут быть «blog», «post» и т.д. и всё это отдельные контролеры и их методы. Так что нужно сделать? Правильно, просто переписать условия в роутере!

Например мы хотим получать все запросы на welcome. Делается так:

$route[':any'] = "welcome";

Давайте теперь переиграем задачу. Пусть по умолчанию будет работать MaxSite CMS, а для перехода к welcome будем использовать адрес вида:

example.com/my

Меняем роутер так:

$route['default_controller'] = "maxsite"; $route['my:any'] = "welcome";

Переходим на заданный адрес и замечательно видим, как работает наш уже любимый welcome. При этом у нас также замечательно работает и MaxSite CMS.

Надеюсь, что данный экскурс в routes.php поставит большую и жирную точку на тех, кто утверждает, что в MaxSite CMS нельзя использовать «классические» CodeIgniter-приложения.

Другие записи сайта

maxsite.org

CMS на основе CodeIgniter — текущая ситуация / Хабр

На днях мне потребовалось установить движок для англоязычного блога. Проблема в том, что хостинг (VPS с объемом памяти 256 Мб) не тянет WordPress версии 2.6, а в 2.0.11 (которая, возможно, и заработала бы) работают не все нужные мне плагины. В общем, я решил посмотреть, какие сейчас существуют легкие CMS, причем на основе CodeIgniter, как наиболее быстрого и потребляющего мало памяти фреймворка PHP. Требования по функционалу у меня достаточно простые: возможность ведения блога, желательно с SEO-примочками (прописывание заголовков, мета-тегов, генерация Google Sitemap).

Для начала две CMS, которые я не рассматривал, как возможные решения:

MaxSite CMS — русскоязычная CMS, о которой я уже писал. Скажу сразу, что это самая продвинутая CMS на CodeIgniter из всех, перечисленных в этом обзоре, но для меня в данной задаче она не подошла по одной причине — ее русскоязычности, но об этом позже.

ExpressionEngine — замечательная CMS, у которой достаточно много поклонников, к тому же она создана теми же людьми, что и сам CodeIgniter. Но, во-первых, текущая версия (1.6.5) не реализована на CodeIgniter (разработчики планируют перейти на CI только в версии 2), а во-вторых, лицензия на ее коммерческое использование платная ($249.95), а персональный бесплатный вариант я использовать не могу.

Итак, какие варианты есть из того, что мне удалось найти:

Blaze — этот проект, похоже, уже умер, по крайней мере, последние новости системы датируются апрелем 2008 года. Зато он стал родоначальником для нескольких других CMS, которые рассматриваются ниже. Заставить нормально работать эту систему мне не удалось. Практически на любое действие возникали ошибки со ссылками, как с использованием mod_rewrite, так и без него.

Blogmer — честно признаюсь, эту CMS мне не удалось даже поставить, в дистрибутиве я не нашел файла index.php в корневой директории. Попытка подставить файл из самого CodeIgniter к успеху не привела. Информация об установке пакета при этом отсутствует.

Shanti CMS — попытка запуска системы выдает ошибку синтаксиса MySQL, инструкции об установке системы нет

CI-CMS — этот проект вроде бы достаточно живой, по крайней мере, автор периодически выкладывает свою работу в SVN (последние исправления — 23 октября). Система основана на Blaze, позиционируется как «модульная» (пока что есть только модули ядра, типа «блог», «страница» и т.д.). Поставилась легко, смог зайти в админку. Только вот незадача — найти в админке способ публикации материалов (блога и страниц) мне не удалось. Возможно, проблема в браузере, и нужно использовать IE (у меня FF), но это проверять я уже не стал :)

InkType — единственная полноценно работающая CMS из перечисленных. Ставится легко, я без проблем адаптировал для нее один из простых шаблонов от WordPress. Но толку от этого достаточно мало: в системе для сайдбара предусмотрено всего 4 виджета — recent posts, search, categories и blogroll, поддержка тегов в постах отсутствует, ну и вообще функционал очень скудный. Будем надеятся, что он будет развиваться, последняя версия системы — от 7 сентября 2008.

Выводы
1. Решения задачи в чистом виде я не нашел

2. InkType — это единственная из рассмотренных CMS, которой можно пользоваться, но только при очень скромных требованиях к функционалу.

3. Единственный выход на текущий момент — это использовать MaxSite CMS, но придется думать, как перевести ее на английский, хотя вероятно, это не так сложно.

habr.com

[content-management-system] CMS на основе CodeIgniter [php]

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

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

FuelCMS - новый ребенок на блоке

ExpressionEngine 2 - стоит, но, безусловно, лучше.

PyroCMS - бесплатный и, хотя выглядит уродливым как грех, ветвь v0.9.8-dev очень перспективна. Делает много больше, чем просто блоги.

DBlog - просто блог, но все хорошо.

посмотрите на CMS Egypt, это простая основа базы данных, аутентификации, dojo, datamapper, которая упростит вашу работу

http://blazeeboy.github.com/Codeigniter-Egypt/

Codefight CMS также основан на кодеригенере.

MaxSite CMS основан на CodeIgniter. http://max-3000.com/

Вот еще одна CMS на основе CodeIgniter с платной версией, которая включает функции электронной коммерции. Они также используют Smarty для управления шаблонами.

http://www.heroframework.com/

Nakid CMS - для решения, которое будет внешним с вашего сайта

Open Source CMS:

code-examples.net

CodeIgniter + CMS = MaxCMS | VR-online

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

Проекты нам попадаются самые разные, но в большинстве случаев приходиться заниматься разработкой индивидуальных конфигураций/программ на базе платформы 1С:Предприятие 8/Delphi и созданием сайтов. К каждому проекту мы подходим индивидуально и стараемся выбрать оптимальный путь решения поставленной задачи. Если с 1С:Предприятие все максимально стандартизировано (в плане методик разработки и набора технологий), то в WEB-программировании сам черт ногу сломит. Куча всевозможных фреймворков, систем управления сайтами, готовых модулей и т.д. Во всем этом многообразии легко потеряться.

Мы пробовали делать web-проекты на Drupal/Joomla/CodeIgniter/WordPress. Каждый из перечисленных продуктов оставил как приятные, так и не приятные впечатления. Например, Drupal дает максимум конфигурируемости, но за эту гибкость приходится платить сложностью разработки. Реально, чтобы не говорили фанаты Drupal (к коим я себя тоже могу отнести), но эта система пока сложна для изучения и имеет достаточно высокий порог вхождения. Я бы даже сказал, что если на Drupal’е требуется написать что-то нестандартное, то сразу возникает куча проблем. Конечно, проблем с опытом будет появляться все меньше и меньше, но на приобретение более-менее приличного скила потребуется время. И его надо больше, чем на постижение Joomla, Wordpress, CodeIgniter. Понятное дело, что все перечисленные мной движки/cmf находятся в разных весовых категориях, но ориентируюсь на общие моменты, т.е. изучение того минимума, который позволит начать разработку.

Из всех перечисленных выше продуктов нашими неотъемлемыми спутниками можно считать: Drupal, Wordpress и CodeIgniter. Joomla категорически не нравится, поэтому было решено ее выбросить из команды. Теперь Drupal у нас является главной ударной силой и мы готовы им пользоваться для разработки больших проектов. CodeIgnier выполняет роль ловкого нападающего и готов зажигать там, где требуется нестандартный подход (например, разработка какого-нибудь специфического web-приложения). Ну а WordPress стоял (уже в прошедшем времени) в защите и отражал типовые проекты аля сайты-визитки. Начиная с этого, месяца мы решили окончательно попрощаться с маленьким гигантом (это я про WordPress) и поддержать отечественное ПО. На замену в нашу “виртуальную” студию пришел MaxCMS (]]>http://max-3000.com/]]>). Это бесплатная CMS, созданная на базе любимого нами фреймворка CodeIgniter (]]>http://codeigniter.com/]]>).

Впервые о MaxCMS я узнал где-то с года полтора назад, но тогда, к сожалению, у меня не было времени познакомиться с ним получше. Я бы даже сказал, что вопрос был не во времени, а в отсутствии подходящего проекта. К счастью, на прошлой неделе поступил небольшой заказик и его мы решили выполнить именно на MaxCMS. Неделя вечерней разработки (созданию сайта мы уделяли по 1,5-2 часа с понедельника по пятницу) пролетела быстро и весело. Полученная практика позволяет смело выделить и назвать сильные стороны MaxCMS (по отношению к WordPress):

1. Производительность. По сравнению с WordPress MaxCMS просто пушинка и потребляет гораздо меньше памяти.

2. Скорость разработки. Это одна из самых сильных сторон MaxCMS. Верстать шаблоны и дорабатывать функционал намного (я бы даже сказал нааааааамнооого) проще, чем делать тоже самое под WordPress. Верстка шаблонов кажется просто сказкой (во всяком случае так показалось нам). Программировать приходится намного меньше. Кроме того, сама идея генерации шаблонов выглядит куда проще, чем аналогичная в WordPress.

3. Расширяемось. Функционал MaxCMS можно без проблем расширить за счет сторонних модулей. В месте с системой поставляется солидный набор уже готовых модулей, которые существенно упрощают разработку web-проекта. Если чего-то не хватает, то создать свой модуль достаточно просто. Провернуть ту же самую операцию для WordPress (а еще хуже того для Дру-дру) - задача не из легких.

4. Низкий порог вхождения. Чтобы разобраться с работой MaxCMS не нужно иметь пятикилограммовый мозг. Достаточно почитать статьи на официальном сайте и можно приступать к выполнению реального проекта.

Выводы

MaxCMS - многообещающая система управления контентом и для нас с Lord’ом она смогла заменить WordPress. Пускай проект еще достаточно молодой (чуть больше трех ле), но уже сейчас MaxCMS может похвастаться оригинальными идеями и выглядеть достойно среди подобных разработок. Скорость, бесплатность, качество, простота обучения - вот главные преимущества проекта. Если тебе время от времени приходится разрабатывать под Web, то обязательно присмотрись к этому продукту. Возможно ты обретешь новый незаменимый инструмент.

www.vr-online.ru

CodeIgniter и будущее maxSite CMS

Мне на почту пришёл интересный вопрос про будущее maxSite CMS движка в связи с кажущимся замедлением развития и понижением активности поддержки некогда очень популярного фремворка CodeIgniter:

Я долгое время слежу за развитием maxSite CMS, но до недавнего времени не задумывался о развитии CodeIgniter, а ведь если фреймворк умрет, а он уже практически умер, то в месте с ним канет в лету и maxSite, поэтому это меня стопорит в создании чего-то огромного и полезного: плагинов магазина, форума, системы личных сообщений и т.д. Как ты смотришь на это?

Я ответил на письмо, а потом подумал, что возможно другим членам сообщества движка тоже будет интересно высказаться на эту тему. Поэтому я публикую своё развёрнутое мнение, а желающие высказаться смогут это сделать здесь в комментариях (авторизацию на блоге починил, так что можно даже под комюзером комментировать) или у себя на блоге. Итак...

Лично я смотрю на причитания ситуацию вокруг CI не столь пессимистично, как автор исходного вопроса, т.к. по большому счёту, maxSite CMS завязан на CI только боком совсем немного. Да, отчасти используется структура папок, процедуры инициализации, хелперы и библиотеки (например, для доступа к базе данных) и т.д. Но, самое главное, движок не использует парадигму CI для построения приложений - нет никакой попытки внедрить возможности MVC/ООП и т.п. вещей из предлагаемых фреймворком средств разработки приложений. Т.е. по сути, CI активно используется в ядре движка, да и то в основном только лишь в качестве набора полезных функций для нужд движка. Причём вас никто особо не принуждает пользоваться в ваших разработках для maxSite CMS именно этими функциями - вполне можете внедрять свои велосипеды программные наработки и решения.

Думаю, что истерику шефвсёпропало! пессимистическую волну вокруг стагнирующего CI поднимают в основном идеалисты-перфекционисты (эти ребята никогда не успокоятся в своих претензиях ) и те, чьи проекты глубоко погрязли в инфраструктуре фреймворка. MaxSite CMS в этом смысле не такая Помню к первым версиям движка часто поступали отзывы типа - «фууу! там совсем нет ООП»! И только сейчас, спустя несколько лет и в связи с ситуацией вокруг CI, можно уверенно говорить, что такой сознательный отказ от «прелестей» CI был довольно удачным и перспективным техническим решением Максима.

Лично я в своей самой разнообразной практике разработки плагинов для maxSite CMS ни разу не столкнулся с каким-то принципиальным ограничением CI, которое нельзя было бы решить простым отказом от использования предлагаемых классов/хелперов (например, автоматически генерирование HTML-кода таблиц в основном подходит только для простых случаев и приходилось иногда формировать таблицы «напрямую») или инклудингом нужной специализированной библиотеки (такое было, например, когда было необходимо организовать импорт Excel-овских файлов). Я хочу сказать, что для нужд готовых и только проектируемых плагинов и проектов имеющихся в CI возможностей вполне достаточно и поэтому я не совсем понимаю, чего народ ещё хочет чтобы появилось в CI и без чего ну совсем нельзя обойтись? Конечно речь идёт только о контексте движка maxSite CMS и типичных задач, решаемых движком.

Допустим что CI объявлен умершим . Думаете стоит заворачивать прекращать ваши проекты на maxSite CMS? Но почему? Неужели сайты сейчас не справляются со своими задачами публикации контента? Конечно справляются. Это примерно также как в ситуации, когда продолжают нормально работать сайты, сделанные на дефолтном шаблоне первой версии - продолжают отлично работать даже после появления D2. Сайты скорее умрут от плохого контента, недостаточной раскрутки, слабого дизайна или от того, что блоги вести местами очень трудозатратно (например, одна только своеобразно реализованная загрузка изображений чего стоит - хотя файловая мультизагрузка хотя бы с применением того же jQuery File Upload Plugin176 сняла бы вопрос), но уж точно не от того, что в CI нет удобного ORM или неймспейсов.

К слову, у WordPress нет в основе популярного фреймворка и обходится как-то. В общем, движок если и умрёт, то не думаю, что это случится из-за CodeIgniter.

vizr.ru

CodeIgniter - это... Что такое CodeIgniter?

CodeIgniter — популярный MVC фреймворк с открытым исходным кодом, написанный на языке программирования PHP, для разработки полноценных веб-систем и приложений. Разработан компанией EllisLab (англ.)русск., а также Риком Эллисом (Rick Ellis) и Полом Бурдиком (Paul Burdick).

История

Первый публичный релиз фреймворка произошел 28 февраля 2006 года. С выходом версии 2.0 28го января 2011 года CodeIgniter разделился на две ветки:

  1. CodeIgniter Core — ветка, которая делает акцент на стабильности, в связи с чем развивается медленно. Эта версия фреймворка является ядром популярной CMS ExpressionEngine 2.0.
  2. CodeIgniter Reactor — ветка, которую развивает сообщество. Эта ветка развивается быстро и содержит самые новые возможности.

Особенности

Возможности

Примеры кода

Active Record

Выбрать все из таблицы
$this->db->get('table_name');

Эквивалент SQL:

SELECT * FROM `table_name`
Пример с операторами JOIN и LIMIT =
public function getData($id = 0, $offset = 0, $limit = 30) { $result = $this->db->select('table1.id, table2.name') ->from('table1') ->join('table2', 'table2.id=table1.id', 'left'); if ($id) return $result->where('table1.id', (int)$id)->limit(1)->get()->row(); return $result->limit($limit, $offset)->get()->result(); }

Сценарий 1 (когда $id = 0):

Данные: $id = 0, $offset= 10, $limit = 30

SQL на выходе:

SELECT table1.id, table2.name FROM table1 LEFT JOIN table2 ON table2.id = table1.id LIMIT 10, 30

Функция вернет массив объектов. (db->result())

Сценарий 2 ($id отличен от нуля):

Данные: $id = 5, $offset = 0, $limit = 30

SQL на выходе:

SELECT table1.id, table2.name FROM table1 LEFT JOIN table2 ON table2.id = table1.id WHERE table1.id = 5 LIMIT 1

Функция вернет один объект (db->row())

Критика фреймворка

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

Влияние CodeIgniter

CodeIgniter послужил базой для таких фреймворков, как Kohana и Rain Framework (англ.)русск., многие идеи CodeIgniter применены в фреймворках Fuel PHP[10] и CodeLighter[11].

Фреймворк Kohana изначально был ветвью CodeIgniter и был создан с целью использования всех возможностей PHP5 с сохранением простоты и высокой производительности CodeIgniter. Он отличался от CodeIgniter отсутствием поддержки PHP4 и наличием некоторых дополнительных библиотек (ORM, Auth и других). Если версии Kohana 2.x все еще чем-то были схожи с CodeIgniter, то современные версии (3.x) фактически не имеют с ним ничего общего, кроме истории.

На CodeIgniter основано множество CMS: Fuel CMS[12], MaxSite CMS[13], Cogear[14], PyroCMS[15] и другие.

Ссылки

Проекты, выполненные на CodeIgniter

См. также

Примечания

dic.academic.ru

Prostoy-Site | Все права защищены © 2018 | Карта сайта