Вопросы и ответы по MaxSite CMS

Зачем MaxSite CMS?

Действительно, на сегодняшний день недостатка в CMS нет. Счет наверное уже на тысячи. И всё-таки я решился на создание своей. Причин несколько:

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

Чем не уcтраивает WordPress?

Что касается самого WordPress, то признаться мне уже просто надоело в нём «вариться». За несколько лет для меня наверное не осталось никаких его «секретов». Когда я начинал работать с WordPress, то меня привлекла прежде всего возможность использовать обычный PHP: я знал PHP, но не знал WordPress. Через год, когда WordPress уже не являлся для меня «тайной», я однажды словил себя на том, что не могу решить какую-то задачу, потому что в самом WordPress'е не было необходимой функции. И тут я сказал себе: «Стоп!». Как-то так незаметно получилось, что я невольно стал мыслить рамками самого WordPress и всё, что было за ними, ускользало из моего поля зрения. А ведь задача элементарно решалась на обычном PHP.

Тогда-то я и задумался более серьезно над тем, что WordPress несет слишком много ограничений и их нужно как-то убирать. Я рассказывал вам о шаблоне Rioni, где заложена модель «идеального» шаблона. В то время я серьезно занимался тем, чтобы заставить WordPress выдавать только те данные, которые действительно необходимы (WordPress as CMS). Тогда же я придумал «локальное» и «глобальное» кэширование. Для клиентов я разработал много виджетов, плагинов и функций. Но во всех этих разработках я постоянно сталкивался с ограничениями самого WordPress - его архитектура просто не позволяет как-то гибко управлять данными.

Ну и одна из главных проблем - это излишнаяя прожорливость WordPress. Я слышал много высказываний, что дескать это даже не проблема WordPress, а проблема хостинга. Позволю себе не согласиться. Конечно, хостинги сейчас предоставляют более чем приемлемые условия, но если задуматься и попытаться понять откуда в WordPress такое потребление ресурсов, то мы придем к неутешительным выводам. Дело в том, что в WordPress'е грузятся почти все библиотеки и файлы, независимо ни от чего для всех запросов (см. wp-settings.php). Когда я более плотно с этим стал разбираться, то пришел к выводу, что в WordPress'е неверно организованы файлы. Функции в файлах группируются по их «тематической» функциональности. Например в formatting.php все функции по форматированию текстов. Может это было бы и неплохо, но если заглянуть внутрь, то увидим массу функций, которые либо вовсе не используются, либо крайне редко. Какой в них тогда смысл?

С точки же зрения правильной архитектуры, необходимо вынести в один файл те функции, без которых система не может функционировать. То есть система при загрузке должна загружать только один (по возможности) файл - «ядро» системы. Остальное загружается при необходимости. То есть разработчики WordPress особо не утруждали себя таким анализом, а просто прописали подключение всех файлов. Вот вам и требование в 32Мб. :)

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

В общем WordPress меня действительно не устраивает по многим причинам. Правда всё-таки следует отметить, что для нетребовательного клиента он более чем подходит. Во-первых, у WordPress красивая админка. Во-вторых, к WordPress множество шаблонов. В третьих, к нему много плагинов. И в четвертых, у него большая поддержка со стороны wp-специалистов. Что же касается описанных недостатоков, то для 90% они решаются путем перехода на более дорогой тарифный пакет хостинга. :)

Почему за основу был взят фреймворк CodeIgniter?

Дело в том, что MaxSite CMS не первая система, которую я делаю. Думаю, что с десяток CMS всё-таки наберется. Конечно же они были разные, под разные задачи, но главное, что сам процесс создания CMS я представляю довольно неплохо.

Именно поэтому в начале работы необходимо сразу определиться с «каркасом», на основе которого и будет строиться система. Наверное можно было бы самому написать нужные библиотеки, например для работы с БД, но как я понял, можно взять и сторонюю разработку. Благо к этом времени появились довольно неплохие framework'и, которые изначально содержат необходимый функционал.

Здесь я бы хотел объяснить что фреймворк это всего лишь набор функций/библиотек. То есть чтобы получить готовую систему необходимо создать свою структуру данных, управление ими и т.д. И вот здесь функции фреймворка как раз и подойдут. Это как кирпичи, которые можно использовать по своему усмотрению.

Следует отметить, что обычно фреймворки содержат и свой API, который позволяет «склеивать» кирпичики. Также фреймворк выполняет некоторый начальный код, который инициализирует систему, а дальше управление передается вашим функциям.

И вот здесь главный момент: некоторые фреймворки «заставляют» строго следовать своей «идеологии» (API), а некоторые допускают «вольности». CodeIgniter как раз относится ко вторым. Например, используемый принцип MVC (модель-отображение-контролер) хоть и заявлен, как основополагающий, совершенно не требует строгого соблюдения. Поэтому я волен выбирать ровно ту архитектуру, которая меня устроит.

