Новый движок — MaxSite CMS

Владимир | | Web разработка, Разное.

MaxSite CMS
Наверное, многие слышали о новой системе управления контентом – MaxSite CMS. Ее разработкой занимается Максим, автор небезызвестного блога — maxsite.org. Система имеет ряд очень интересных возможностей и при этом потребляет совсем немного системных ресурсов. В общем, заслуживает самого пристального внимания, и я хочу поделиться своими впечатлениями.

Начнем с установки и настройки.

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

Первый касается настроек PHP. У вас в php.ini должны быть включены:

short_open_tag = On
allow_call_time_pass_reference = On

На мой взгляд, можно было бы отменить эти требования.

Второй касается базы данных. Дело в том, что если ваш сервер MySQL по-умолчанию использует InnoDB, то вы получите ошибку при попытке создания таблицы mso_page, т.к. для трех полей этой таблицы включен полнотекстный (FULLTEXT) поиск, а InnoDB его не поддерживает. Чтобы исправить ситуацию, открываем файл application/views/install/model.sql и явно указываем тип движка (строка 219):
) _CHARSETCOLLATE_ ENGINE=MYISAM;

Хочу сразу отметить, что эти замечания нельзя считать недостатками хотя бы потому, что текущая версия имеет номер 0.16 и находится в состоянии тестирования.

Переходим к использованию.

Сразу после установки вы получите систему управления блогом, т.е. сможете создавать посты, страницы, рубрики и т.п. Но возможности MaxSite CMS блогом не ограничиваются. Вы можете создавать любые типы страниц для любых целей, просто по-умолчанию их два (blog и static). Естественно, если вы создаете новый тип, то придется внести соответствующие изменения в шаблон.

Вообще интерфейс админ-панели довольно простой и удобный. «Лазить» по меню практически не приходится. Все на русском языке. Правда, подписи к кнопкам визуального редактора на английском. Но иконки стандартные и вряд ли у кого-то возникнут сложности при его использовании. И не понятно, почему в окнах вставки ссылок и картинок надписи на испанском 🙂 .

Теперь самое интересное. Создание собственных шаблонов. На эту тему Максим уже написал три лекции (надеюсь, это только начало 🙂 ).

Пересказывать их я не буду, только остановлюсь на паре моментов.

Во-первых, создание шаблона для MaxSite CMS не сложнее чем для WordPress. Наверное, даже проще, т.к. используется меньше встроенных функций. Например, подключения файлов шаблона используется require, а не get_footer() и т.п.

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

В-третьих, использовать готовые шаблоны для WordPress (или других CMS) не получится. Т.е. из них можно взять только дизайн.

В общем, если вы хотите создать шаблон для MaxSite CMS на основе существующего для WordPress, то, на мой взгляд, проще всего использовать такую схему.

1) Установить WordPress и активировать нужную тему.
2) Открыть страницу сайта в режиме html. Т.е. вы получите сверстанную страницу.
3) Установить MaxSite CMS и скопировать дефолтный шаблон в новую папку (/application/maxsite/templates/имя_шаблона).
4) Скопировать файл с таблицей стилей styles.css.
5) Посмотреть какие файлы дефолтного шаблона будете использовать, и изменить разметку в них.
6) Добавить собственные файлы в шаблон (если они нужны).

Как видите, процесс достаточно простой.

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

С шаблоном тоже ничего сложного. Многие названия говорят сами за себя. Например, посмотрите функцию getinfo (файл application/maxsite/common/common.php). Вряд ли вам потребуется подробное описание параметров 🙂

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

В заключение, пару слов о потреблении ресурсов. Это одно из самых больших преимуществ MaxSite CMS. В базовом варианте (с отключенными плагинами) система потребляет около 3 МБ памяти. Для сравнения, WordPress вообще не запускается при ограничении в 8 МБ, а для нормальной работы с этим движком нужно 16-32 МБ.

Кроме того, MaxSite CMS поддерживает кэширование. Это позволяет существенно сократить количество запросов к БД и снизить нагрузку (правда, за счет свободного места на диске).

В общем, я всем советую поработать с этим движком. Несмотря на то, что релиз еще не вышел, и некоторые моменты нуждаются в доработке, система работает стабильно. «Глюков» я не видел (может плохо искал? 🙂 ). А если вас не устраивает потребление ресурсов WordPress, то MaxSite CMS может стать реальной альтернативой.

