Современная, быстрая и удобная система управления сайтом

MaxSite CMS для разработчиков

БлогКомментарии: 17Просмотров: 4985

Почти два месяца мне потребовалось на то, чтобы сделать каркас для будущей CMS. Теперь, когда основа создана, я приглашаю разработчиков поучаствовать в создании системы.

Хочу особо подчеркнуть: требуются не тестеры, а разработчики. Потому что тестировать особо нечего. Нужно посмотреть, может быть найти ошибки и может быть взять на себя работу по созданию какого-то админского плагина/страницы и т.д. То есть требуются знания PHP, и очень желательно CodeIgniter. Так, что если вы готовы, то пишите мне на max-3000###list.ru - в обратную я вышлю файл с текущей системой. Свои замечания и предложения вы можете выслать мне опять же письмом, а можно через отдельный форум. Естественно, я беру на себя обязательство объяснить что я понапридумывал в коде. :) Пока же коротко о MaxSite CMS (информация для разработчиков).

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

1. Система основана на CodeIgniter, поэтому активно используются его функционал.

2. Адресация (URL) происходит через роутер. Настроен он так, что все запросы переправляются на контролер maxsite. Если вы хотите использовать какой-то дополнительный контролер, то нужно прописать это в роутере.

3. В контролере прописаны основные методы. Метод - по сути тип данных/страница. Например адрес «сайт/page/12» - «page» - метод и тип данных (для чего это, чуть ниже).

4. Контролер использует метод «_remap». Работает так: если вызываемый метод существует, то он и выполняется. Если метода не существует, то происходит поиск в каталоге контролеров файла с тем же именем (только добавляется расширение «.php»). В качестве примера я добавил файл contact.php - таким образом можно расширять типы данных без переписывания основного контролера. И если уже не найден и файл, то происходит выполнение метода «page_404».

5. Сами методы содержат вызов вьювера (из views). Тут нюанс в том, что вьювер не является конечным отображением страниц. У нас CMS, которая поддерживает разные шаблоны, поэтому во вьювере только считывается текущий шаблон и подключается его файл index.php. Дальнейшая логика и функционал выполняется в этом файле шаблона (как - чуть ниже).

6. Основной вьювер index.php, но в нем используется тип данных. Это что-то вроде WordPress-овского is_single, is_home и т.п. Только у меня используется более универсальное решение: is_type(). Для того, чтобы «связать/передать» тип данных используется глобальный массив $MSO_data. То есть хоть мы и используем один вьювер для разных методов, но за счет указания типа данных, наш шаблон получает указание того какие именно данные требуется выводить.

7. Для некоторых методов не требуется делать ни типы, ни передавать управление в шаблон. В таких случаях мы используем обычные возможности вьюверов. Примеры: install, url, xmlrpc, login и некоторые другие.

8. Такая схема позволяет без особого труда создавать новые типы данных. Например, клиент вдруг захотел внедрить на сайте каталог продукции. У вас два варианта. Первый - вы создаете свой контролер «catalog» и делаете его как это принято в CodeIgniter. Второй - вы создаете файл «catalog.php» и в нем указываете тип «catalog». Дальше делаете вывод данных уже через шаблон.

9. Шаблон устроен очень просто. В каталоге должен быть только файл index.php. Обязательно. В этом файле вы анализируете тип данных и подключаете соответствующий файл. В общем смотрите default - там все это сделано. (Оформлением не занимался!)

10. Плагины. Тут я решил, что водпрессовского бардака не будет, поэтому любой плагин должен строго следовать базовым правилам. Прежде всего каждый плагин должен находиться в отдельном каталоге и имя каталога должно совпадать с именем файла плагина. Кроме этого должен быть файл info.php, в котором содержится массив с информацией о плагине.

11. В плагине все функции должны именоваться с именем этого плагина. Существуют предопределенные имена функций: плагин_autoload(), плагин_ativate(), плагин_deativate(), плагин_uninstall(). Для чего они предназначены, в общем ясно из их названия.

12. В плагине (впрочем, как и везде) можно использовать хуки (hooks). То есть при вызове хука выполнится и указанная функция.

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

14. Чтобы связать любой плагин с админкой, нужно выполнить две функции: одна из них добавляет пункт в админское меню (два уровня), вторая - прописывает хук на url плагина. При желании можно добавить и пункт меню (горизонтальный), но уже на какой-то другой админской странице. Примеры реализации см. в плагинах «admin_options» и «admin_cat».

15. Для того, чтобы продемонстрировать примеры я сделал плагин «_null».

16. Некоторые функции будут вынесены в XMLRPC. Это сервер, который получает название метода и данные для него и выполняет их. Через этот механизм работают блог-клиенты. Поэтому, чтобы не дублировать функции через админку, я сразу же решил реализовывать их через XMLRPC. Пока что я сделал три метода для добавления, изменения и удаления рубрики. Посмотрите плагин «admin_cat», чтобы убедиться в том насколько просто реализуется нужный функционал.

Вот пока всё. Что еще требуется сделать.

- Админские плагины (большинство) пока что реализованы в виде «заглушки». Нужно их доделать.

- Нужно сделать дефолтный шаблон. Хотя бы дизайн.

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

- Совершенно не реализована работа с юзерами. Точнее есть только login/logout. Нужно еще придумать алгоритм, который позволит создавать группы пользователей и иметь возможность устанавливать различные разрешения для отдельных пользователей (на форуме уже обсуждали).

- Сделать импорт/экспорт данных. Идеально, чтобы понимал WordPress'овский XML.

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