То, что в CodeIgniter входит масса библиотек, делает программирование CMS гораздо проще и удобней: вместо «изобретения велосипеда» я просто использую готовую библиотеку или хелпер. Правда всё-таки в CodeIgniter есть проблемы и я с ними уже столкнулся, когда обновлял свою систему на новую версию. Поэтому насколько я буду пользоваться CodeIgniter зависит от его развития. Если возникнут какие-то проблемы, то я просто «откачусь» на предыдущую версию CodeIgniter. Благо текущего функционала более чем достаточно.

Основы MaxSite CMS

Во главу угла я сразу поставил несколько принципов.

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

- Несложные шаблоны. В целом мне нравятся WordPress-шаблоны, точнее их идея. Это обычный PHP, который выводит полученные данные. Проще и не придумаешь. Правда в отличие от WordPress, я не стал вводить лишние функции-замены (т.н. цикл The Loop), а использую обычный PHP. Схема же самого шаблона совсем простая: по-идее достаточно всего одного файла index.php в котором получаются и выводятся данные. Но если говорить о шаблоне default, то в нем проверяется тип данных (рубрики, страницы, метки и т.д) и подключается соответствующий файл (имя произвольно). Я думаю, что шаблоны для MaxSite CMS не сложней WordPress'овских.

- Несложные плагины. Мне совершенно не нравится система плагинов WordPress. Во-первых в них полный бардак: это могут быть любые файлы с любыми именами и функциями. Во-вторых мне не нравится их внутренняя структура - например отсутствие функций для удаления, uninstall или активации. Если строго, то их можно придумать, но только через хуки (hooks, action). В третьих мне не нравится как сделано их подключение и отключение. Поэтому я сделал всё наоборот. Во-первых, у меня все плагины должны строго быть в своем каталоге, а функции плагина должны именоваться по единым правилам. Во-вторых, у меня предусмотрены функции для удаления, деактивации, активации плагинов. В третьих, у меня можно включить/отключить плагины выборочно, просто отметив нужные.

- Несложные виджеты. С виджетами я долго бился - сказался опыт WordPress. :) В результате виджеты в MaxSite CMS делаются до безобразия просто. В любом плагине можно вынести настройки в виджет. Самих виджетов одного плагина может быть сколько угодно. Для виджетов предусмотрено несколько функций, которые выполнят всю черновую работу: отображение формы настроек и их обновление. Для конечного же пользователя настройка виджетов выглядит так: вначале нужно указать какие виджеты разместить в сайдбарах, после этого настроить каждый виджет.

- Несложная структура админ-панели. Тут «фишка» в том, что в MaxSite CMS админ-панель состоит из очень небольшого набора функций (ок. 11Кб) и очень маленького темплейта (ок. 8Кб, включая css и картинки). Секрет в том, что функции админ-панели это обычные плагины. Правда для удобства они расположены в отдельном каталоге и для них не требуется активация (вручную прописана). Таким образом для плагинов админ-панели используется тот же функционал, что и для обычных плагинов. С равным успехом можно создать страницу плагина в админ-панели. Что же касается шаблона админ-панели, то в нем используются всего четыре блока (div): заголовок, меню, блок плагина, подвал. То есть даже просто изменяя стили css-файла можно менять внешний вид админ-панели. По сравнению с WordPress, где изменение внешнего вида админ-панели большая проблема, у меня это элементарное действие.

Насколько MaxSite CMS подходит оптимизаторам?

Обычно для сайтов под этим подразумевают настройку title, description и keywords. Если это так, то они уже предусмотрены. Если же нужно предусмотреть какие-то другие опции для страниц, то они очень просто задаются в ini-файле. Правда как имено их использовать будет зависеть уже от шаблона.

В планах стоит создание плагина для отправки пинга на ping-сервисы.

Насколько сложно настроить MaxSite CMS под свою задачу?

Думаю, что проще, чем с WordPress. ;) Я хочу сразу сказать, что нисколько не позиционирую свою систему под «кухарок». Нужны какие-то знания PHP, чтобы уметь правильно задать настройки и написать свои функции. Задачи можно решать самые разные. Как я уже сказал, в моей системе управление передается в шаблон. Что дальше делать - решает сам разработчик. В дефолтном шаблоне я продемонстрировал, что сайт способен работать так же как и WordPress, то есть в режиме блога. Если нужно выводить данные как-то по другому, то решается это двумя путями: а) если структура данных БД таже, то достаточно ввести свои настройки и учитывать их при получении данных для вывода; б) написать свою функцию получения данных и вывести их как нужно.

Насколько MaxSite CMS расчитана на большую нагрузку/посещаемость?

На сайте я уже описывал эту проблему. Если кратко, то да, расчитана. Делается это с помощью кэширования. Доступны два уровня «локальный» и «глобальный». «Локальный» - это кэширование целой функции (или её части). То есть вместо её выполнения получается готовый результат из кэша. «Глобальный» - это кэширование готовой страницы (по её url). Первый - более гибкий способ и позволяет выполнять кэширование выборочно и таким образом можно добиться многократного снижения нагрузки. Во-втором случае можно снизить нагрузку еще больше - до нуля запросов к БД. Проблемой «глобального» кэширования является то, что не будут работать изменяемые данные, например случайные цитаты, а также бОльшие затраты места на диске, поскольку в кэш записываются целые страницы.