Так что, пожелаем Максиму удачи!

  • В WordPress тоже есть встроенное кеширование, и даже в 2.5 его можно вернуть. Вот тут я про это пишу — http://www.chanishvili.org/wp-cache251/

    А cms от макса пока всетаки сыровата.

    • Да, согласен. Кстати, кэширование в WP не только встроенное, есть еще спец. плагины. Где-то даже видел анализ их эффективности.

      Просто я хотел отметить, что автор с самого начала уделяет много внимания производительности.

      >> А cms от макса пока всетаки сыровата.
      Да, сыровата, но блог max-3000.com на ней вроде работает нормально.

      • >>Кстати, кэширование в WP не только встроенное, есть еще спец. плагины.
        Только с ними больше проблем чем выгоды 🙁

        >>Да, сыровата, но блог max-3000.com на ней вроде работает нормально.
        Ну еще бы у разработчика не работало 🙂 Я имел в виду что нет wp легкости — что любой чайник освоивший копирование через фтп поставить может 🙂 Хотя это наверно больше плюс а не минус.

        • >> Только с ними больше проблем чем выгоды

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

          >> Ну еще бы у разработчика не работало

          У меня на локалке тоже нормально работало 🙂

  • В WordPress тоже есть встроенное кеширование, и даже в 2.5 его можно вернуть. Вот тут я про это пишу — http://www.chanishvili.org/wp-cache251/

    А cms от макса пока всетаки сыровата.

    • Да, согласен. Кстати, кэширование в WP не только встроенное, есть еще спец. плагины. Где-то даже видел анализ их эффективности.

      Просто я хотел отметить, что автор с самого начала уделяет много внимания производительности.

      >> А cms от макса пока всетаки сыровата.
      Да, сыровата, но блог max-3000.com на ней вроде работает нормально.

      • >>Кстати, кэширование в WP не только встроенное, есть еще спец. плагины.
        Только с ними больше проблем чем выгоды 🙁

        >>Да, сыровата, но блог max-3000.com на ней вроде работает нормально.
        Ну еще бы у разработчика не работало 🙂 Я имел в виду что нет wp легкости — что любой чайник освоивший копирование через фтп поставить может 🙂 Хотя это наверно больше плюс а не минус.

        • >> Только с ними больше проблем чем выгоды

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

          >> Ну еще бы у разработчика не работало

          У меня на локалке тоже нормально работало 🙂

  • MAX

    Спасибо за обзор!

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

    Роланд, вы лишь отчасти правы. Кэш есть, но в памяти. Ну хорошо, подключите вы старый файловый, а будущей версии WordPress опять что-нибудь придумают, что опять приведет к проблемам. Вообще зачем было лишать систему файлового кэша?

    Сейчас кэш еще больше требовать памяти, то есть сняли запрос в БД, но увеличили потребление памяти. Я вот смотрю статистику на своем сервере и вижу, что именно память является критическим элементом, а не обращение к файлам. Так что все не так просто.

    • >>Кэш есть, но в памяти.
      И что полезного кешится в памяти кроме wpvsc_options?

      Для моих задач (хранение различных топов, которые кушают много запросов, но меняются раз в день или раз в неделю, например http://www.kaak.ru/top100/ ) был нужен именно файловый кеш с большим временем жизни.

      >>Ну хорошо, подключите вы старый файловый, а будущей версии WordPress опять что-нибудь придумают, что опять приведет к проблемам.
      Вот когда придумают — тогда и будем решать, счас боятся еще рано 🙂
      Хотя сильно менять интерфейс ближайшие пару-тройку версий никто не будет — совместимость со старыми версиями всетаки нужно сохранять.

      >>Вообще зачем было лишать систему файлового кэша?
      Вот уж не ко мне вопрос 🙂 Может в 2.6 вернули, я бетки пока не смотрел

      • MAX

        Кешируется не только опции, но и ряд запросов, а также данных юзеров. То что в WordPress кэш используется не очень толково — проблема. Тем более, что многие авторы плагинов вообще никак не использует даже существующие возможности. Часто вставляют запросы в циклы, а это порождает огромное количество запросов. Да и вообще дело даже не в запросах как таковых. Кэш позволяет значительно уменьшить и скорость и время выполнение сложных кусков кода. На одном из сайтов (на MaxSite CMS) мне нужно было сделать вывод объявлений (типа каталога). Без кэша было примерно 150 запросов, причем там много циклов и всяких анализов. Просто закешировав результат получил 0 запросов и время выполнения уменьшилось на порядок.

        • Вообще эффективность кэширования сильно зависит от конкретного сайта (и посещаемости).
          Насколько я знаю, универсального решения, которое во всех случаях давало бы хороший результат не существует. А разработчики WP ориентируются на «средний» блог и, может быть, на некоторые популярные плагины.
          Кстати, возможно из-за них и убрали кэш из WP2.5.
          Может, считают, что если кэширование реально нужно (посещаемый блог), то владелец решит проблему (установит плагин, поиграется с настройками, сравнит скорость работы), а при низкой нагрузке выгода от кэширования мизерная.

        • Владимир, в общем — тут все сходятся во мнении, но спорят из-за формулировок 🙂 вп-кеш и супер кеш я тестил, они просто переводя

          Мах, полностью согласен что дело в кривых ручках. А пока будем ждать — более толковой реализации, или более удобно cms 🙂
          А насчет сотен запросов — показательный пример дагон сайтмап, когда я его в последний раз видел плаг выжрал около 300 запросов, и никак их не закешил. За что и был безжалостно убит.

  • MAX

    Спасибо за обзор!

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

    Роланд, вы лишь отчасти правы. Кэш есть, но в памяти. Ну хорошо, подключите вы старый файловый, а будущей версии WordPress опять что-нибудь придумают, что опять приведет к проблемам. Вообще зачем было лишать систему файлового кэша?

    Сейчас кэш еще больше требовать памяти, то есть сняли запрос в БД, но увеличили потребление памяти. Я вот смотрю статистику на своем сервере и вижу, что именно память является критическим элементом, а не обращение к файлам. Так что все не так просто.

    • >>Кэш есть, но в памяти.
      И что полезного кешится в памяти кроме wpvsc_options?

      Для моих задач (хранение различных топов, которые кушают много запросов, но меняются раз в день или раз в неделю, например http://www.kaak.ru/top100/ ) был нужен именно файловый кеш с большим временем жизни.

      >>Ну хорошо, подключите вы старый файловый, а будущей версии WordPress опять что-нибудь придумают, что опять приведет к проблемам.
      Вот когда придумают — тогда и будем решать, счас боятся еще рано 🙂
      Хотя сильно менять интерфейс ближайшие пару-тройку версий никто не будет — совместимость со старыми версиями всетаки нужно сохранять.

      >>Вообще зачем было лишать систему файлового кэша?
      Вот уж не ко мне вопрос 🙂 Может в 2.6 вернули, я бетки пока не смотрел

      • MAX

        Кешируется не только опции, но и ряд запросов, а также данных юзеров. То что в WordPress кэш используется не очень толково — проблема. Тем более, что многие авторы плагинов вообще никак не использует даже существующие возможности. Часто вставляют запросы в циклы, а это порождает огромное количество запросов. Да и вообще дело даже не в запросах как таковых. Кэш позволяет значительно уменьшить и скорость и время выполнение сложных кусков кода. На одном из сайтов (на MaxSite CMS) мне нужно было сделать вывод объявлений (типа каталога). Без кэша было примерно 150 запросов, причем там много циклов и всяких анализов. Просто закешировав результат получил 0 запросов и время выполнения уменьшилось на порядок.

        • Вообще эффективность кэширования сильно зависит от конкретного сайта (и посещаемости).
          Насколько я знаю, универсального решения, которое во всех случаях давало бы хороший результат не существует. А разработчики WP ориентируются на «средний» блог и, может быть, на некоторые популярные плагины.
          Кстати, возможно из-за них и убрали кэш из WP2.5.
          Может, считают, что если кэширование реально нужно (посещаемый блог), то владелец решит проблему (установит плагин, поиграется с настройками, сравнит скорость работы), а при низкой нагрузке выгода от кэширования мизерная.

        • Владимир, в общем — тут все сходятся во мнении, но спорят из-за формулировок 🙂 вп-кеш и супер кеш я тестил, они просто переводя

          Мах, полностью согласен что дело в кривых ручках. А пока будем ждать — более толковой реализации, или более удобно cms 🙂
          А насчет сотен запросов — показательный пример дагон сайтмап, когда я его в последний раз видел плаг выжрал около 300 запросов, и никак их не закешил. За что и был безжалостно убит.

  • Лично я с удовольствием перешл бы на движок от Макса.

    Так что ждем реализации функции импорта из ВП. Тогда перейду даже не задумываясь 🙂

  • Лично я с удовольствием перешл бы на движок от Макса.

    Так что ждем реализации функции импорта из ВП. Тогда перейду даже не задумываясь 🙂

  • Хороший блог, много интересного.

  • Хороший блог, много интересного.

  • Хм, спасибо за сведения — тоже присмотрюсь к этой системе.

  • Хм, спасибо за сведения — тоже присмотрюсь к этой системе.

  • Кстати, возможно из-за них и убрали кэш из WP2.5.

    Да не убрали, а перенесли в память. То то я понять долго не мог, почему настроек кеша нет.

    а при низкой нагрузке выгода от кэширования мизерная.

    А почему и не кешировать при малой посещаемости?
    Настроить кеш, как нужно, и нагрузка поменьше, оно вам надо хостинг лишний раз рвать.

    • Для меня кеш в памяти — все равно что нету.

    • >> оно вам надо хостинг лишний раз рвать

      Сама операция кэширования тоже ресурсы потребляет. А кэш место занимает. Поэтому при маленькой посещаемости еще не известно в каком случае нагрузка меньше будет.
      Лучше всего, конечно, потестировать оба варианта и выбрать подходящий.

  • Кстати, возможно из-за них и убрали кэш из WP2.5.

    Да не убрали, а перенесли в память. То то я понять долго не мог, почему настроек кеша нет.

    а при низкой нагрузке выгода от кэширования мизерная.

    А почему и не кешировать при малой посещаемости?
    Настроить кеш, как нужно, и нагрузка поменьше, оно вам надо хостинг лишний раз рвать.

    • Для меня кеш в памяти — все равно что нету.

    • >> оно вам надо хостинг лишний раз рвать

      Сама операция кэширования тоже ресурсы потребляет. А кэш место занимает. Поэтому при маленькой посещаемости еще не известно в каком случае нагрузка меньше будет.
      Лучше всего, конечно, потестировать оба варианта и выбрать подходящий.

  • Большое спасибо за обзорную статью, обязательно потестим:)!

  • Большое спасибо за обзорную статью, обязательно потестим:)!

  • Полезный обзор, спасибо.
    Насчет сыроватости движка — ну да, пока идет работа ) Что интересно, был у меня сайт на WP, теперь вот на MaxSite блогчик, на WP возвращаться не тянет, даже не могу внятно сказать — почему. Это наверное сложное колдунство 😉 Вроде и плагинов в WP море полезных и шаблонов завались.. а вот не тянет.

  • Полезный обзор, спасибо.
    Насчет сыроватости движка — ну да, пока идет работа ) Что интересно, был у меня сайт на WP, теперь вот на MaxSite блогчик, на WP возвращаться не тянет, даже не могу внятно сказать — почему. Это наверное сложное колдунство 😉 Вроде и плагинов в WP море полезных и шаблонов завались.. а вот не тянет.

  • Владимир,спасибо за комментарий на мой отзыв о движке! 🙂 У вас действительно немного другой ракурс обзора и информация уже местами обновилась.

    • Пожалуйста 🙂
      Проблема в том, что с MaxSite CMS я только экспериментировал, в основном по лекциям на сайте Максима, в коде особенно не ковырялся. Поэтому и статья у меня обзорная.

  • Владимир,спасибо за комментарий на мой отзыв о движке! 🙂 У вас действительно немного другой ракурс обзора и информация уже местами обновилась.

    • Пожалуйста 🙂
      Проблема в том, что с MaxSite CMS я только экспериментировал, в основном по лекциям на сайте Максима, в коде особенно не ковырялся. Поэтому и статья у меня обзорная.

  • а чеж щас то на вордпресс перешел? хех

    • Я никуда не переходил. Этот блог бы на WP изначально, еще до появления MaxSite CMS.

  • а чеж щас то на вордпресс перешел? хех

    • Я никуда не переходил. Этот блог бы на WP изначально, еще до появления MaxSite CMS.