Frog CMS - простота и элегантность

[Ялекс]

Здравствуйте. Я раньше был активным участником этого форума, но теперь попросту не хватает времени участвовать в обсуждениях, надеюсь администрация меня поймет и не сочтет это сообщение за спам или навязчивую рекламу, тем более я согласен ответить на все ваши вопросы. Возможно тема будет лучше смотреться в разделе PHP или Ресурсы, но я не стал гадать и опубликовал её здесь.

Я запустил русскоязычное сообщество Frog CMS. Движок я всячески поддерживаю, разрабатываю сайты на нем уже год, поэтому решил продвинуть в рунете и написал небольшой обзор.

Frog CMS

Сервер: Apache

Язык программирования: PHP5

Базы данных: MySQL или SQLite 3.

Официальный сайт: http://madebyfrog.com/

Англоязычное сообщество: http://forum.madebyfrog.com/

Документация на английском: http://madebyfrog.com/docs.html

Документация на русском: http://frogcms.in.ua/

Русскоязычное сообщество: http://groups.google.ru/group/frog-cms-ru

Frog CMS — простая система управления сайтом, основными особенностями которой являются: небольшой размер, простота использования, гибкость, высокая производительность. Философия системы заключается в следующем: разработчику предлагается ядро с базовыми функциями и удобным API, остальной функционал наращивается за счет плагинов.

Демо версия

Демонстрационный сайт показывает нам как на базе Frog CMS можно организовать блог.

Демонстрационный сайт (версия 0.9.5): http://opensourcecms.com/demo/1/28/Frog

Демонстрация админ раздела: http://opensourcecms.com/demo/2/28/Frog (Логин: admin Пароль: demo123)

Немного истории

Начала свою жизнь система в январе 2007 года благодаря известному Ruby On Rails приложению - Radiant CMS. Название было подобрано соответствующее - phpRadiant. Затем через некоторое время название сменили, система начала назваться Frog CMS, что в переводе означает Лягушка. Был выбран именно этот представитель живой природы, потому что точно он, как и система, обладает качествами: быстрота и простота, не требовательность.

Система была выложена под лицензией GNU General Public License 3. В данный момент доступна для бесплатной загрузки версия системы 0.9.5.

Требования к серверному ПО

Система действительно не требовательна, и способна работать на бесплатном хостинге с большими ограничениями. Из бесплатных могу советовать http://byethost.com/.

Серверный язык: PHP 5

Базы данных: MySQL 4 и выше, либо SQLite 3

Рекомендуется:

* Поддержка сервером UTF-8

Наличие PHP-модулей:

* PDO

* mod_rewrite

Установка занимает 10 минут после чего вам будет доступен готовый демонстрационный сайт-блог.

Установка описана на странице: http://frogcms.in.ua/rukovodstvo-polzovatelya/ustanovka.html

Особенности

Главной особенностью системы является так называемое PHP "дерево сайта". Другими словами существует определенная переменная которая даёт возможность "прогуливаться" по иерархии страниц, находить нужную и выводить контент или только информацию о станице. С помощью данного приёма поиск и вывод ленты новостей сводиться к поиску страницы по URI и вывод информации о потомках этой страницы.

Как было сказано выше - возможности системы безграничны, потому что основным ограничением является набор модулей, разработанный сообществом.

Разработчик позаботился чтобы создание модулей было простым и комфортным. Фундаментом системы является Green Framework - быстрый и простой, поддерживающий структуру MVC в админ панеле и модулях. Для разработчика доступно API на базе которого легко создаются новые, не стандартные, модули. Предусмотрено практически все: от активации и деинсталляции модуля до специальной страницы-документации модуля.

Сфера применения системы

Система идеально подходит для разработки сайтов-визиток, потому что её размер мал, а средств для управления сайтом-визиткой более чем достаточно.