В самой системе кэширование используется очень активно. Я бы даже сказал, что это её составная часть.

Насколько сложно переделать шаблон WordPress под MaxSite CMS?

Тут сложный вопрос. Лично я уже давно не использую готовые шаблоны WordPress. Даже если он есть и готов к использованию, то я беру от него только сам дизайн. Весь внутренний код удаляется начисто. Поэтому, если вопрос подразумевает использование WordPress-шаблона в качестве готового варианта, то вынужден разочаровать - скорее всего придется все переделывать. Если же имеется ввиду переделать только дизайн, то это будет не очень сложно: главное в таком шаблоне выделить блоки сайдбара и вывода текстов. Остальное - практически оригинальный html.

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

Можно ли сделать каталог или модуль для электронной коммерции на MaxSite CMS?

У меня в планах не стоит. Технически же я думаю, что можно интегрировать подобные решения. Поскольку MaxSite CMS поддерживает множество типов данных, а также позволяет без труда создавать свои, то я не вижу проблем. Другое дело, что такие системы сложны сами по себе, поэтому видимо потребуют дополнительного программирования.

Создавая CMS вы предпочитаете руководствоваться ООП принципами или процедурными?

Если бы мы говорили о программировании под Windows, то конечно ООП. Прежде всего по той причине, что это удобно и быстро. Ели же говорить о PHP, то всё не так однозначно. Если мне нужно написать функцию, которая принимает и обрабатывает какие-то данные, то смысла городить для неё классы я не вижу. Поэтому использование ООП в PHP имеет смысл только в тех случаях, когда реально будут создаваться классы (наследование) или где это необходимо по определению (как в CodeIgniter). А так я сторонник более простого подхода. В большинстве случаев он ничем не хуже, да и к тому же нет проблем с совместимостью между PHP4 и PHP5.

Почему такое название: MaxSite?

Название возникло спонтанно, без каких-либо обсуждений и скорее как рабочий вариант. Мне уже много раз предлагали назвать MaxPress, но мне не хочется иметь ассоциации с WordPress. Другие варианта со словом «max» не сильно отличаются от текущего, поэтому не вижу смысла что-то менять. Другое дело использовать что-то совсем нейтральное, например название горы, реки, звезды и т.д., но пока каких-то приемлемых вариантов я не встречал. Впрочем, этому вопросу я особого внимания еще не уделял. :)

Лицензия MaxSite CMS

Тут все просто - GPL-2. Я не стал особо мудрить - многие проекты делаются именно под этой лицензией и не доверять их выбору у меня нет оснований. Я конечно же расчитываю, что на каком-то этапе к проекту подключатся программисты, особенно по CodeIgniter, но пока я всё делаю самостоятельно. Собственно именно по этой причине я и не могу точно сказать о сроках - иногда нужно и деньги зарабатывать. ;)

Поддержка WordPress будет уходить на второй план?

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

Если код - это поэзия, считаете ли вы себя интересным, или хотя бы заслуживающим внимания, поэтом?

Нет, конечно. :) Я бы сказал, что код это даже не проза - это такой мат. Причем трех,-четрырехэтажный. Сейчас программы имеют исходники в сотни килобайт и разобраться в этом мессиве кода довольно тяжело. Если я не прокомментирую код, то уже через месяц могу просто не вспомнить для чего он предназначен. Поэтому код должен обильно комментироваться и быть удобочитаемым. Тут уж не до поэзии. :) Кстати мне нравится стиль кодирования CodeIgniter. Если быть точным, то это стиль GNU. Читается он несколько легче, чем «рациональный» стиль (стиль языка C), который используется в WordPress. Впрочем это всего лишь субъективные предпочтения. :)

Дальнейшее развитие MaxSite CMS

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

Вторая задача - расширять функционал. В перспективе я бы хотел добиться такого, чтобы было всё равно на чем делать блог: WordPress или MaxSite CMS. Визуально этого добиться несложно, а вот по функционалу еще предстоит много работы.

Третья задача - изучить реальные потребности. Тут я действую своим проверенным способом: делать сайты и добавлять то, что нужно клиентам. Если кто-то думает, что этот список может быть бесконечен, ошибается. Когда я делал виджеты для WordPress, то убедился на практике, что 20-30 виджетов с лихвой перекрывают 99% потребностей клиентов. Думаю, что здесь порядок цифр будет тот же. ;)

Четвертая задача - делать хелп. Нюанс в том, что текущая версия всего лишь 0.15 и до релиза (1.0) пока далеко. Поэтому многие описания могут запросто измениться и придется следить еще и за их соответствием. Впрочем хелп будет в любом случае.

ps С вопросами помогали: Friend, vladname (Владислав), m0nah (Голубев Евгений), SeoNub, Артем, Стаценко Владимир, Алексей Саминский, Feelov, Shas, ABTOP, Владимира Лапшина, Provadd (Вадим), robert (Роберт Бадретдинов), Илья Рабченок.