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

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

Архив записейКомментарии: 18Просмотров: 3109

Зачем 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 (Роберт Бадретдинов), Илья Рабченок.

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

1idler11-06-2008 22:50

Я искренне желаю, чтоб со временем, MaxSite CMS стала популярной как wordpress, или даже больше....

2Friend12-06-2008 09:39

Ну что - вышло достаточно интересно и познавательно, а ведь имхо были какие-то нотки неуверенности в сообщении "Можно задать свой вопрос".

Лично я заинтересовался cms и как только покончу с текучкой, хочу поглядеть системку, особенно заинтересовали моменты, связанные с нагрузкой.

Помню, Lecactus воевал с прожорливостью Wordpress на собственном сервачке. Нагрузки были существенные из-за количества работающих плагинов в т.ч. Поглядим, как будут обстоять дела в MaxSite CMS :)

PS. Friend - это не Елена Камышанская :razz:. Просто сайт о батике - это первый сайт, который я сделал на wordpress для своей мамы, которая занимается этим видом творчества, а сам сайт - мое поле для экспериментов над wordpress :)

3art12-06-2008 09:51

стало интересно попробовать maxsite, но ка со временем не очень, но к 1.0 обязательно выкрою (:

4MASTERPLUS.TV12-06-2008 10:24

Огромное спасибо Вам Max за ваши труды и постоянное стремление к совершенству. Убивают высказывания типа: зачем, ведь есть уже CMS, а мне и этого хватает и т.д. Уважаю людей стремящихся изменить мир к лучшему. Жму руку и желаю сбычи мечт! :smile:

5SolarWind12-06-2008 10:31

А вы не смотрели на Drupal? Просто то, что вы пишете про свою CMS, по описаниям очень похоже на Drupal. :-) Ну а так - респект. Своя CMS всегда неплохо.

6Орлангур12-06-2008 13:34

Если быть точным, то это стиль GNU. Читается он несколько легче, чем «рациональный» стиль (стиль языка C), который используется в WordPress.

Оба стиля - стили C ;)

Один Кернигана и Ричи, другой GNU.

http://ru.wikipedia.org/wiki/Стиль_отступов

7Максим12-06-2008 13:59

По стилям см. «PHP5 на примерах» Кузнецова, Симдянова и Голышева.

8Crash12-06-2008 15:20

SolarWind, по Друпалу пое ИМХО - странная структура. Сделал на нем три сайта, столько пришлось мучаться, чтобы просто сделать рубрики... Проще было TYPO3 изучить

9Владимир12-06-2008 18:42

Все-таки приятно, что появляются такие разработки.

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

Вы правильно заметили, что успех WP в основном определяется количеством готовых плагинов и тем. С этим сложно конкурировать, ведь если плагин устраивает пользователя, то ему в большинстве случаев не важно, что при этом потребляется пару лишних мегабайт памяти. Ему проще (и, возможно, дешевле) заплатить на 3-4$/мес больше за хостинг, чем связываться с разработкой собственного решения.

Удачи вам!

10Роман12-06-2008 20:15

Мне кажется, что наиболее удобочитаемый стиль такой:

function replace($sString)
{
if ($sString)
return str_replace('x!', '!x', $sString);
}

То есть, в именах ф-ций строчные буквы, слова разделяются знаком «_». В переменных слова каждое начинается с заглавной буквы, перед именем переменной первая буква типа (a — array, s — string). Табуляция составляет 4 пробела, глобальные переменные такого типа:

$_SUPER_MEGA_GLOBAL_VARIABLE

и константы:

COOL_CONSTANT

:mad:

11SolarWind12-06-2008 21:54

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

12tarusexpert14-06-2008 00:42

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

Кстати, SolarWind, видимо, ты не совсем внимателен, сравнивая это с Друпалом.

13Anton Shevchuk15-06-2008 20:32

Wordpress я бы не причислял к "тяжелым" CMS системам (кто-то говорил о Друпал - так он еще тяжелее), в действительности разработчики не проводят полноценный рефакторинг - у них постоянно растет список умерших функций (deprecated.php), они стараются поддерживать старые плагины, постоянно плодят алиасы - это мрак, да еще и отказываются от PHP5 - как по мне им просто пора вырезать старый функционал - и тогда поживее станет бегать система...

Еще есть чудные плагины - каждый пишет как может, а зачастую могут не многое - сколько раз встречал плагины которые инициализируют все свои файлы и классы и вешаются на админские хуки... :(

P.S. Хочу пожелать Вам успехов в Ваших начинаниях :)

14localisator19-06-2008 12:16

Хотелось бы попросить к этому всему еще и прикрутить одну такую функцию как мультиязычность. Т.к. на сегодня нет ни чего достойного... Если такое планируется - создавайте или копилку или номер кошелька = для такого дела не жалко и простимулировать финансово.

15SolarWind21-06-2008 18:20

localisator, я тут уже упоминал друпал. Вот он как раз уже умеет нормальную мультиязычность. :-)

16Silence27-06-2008 09:41

Было бы очень здорово, если бы была проработана интеграция популярных форумов phpBB3/SMF в CMS. Думаю, это привлечет очень многих.

17ABTOP03-08-2008 21:16

...код это даже не проза - это такой мат.

Вы заметили, что официальный лозунг теперь озвучен по-русски как "Программирование - это искусство"? :mrgreen:

18Бультозавр01-05-2009 12:28

Интересно, что будет с CMS если в неё грузануть порядка 100 плагинов и виджетов каждый из которых выполняет кучу своих операций с БД, получим громадное количество запростов как у друпала =).

Пданируете ли вы какнить с этим бороться? помимо 2х видов кеширования может ещё чтонить придумать =)

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

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

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

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