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

25-02-2008Время чтения ~ 5 мин.Блог 20309

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

Хочу особо подчеркнуть: требуются не тестеры, а разработчики. Потому что тестировать особо нечего. Нужно посмотреть, может быть найти ошибки и может быть взять на себя работу по созданию какого-то админского плагина/страницы и т.д. То есть требуются знания PHP, и очень желательно CodeIgniter. Так, что если вы готовы, то пишите мне на почту - в обратную я вышлю файл с текущей системой. Свои замечания и предложения вы можете выслать мне опять же письмом, а можно через >отдельный форум. Естественно, я беру на себя обязательство объяснить что я понапридумывал в коде. :) Пока же коротко о 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.