MaxSite CMS - первая публичная версия
Как и обещал, выкладываю первую публичную версию своей системы. Хочу сразу предупредить, что система еще не завершена - это просто текущая рабочая версия (0.15), которую буду еще доделывать (релиз - это версия 1.0).
Впрочем эта версия вполне работоспособна и если закрыть глаза не некоторые нереализованные вещи, можно сказать, что на ней можно сделать вполне нормальный сайт.
Установка системы довольно проста. Все шаги подробно описаны в файле install-ru.txt. Читайте и всё будет нормально.
Плагины
Для того, чтобы расширить функциональность системы, используются плагины. Что такое плагины, я думаю, объяснять не нужно. Установка плагина сводится к нескольким простым действиям:
- Скопировать файлы в каталог плагинов
- В админ-панели активировать его
Некоторые плагины требуется явно прописывать в шаблоне, поэтому есть смысл почитать описание его разработчика.
Технически плагины представляют собой обычные php-файлы, которые подключаются в момент инициализации системы. По этой причине плагином можно сделать практически любой сторонний php-скрипт. Всё, что требуется для его модернизации - это указать правильное именование функций (см. правила).
Учитывая свой опыт создания плагинов для WordPress (где существует изрядный бардак), я решил разработать несколько несложных правил, которых должны придерживаться все разработчики плагинов. А для того, чтобы облегчить сей труд, в комплекте с дистрибутивом будет поставляться несколько заготовок для новых плагинов.
Правильные последние комментарии
Не секрет, что обычно блок последних комментариев мало кто читает. Всё дело в том, что комментарии выводятся одной лентой, где в перемешку идут разные записи. Кроме этого, обычно они располагаются по принципу: более новые вверху. То есть такой блок просто не удобно читать.
Я решил немного отступить от этой традиции и предложить другой вид последних комментариев, где они группируются по записям и выводятся в прямом порядке.
В общем смотрите блок «Обсуждения».
Дефолтный шаблон в MaxSite CMS
Поскольку скоро я выложу на всеобщее обозрение первую публичную рабочую версию своей системы, то решил в последние дни более плотно заняться дефолтный шаблоном.
На самом деле это очень важная часть любой CMS. Такой шаблон должен решить две задачи. Во-первых он должен показать пользователю на что способна система. То есть пользователь выполнил только установку и еще не разбирается во всех тонкостях (и это естественно), но уже на этом этапе должен получить нечто рабочее и похожее на конечный продукт. Здесь конечно же следует обратить внимание на дизайн. Если бы разработчики систем придавали бы этому вопросу большее значение, то наверное их истемы были более популярны. Для примера можно взять тот же CodeIgniter или CakePHP. С таким дефолтным шаблоном первое впечатление создается более чем тягостное.
Непонятные проблемы...
Что-то явно не так в CodeIgniter. Столкнулся с серьезной проблемой, которую так и не могу побороть. Дело в XmlRPC, хотя я думаю, что в каких-то ситуациях дело не только в этой библиотеке. Скорее всего существует ошибка при подключении разных классов в основном контролере. То есть когда я в основном контролере передаю управление во вьювер, то в этом вьювере, при условии, что должен подключиться еще один класс (через new), начинают твориться странные вещи.
Я уже писал, что не смог перейти на 1.6.2 из-за того, что XmlRPC вдруг перестала видеть базу данных. Все попытки вручную её прописать, все равно не срабатывают - в основном контролере она есть и дальше, хоть тресни, не видно.
Сегодня столкнулся с аналогичной проблемой, только на другом хостинге. XmlRPC опять напрочь отказывается работать. И опять проблема с подключением классов. На сей раз вылезает ошибка:
- Fatal error: Cannot redeclare class ci_session in /.../system/libraries/Session.php on line 0
При этом если прописать библиотеку в автозагрузку, никакого эффекта. Поэтому пришлось отключить автозагрузку и прописать подключение библиотек вручную. При этом, что интересно, хотя в основном контролере все прописано, а в XmlRPC стоит и «parent::Controller();» и «$CI = & get_instance();» (и каких только вариантов я не перепробовал), все равно происходит какая-то ошибка и база опять отваливается.
Впрочем есть у меня предположение, что дело здесь вовсе не в CodeIgniter и моих кривых ручках, а самом хостинге. Проблема возникает на хостинге с PHP 4.4.8. На локальной машине и на другом хостинге, где стоит PHP 5.2 подобных проблем не наблюдается.
Собственные опции шаблона
Как я уже писал, опции я реализовал в виде ini-файла. Основные преимущества такого подхода в том, что можно с помощью простого ini-файла создать или поменять любые настройки сайта. То есть вместо «вшивания» настроек в «движок» мы выносим их в отдельный описательный файл.
Точно такой же способ я реализовал и для настройки шаблона. Попробую объяснить что я хотел добиться на примере WordPress.
Для примера можно рассмотреть такую настройку как количество записей для вывода на главной. В WordPress данная опция определена в самой админке. Кажется, что все логично, но предположим я хочу выводить разное количество записей для главной и для страницы рубрик. Что делать? В WordPress нужно лезть в шаблон и прописывать query_posts(). Согласитесь, малоэлегантное решение.
Кэширование в MaxSite CMS
Основной способ борьбы с высокой нагрузкой ложится на кэширование. Именно за счет кэширования достигается максимальная разгрузка сервера. Для проектов с небольшой посещаемостью кэширование может вовсе не понадобится. А вот для более-менее посещаемых, использование кэша вполне оправданно. По моим прикидкам кэширование есть смысл использовать для сайтов от 100-200 хостов в день. Во всяком случае при такой посещаемости кэш обновляется не чаще, чем это будет требоваться.
В своей системе я максимально использую кеширование. Но трудность кэширования в том, что нельзя кэшировать всю страницу, поскольку какие-то блоки всегда должны быть уникальны. Например вывод случайных цитат. Поэтому в большинстве случаев я использую «локальное» кеширование.
Опции в MaxSite CMS
На днях я доделал опции. Вы наверное удивитесь, посколько опции (или настройки) являются ключевым узлом любой системы. Нет, конечно какие-то минимальные настройки изначально присутствовали, но цельного механизма еще не было.
Дело в том, что опции сами по себе очень сложный механизм. Прежде всего из-за их крайней негибкости. Я приведу в качестве примера WordPress.
В нем предусмотрены настройки, вроде адреса админа, титула, описания, временной зоны и т.п. Все эти опции жестко прописаны не только в шаблоне, но и в базе данных (имеется ввиду обновления, установка). В принципе всё нормально, за исключением одной мелочи: практически нереально предусмотреть свои варианты.
Ну предположим, мне хотелось бы внести опцию для ключевых слов (meta description). Никакого «легального» способа добавить эту настройку в WordPress нет. В самом лучшем случае вы сделаете это через отдельный плагин.
Другой пример - мета-поля в записях/страницах. Мне бы хотелось сделать отдельное поле для ключевых слов для любой страницы. Для этого можно завести мета-поле и в нем уже указывать нужное значение. Конечно же это потребует программировать шаблон, но в целом задача решаема.
Проблема здесь только в том, что метаполя в WordPress очень неудобно реализованы. Хотя что мешает сделать их в виде, аналогичном, скажем выбору рубрик?
