Вопросы и ответы по 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 (Роберт Бадретдинов), Илья Рабченок.
Постоянная ссылка: http://maxsite.org/?p=388
Версия для печати
RSS: Вопросы и ответы по MaxSite CMS