2Орлангур25-02-2008 20:53

интересно во что вырастет проект =)

3injun #57687126-02-2008 03:55

Я так понял это будет некая мутация на основе MVC? :eek:

4ACID Jesus26-02-2008 15:46

Раз такая работа планируется мощная, как создание cms целым коммунити (ну или даже если для начала небольшой группой) разработчиков, то сделали бы тот же репозиторий cvs с текущей версией кода - так и любой смог бы ознакомиться, ну а избранные и вносить свои изменения... 8-)

5Глобатор27-02-2008 07:30

Буду с нетерпением ждать появления беты.

6Nik28-02-2008 01:18

Думаю, многих здесь присутсвующих волнует вопрос - будет ли конвертер для перехода с WordPress на MaxSite CMS. Проект интересный вырисовывается, и многие наверняка решат перейти. Понятно, что и с основным кодом работы ещё на долго хватит, но всё таки интересно...

7Максим28-02-2008 08:44

Конвертер в планах есть. Как только определимся со структурой своей базы, появится и коневертер. ;)

8krolser28-03-2008 16:04

Вроде бы неплохо вырисовываеться. Но один вопрос. Зачем всё это? Что в этой CMS будет такого, за что я смогу выбрать её из десятка подобных. Не боитесь ли, что после кучи версий и аддонов, апдейтов, вся ваша структура без чёткой документации рухнет или превратиться в месиво?

Хотелось бы увидеть список будущих возможностей.

Кстати, я разарботкик :). Надеюсь не обидел своим комментом.

9Максим28-03-2008 19:00

Ну я бы не рискнул позиционировать свою систему, как противовес WordPress или какой-то другой системе. Полностью согласен - систем очень много и выбор конкретной зависит от массы условностей и предпочтений. Но я стараюсь подойти к этому вопросу с прагматичной точки зрения. Мне не хватает в WordPress'е прежде всего управляемости и легкости. И мне не нужна та масса бирюлек, которыми оброс WordPress. Согласитесь, в WordPress'е серьезный перекос в сторону админки, хотя эта админка видна только самому админу. Поэтому я стараюсь сейчас сделать так, чтобы разработчик получил в свое распоряжение мощный и гибкий инструмент. Скорее всего уровень «вхождения» будет несколько выше, чем у WordPress, потому что я просто физически не смогу охватить все участки работы. Поэтому на первом этапе делается так, чтобы все работало, а красОты оставлю на потом.

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

10krolser28-03-2008 20:05

Я немного не про это. Перечитал свой пост и понял, что немного не на то указал, что хотел.

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

Нужна не дока, а описание будущих возможностей. Не раз наступал на эти грабли. Другим не советую :).

11Максим28-03-2008 20:21

Вот вы о чем. :) Честно говоря даже не знаю, что написать. Какой-то четкой цели нет. Есть потребность и вот это и есть генеральная линия.

Захотел прицепить визуальный редактор - без проблем. Добавляется почти по инструкции. Захотел другой - без проблем. Захотел свою страницу настроек в админке - нет проблем. Пара функций - все работает.

Совсем недавно решил прицепить твиттер. Тьфу делов - три вызова функций. Какой-нибудь рандомтекст (случайные цитаты) - три строчки кода. Lightbox для красоты - весь код с комментариями и красотами - 957 байт.

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

12alex30-03-2008 00:43

Максим, если вы ставите свой целью то, что на примере описали выше, то ваша цель не CMS, не очень то она вырисовывается. Ваша цель тогда - удобное core, которое легко изменить и доработать. ТОгда уж framework. А CMS - это как раз другое, где есть функционал визуальный, для систем управления контентом.

Вообще же отсутствие четких целей ведет к отсутствию текущих задач или их неточности.

13Максим30-03-2008 13:22

А по вашему WordPress как-то по другому делался? ;) Весь функционал вырос из плагинов. Просто я ставлю задачу не усложнять там, где нет особой необходимости. Ну вот свежий пример.

Изменили активацию плагина в WordPress 2.5. Сами плагины рабочие и проблем с ними нет. Но вот из-за глюков с самой активацией плагин включить невозможно. Спрашивается зачем делали? С какой целью проверять «работоспособность» плагина, если задача до безобразия примитивна - поставить отметку «активно»?

Но все таки я не думаю, что это просто фреймворк. Фреймворк - это набор кирпичиков, а CMS - это уже готовое здание. Я делаю здание. :)

14souznik28-05-2008 18:21

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

Максим, а ведь CodeIgniter уже является таким инструментом!

15Максим28-05-2008 18:52

Не согласен. CodeIgniter невозможно использовать в качестве готовой системы. Он просто набор файлов + небольшая модель работы. Для того, чтобы сделать из CodeIgniter что-то действующее, требуется много дописывать своего кода. Попробуйте написать админ-панель на CodeIgniter и вы сразу поймете о чем идет речь.

16souznik28-05-2008 20:51

Попробуйте написать админ-панель на CodeIgniter и вы сразу поймете о чем идет речь

Ты меня не много не понял. CodeIgniter создает пространство для облегчения жизни разработчика. CMS создает пространство для работы контентора. Твою же систему нужно называть CMF - content management framework, что-то вроде Drupala. Мое глубоко субъективное мнение, CodeIgniter нужно использовать для решения специфичных задач. Вообщем вот целый пост на эту тему http://souza.ru/2008/05/pros_and_cons/

17Максим28-05-2008 23:02

Очень глубокая мысль. Я не понял. ;)

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

Комментарий будет опубликован после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

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