Но однозначно нельзя сказать, что на базе этой могут работать только сайты-визитки. Среди сайтов, разработанных на Frog CMS (http://frogcms.in.ua/primeri-proektov-frog-cms.html) есть и корпоративные сайты, промо-порталы.

Демонстрационный сайт показывает нам как на базе Frog CMS можно организовать блог.

Если ваш уровень программирования выше среднего, то вы без труда нарастите необходимую функциональность, используя API системы.

Модули: начальная комплектация

Исходя из философии системы: "разработчику предлагается ядро с базовыми функциями и удобным API, остальной функционал наращивается за счет плагинов" не трудно предположить, что начальная комплектация минимальна.

Модуль Textile и Markdown

Изначально в системе отсутствует WISIWIG редактр, а представлены два на выбор Wiki-подобных редактора: Textile и Markdown.

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

Модуль Файловый менеджер

Для "публичных" файлов системой предусмотрена отдельная директория "public", где администратор или редактор обычно хранят изображения, документы, необходимые для вставки в контент страниц. Загрузка и управление этим каталогом файлов осуществляется через модуль - файловый менеджер.

Модуль Комментарии

По умолчанию модуль отключен. Модуль реализует систему комментариев для всех страниц сайта. Для каждой страницы можно включать или отключать комментарии.

Модуль Страница не найдена

Этот модуль включает специальный статус "Page not found". Страница, имеющая этот статус автоматически определяется, как "Страница 404-й ошибки". То есть будет выводиться только в случае неправильно введенного URL.

Остальные модули представлены либо на официальном сайте, либо на сайте русскоязычного сообщества. Среди них есть разнообразные визуальные редакторы Tiny MCE, FCKEditor, фото-галереи, формы обратной связи, форум...

Пользователи

В системе предусмотрено три уровня доступа:

• Администратор - владеет всеми привилегиями
  
• Веб-мастер (дизайнер) - ограничен в функциях управления пользователями и настройками
  
• Редактор - разрешен доступ к некоторым страницам, функциям создания и редактирования, файловому менеджеру и определенным плагинам
  

В заключении

Система идеально подойдет для разработки сайта-визитки, новостного сайта или сайта-блога. Главными особенностями является простота и легкость в освоении. Профессиональные разработчики найдут богатое API для разработки нестандартных плагинов. Система SEO дружелюбна.

Разбираясь в системе вы будете находить интересные и элегантные решения, открывать её изнутри.

Edited January 10, 2010 by Ялекс

[Ялекс]

Для скачивания доступна оптимизированная под русского пользователя версия системы по адресу: http://groups.google.ru/group/frog-cms-ru/...a1f163034a6366a

[s0rr0w]

Посмотрел. CMS на слабую троечку.

[Ялекс]

Что не понравилось?

[Иван Шумов]

ООП хреновенькое, работа с базой... лучше бы использовал ну не знаю.. Doctrine что-ли... модель тоже через PDO, но послабже

[Ялекс]

PDO для с базой не эталон, но вполне хорошо работает и выполняет возложенные на неё задачи.

Doctrine замедляет работу с БД. Не понимаю зачем нужны такие навороты - это же движок для визиток/блогов?

Так как модернизирую систему, хочу услышать подробно: почему "хреновенькое ООП"?

Edited January 10, 2010 by Ялекс

[Иван Шумов]

PDO для с базой не эталон, но вполне хорошо работает и выполняет возложенные на неё задачи.

Doctrine замедляет работу с БД. Не понимаю зачем нужны такие навороты - это же движок для визиток/блогов?

Так как модернизирую систему, хочу услышать подробно: почему "хреновенькое ООП"?

пока не научишься программировать с использованием ООП не поймешь, если серьезно - там от ООП одни базовые понятия.

Что касается Doctrine то ты не найдешь разницу в производительности С и БЕЗ если у тебя не 100к+ онлайн на сайте, а при такой посещаемости это уже хайлоад, рассчитанный на VDS, репликации и т.п. вещи

[Ялекс]

Концепция системы в простоте и легкости - так код системы в архиве ~500 кб, а в разархивированном варианте ~1,3 мб.

Если сделать поддержку Doctrine в ядре, то получим начальный архив уже 1,1 мб, а весь размер системы в разархивированном виде ~3,2 мб.

Очевидно, что о легкости уже не идет речи. Вы ведь, для сайта-визитки не задействуете всю артиллерию и боезапас?

Для разработки сайта на базе этой системы не обязательно знать всех нюансов ООП - нужно просто понимать что возвращает метод, например, $this->children(). Не скажу, что система для начинающих, но для вполне состоявшихся веб-мастеров-фрилансеров - будет хорошим подспорьем.

s0rr0w, я хочу услышать твой комментарий: что конкретно необходимо улучшить в системе. Буду хотя бы наверняка знать что хотят пользователи или что не нравиться.

Edited January 10, 2010 by Ялекс

[Иван Шумов]

Концепция системы в простоте и легкости - так код системы в архиве ~500 кб, а в разархивированном варианте ~1,3 мб.

Если сделать поддержку Doctrine в ядре, то получим начальный архив уже 1,1 мб, а весь размер системы в разархивированном виде ~3,2 мб.

Очевидно, что о легкости уже не идет речи. Вы ведь, для сайта-визитки не задействуете всю артиллерию и боезапас?

Приехали, а на хостинга наверное ну так мало место что лишние 2 метра нам уже давят на мозги. Взять и залить директорию в 1 метр это нормально, а в 10 уже религия не позволяет? Не важно сколько весит ядро - сайт все-равно как правило еще нагружается изображениями, css, шаблонами. Рядом с этим все это ядро тихо спит в сторонке.

[s0rr0w]

s0rr0w, я хочу услышать твой комментарий: что конкретно необходимо улучшить в системе. Буду хотя бы наверняка знать что хотят пользователи или что не нравиться.

Систему стоит рассматривать с нескольких сторон.

С точки зрения пользователя системы:

1. Редактирование страницы.

Что за фильтр? Что это дает? Какую задачу решает?

Есть метаданные у страницы. Это вроде как служебная информация. Тогда почему бы туда не занести еще и инфу про Layout, Page Type и т.д.

Контент отдельно, настройка свойств страниц - отдельно.

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

Вот с этим у меня вообще ступор.

Login: [_____|v] [ ] Protected

Если траница защищена, то как она может не требовать логина? Стремное поведение какое-то.

Да и layout раздела Pages отличается от того же Files

2. Темплейтирование.

Использование вставок php считаю прошлым веком. Читабельность кода никакая, для редактирования потребуются серьезные знания пхп, что для простого пользователя может стать серьезной проблемой.

3. Раздел Files

Вообще непонятно, что там делают пермишины. Дырка в систему? Пользователь должен сам догадаться, что есть 777, что есть 755? Бред какой-то.

Что вообще отсутствует

Визитки зачастую делаются мультиязыковыми. Как это реализовать? Как дела обстоят с локализацией самого интерфейса?

Программерская часть

SQL размазан тонким слоем по всему коду. Этот подход несколько устарел уже. Это приводит к дыркам в систему, sql-инъекциям, куче других проблем.

Темплейтирование сниплетов, плагинов? Как для каждого плагина сделать свой дизайн?

Остальное Иван уже подметил.

[Иван Шумов]

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

[s0rr0w]

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

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

Лет 8 назад я тоже остро реагировал на критику. Но однажды меня так натолкали носом, что я на всю жизнь запомнил.

[Ялекс]

Нет, я не собираюсь злиться. Мне действительно интересно послушать про недостатки.

1. Редактирование страницы.

Что за фильтр? Что это дает? Какую задачу решает?

Фильтр - это редактор. Есть возможность использовать TinyMCE, сейчас пробую сделать плагин редактора Xinha, потому что там есть встроенный редактор изображений.

Я уже подумывал сменить название "Фильтр" на "Редактор", но еще не совсем уверен, потому что в коде это как раз filter.

Есть метаданные у страницы. Это вроде как служебная информация. Тогда почему бы туда не занести еще и инфу про Layout, Page Type и т.д.

Это раздел для SEO информации, конечно там находятся тэги, что вряд ли относиться к SEO, но так было сделано. Пока ничего кардинально не менял, только делал плагины, исправлял небольшие косяки в ядре.

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

В шаблоне, через $this->content('content_bar'); или $this->content('content_bar', true); чтобы наследовать контент у родителя, если нет у текущей страницы.

Login: [_____|v] [ ] Protected

Если траница защищена, то как она может не требовать логина? Стремное поведение какое-то.

Страница защищается паролем. Создаёшь отдельного пользователя, например, редактора и он со свои паролем может просмотреть отдельные страницы или разделы сайта.

Защищена. Если ты администратор, то можешь защать страницы - их нет возможности отредактировать, если ты редактор.

Да и layout раздела Pages отличается от того же Files

В смысле? Files - это отдельный модуль.

2. Темплейтирование.

Использование вставок php считаю прошлым веком. Читабельность кода никакая, для редактирования потребуются серьезные знания пхп, что для простого пользователя может стать серьезной проблемой.

Wordpress, Drupal без шаблонов. Но в кое чем согласен. Можно реализовать с помощью модуля. Пробовал делать Smarty для версии 0.9.4, но там была загвосточка, модуль принципе работал, но работал немного не кошерно. Попробу реализовать в 0.9.5.

3. Раздел Files

Вообще непонятно, что там делают пермишины. Дырка в систему? Пользователь должен сам догадаться, что есть 777, что есть 755? Бред какой-то.

Одному разработчику известно зачем это было предусмотрено. Спасибо, что заметил.

Что вообще отсутствует

Визитки зачастую делаются мультиязыковыми. Как это реализовать? Как дела обстоят с локализацией самого интерфейса?

Реализуются. Есть описание на форуме. Я думаю сделать несколько рецептов. Есть возможность сделать две ветки: русская версия, английская.

В модулях и лэйауте повсюду используется i18n. Что это такое - объяснять, думаю, не нужно.

Программерская часть

SQL размазан тонким слоем по всему коду. Этот подход несколько устарел уже. Это приводит к дыркам в систему, sql-инъекциям, куче других проблем.

Можешь перевести хороший пример реализации - посмотрю? Работа с базой конечно не самое сильное место в системе.

Темплейтирование сниплетов, плагинов? Как для каждого плагина сделать свой дизайн?

Есть возможность. Можно посмотреть, например, плагин comment, папка [root]/frog/plugins/comment/views.

Спасибо за ответ. Есть здравые замечания.

Edited January 10, 2010 by Ялекс

[s0rr0w]

Фильтр - это редактор. Есть возможность использовать TinyMCE, сейчас пробую сделать плагин редактора Xinha, потому что там есть встроенный редактор изображений.

Я уже подумывал сменить название "Фильтр" на "Редактор", но еще не совсем уверен, потому что в коде это как раз filter.

В том же фенотайпе это реализовано лучше и продуманнее.

Это раздел для SEO информации, конечно там находятся тэги, что вряд ли относиться к SEO, но так было сделано. Пока ничего кардинально не менял, только делал плагины, исправлял небольшие косяки в ядре.

Не очень то понятно, что это раздел для SEO. Да и кто мешает рядом еще один таб сделать?

В шаблоне, через $this->content('content_bar'); или $this->content('content_bar', true); чтобы наследовать контент у родителя, если нет у текущей страницы.

Ты про это знаешь, так как ты разработчик. Пользователю это вообще не очевидно.

Страница защищается паролем. Создаёшь отдельного пользователя, например, редактора и он со свои паролем может просмотреть отдельные страницы или разделы сайта.

Защищена. Если ты администратор, то можешь защать страницы - их нет возможности отредактировать, если ты редактор.

Это не очевидно без прочтения документации.

В смысле? Files - это отдельный модуль.

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

Wordpress, Drupal без шаблонов. Но в кое чем согласен. Можно реализовать с помощью модуля. Пробовал делать Smarty для версии 0.9.4, но там была загвосточка, модуль принципе работал, но работал немного не кошерно. Попробу реализовать в 0.9.5.

И за это я ненавижу эти две системы. Натянуть новый скин без танцев с бубном - нереально.

Одному разработчику известно зачем это было предусмотрено. Спасибо, что заметил.

Это еще та глупость.

Реализуются. Есть описание на форуме. Я думаю сделать несколько рецептов. Есть возможность сделать две ветки: русская версия, английская.

Ну, раз так, то тогда ок.

Можешь перевести хороший пример реализации - посмотрю? Работа с базой конечно не самое сильное место в системе.

Фенотайп мне нравится. Там есть абстракции и на уровне базы, и на уровне кода. Можешь посмотреть знаменитые ПХП фреймворки, просто почерпнуть оттуда идеи.

Есть возможность. Можно посмотреть, например, плагин comment, папка [root]/frog/plugins/comment/views.

С первого взгляда я не выявил.

[Ялекс]

Что то определенно про Фенотайп сказать пока не могу сказать - загрузил демку - пока что не очень понятно, скачаю, попробую разобраться.

Спасибо, буду исправлять по возможности все.

В шаблоне, через $this->content('content_bar'); или $this->content('content_bar', true); чтобы наследовать контент у родителя, если нет у текущей страницы.

Без документации многое не очевидно, в принципе, во многих системах. Попробуем это исправить, сделав доступную документацию.

upd.

Phenotype похож чем то на OpenConstructor от козахских разработчиков, но у тех с кодом вообще все плохо. Вообще интересный фреймверк, но класс систем разный.

Edited January 10, 2010 by Ялекс

[Ялекс]

Хм, посмотрел фенотайп изнутри. Код немножко шокировал, все таки это ведь немцы.

Открыл на угад файл selector_media_upload2.php:

		$sql = "SELECT med_comment FROM media WHERE med_id = " . $id;
		$rs = $myDB->query($sql);
		$row=mysql_fetch_array($rs);

Непонятно где здесь абстрактный доступ к БД, если присутствует mysql_fetch_array().

То есть абстракция на уровне контента, но нет абстракции доступа к базе.

Дал ссылку товарищу (вполне компетентный) - думал только мне одному админка кажется непонятной, он тоже сразу не понял. Конечно не спорю - система может хороша, но это совсем не "простая" и совсем не для сайтов визиток.

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

Вообще реально на фенотайпе сделать магазин? И насколько просто и понятно будет добавление товаров в магазин, и какими усилиями можно собрать магазин и насколько получившееся решение будет переносимо, к примеру, на другой проект?

Edited January 10, 2010 by Ялекс

[s0rr0w]

Хм, посмотрел фенотайп изнутри. Код немножко шокировал, все таки это ведь немцы.

Код там местами древний, его не переписывали. Иногда попадаются sql-вставки.

http://www.phenotype-cms.com/wiki/api-start

Непонятно где здесь абстрактный доступ к БД, если присутствует mysql_fetch_array().

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

То есть абстракция на уровне контента, но нет абстракции доступа к базе.

Посмотри на их API, ссылку выше привел.

Дал ссылку товарищу (вполне компетентный) - думал только мне одному админка кажется непонятной, он тоже сразу не понял. Конечно не спорю - система может хороша, но это совсем не "простая" и совсем не для сайтов визиток.

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

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

Изучай. Это полезно. Я не ковырял битрикс, там вроде тоже неплохо продумано все, но фенотайп - единственный CMF, который мне понравился за последние три года. Идеи, которые там используются не студентов-разработчиков. Реализация хромает, не спорю, но идеи - классные.

Вообще реально на фенотайпе сделать магазин? И насколько просто и понятно будет добавление товаров в магазин, и какими усилиями можно собрать магазин и насколько получившееся решение будет переносимо, к примеру, на другой проект?

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

Переносимость сделана в фетотайпе на 4+. Пока что, лучше решения я не видел на рынке.

Если интересно, могу составить краткий экскурс в фичи фенотайпа.

[Ялекс]

Конечно, это что то уникальное, тем и интересно.

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

[s0rr0w]

Конечно, это что то уникальное, тем и интересно.

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

Страницы.

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

Статические страницы - обычные страницы, контент которых не зависит от каких-либо факторов

Динамические - контент которых зависит от запрашиваемых параметров.

Специальные - не знаю.

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

Глобальный контейнер наполняется контентом при помощи компонентов.

Компонент может описывать разные структуры данных. Типичный пример компонентов: заголовок, текст + заголовок, список + заголовок, таблица, галлерея и так далее.

Основная цель компонентов - не давать пользователю ломать дизайн страниц, который предусмотрен разработчиком. В текст нельзя вставить заголовок или картинку. Это можно сделать при помощи компонента. Фактически, пользователь лишен чудесного права что-то испоганить своим ужасным вкусом.

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

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

Страницы имеют версии. Это позволяет переключать различное отображение страниц вручную или по времени.

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

Экспорт-импорт данных

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

Статистика просмотра страниц

Интегрирована прямо в систему. Удобно.

Layout'ы страниц

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

Работа с картинками

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

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

Ресайз, кроп, мультиаплоадинг - все через интерфейс.

[aTei]

Подводя итоги:

- не скоростная

- не простая

- вполне подходит, чтобы полазить, набраться опыта. Может подхватить какие-то идеи, а где-то вспомнить как делать нельзя.

[Ялекс]

Подводя итоги:

- не скоростная

- не простая

- вполне подходит, чтобы полазить, набраться опыта. Может подхватить какие-то идеи, а где-то вспомнить как делать нельзя.

"- не скоростная" - почему не скоростная? Пускай не лидер скорости, но этому уделяется внимание.

"- не простая" - аргументируйте. В чем возникли затруднения?

Здравствуйте. Сделал поддержку шаблонизатора Smarty в шаблонах.

Просмотреть описание и скачать плагин Frog CMS: Smarty.

Edited January 12, 2010 by Ялекс