Сайт вебмастера

MaxSite CMS. Теория

04-01-2008Reading time ~ 8 min.PHP 24851

Здесь должно было бы быть какое-то вступление, но я так ничего и не смог придумать. Я понимаю, то нужно как-то объяснить о чем буду дальше писать в этом блоге, но красивые фразы не получаются. Поэтому я решил, что нет смысла на это тратить время и просто сообщаю, что речь пойдет о CMS, но которая пока существует только в моей голове. Мы попробуем потренироваться и (без лишних амбиций) просто понять как вообще работают такие «штуки».

Старенькая статья, о том, как я создавал MaxSite CMS.

Вступление

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

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

Гибкость

«Движок» должен уметь работать с любой структурой данных, а не только той, которую заложили разработчики. Например у нас есть набор записей. Каждая запись может быть определенного типа: черновик, личная, публичная, запароленная, заметка to-do и т.д. При этом мы хотели бы самостоятельно создавать типы заметок, а в шаблоне (админ-панели и т.п.) самостоятельно решать какие из них следует выводить. Очевидно, что если мы жестко пропишем эти типы в «движке», то мы должны будем включить серьезную поддержку (функции, данные, файлы) для всех этих типов. На мой же взляд, «движок» должен содержать лишь минимальный механизм для управления данными.

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

К моментам гибкости хочу отнести еще и способ работы «движка». На первый взгляд кажется, что нужно предусмотреть как можно больше функций для пользователей на «все случаи жизни». Нужен вывод списка - пожалуйста, нужно выпадающий - без проблем, а хотите просто массив - еще проще. Всё это замечательно, но в реальности мы сталкиваемся с тем, что большинство функций никогда не используются. Срабатывает принцип Парето, когда 80% пользователей используют не более 20% возможностей. Откройте свой WordPress-шаблон и увидите, что для вывода списка записей нужно от силы 1-2 десятка функций. Но, поскольку оставшиеся 80% существуют и подгружаются не зависимо от вашего желания, то мы неизбежно сталкиваемся с проблемой производительности и нехватки памяти.

Я же думаю, что нет смысла делать вывод списка (для примера) рубрик, да еще и с html-форматированием. Что мешает выполнить один запрос (с учетом своих нужд) к БД и получить единый массив? После этого совершенно не сложно выполнить обход массива в цикле и выполнить html-форматирование по своим потребностям. С точки зрения php-программирования это элементарные вещи.

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

Скажем, что происходит в момент получения страницы в WordPress? Помимо инициализации кучи массивов, объектов, переменных и констант, подключаются модули базы данных, функции форматирования, рубрики, метки и т.д., и т.п. (Убедиться в этом можно заглянув в файл wp-settings.php - см. функции «require».) Грубо говоря, подключается практически всё. На мой взгял это совершенно не оптимально.

Работа шаблона

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

Возьмем простой пример: вывод главной страницы. Часто нужно вывести не последние записи, а какой-то их набор. Эта примитивная задача для простого php-скрипта, в WordPress решается только обходными маневрами. Проблема в том, что в момент инициализации, WordPress сам выполняет необходимые запросы к БД и создает глобальный массив, где и содержатся все записи для вывода. И только после этого управление передается шаблону. Таким образом в шаблоне мы должны еще раз сформировать уже нужный нам запрос и опять же получить его в массиве, потому что вывод записей осуществляется в т.н. цикле TheLoop.

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

Все это можно избежать, если предусмотреть, чтобы нужные записи определялись либо в самом шаблоне, либо через его контролер (об этом далее). То есть мы вообще исключаем ситуацию, когда «движок» выполняет запрос к БД и получает какие-то там данные до того, как они были реально востребованы.

Минимализм с помощью фреймворка (Framework)

Любая система содержит некий набор функций, который выполняет роль «ядра». С его помощью осуществляются (грубо говоря) операции «ввода/вывода»: подключение БД, основные операции с БД, анализ/парсинг входящего URL, подключение базовых файлов/классов и т.п.

Можно, конечно начинать делать с нуля, но на мой взгляд это бессмысленное занятие, потому что уже существуют несколько неплохих фреймворков, которые можно без особых сложностей взять за основу. Из наиболее распространенных следует выделить два: CodeIgniter (https://www.codeigniter.com/) и CakePHP (https://www.cakephp.org/).

Основные требования к фреймворку:

  • Небольшой объем
  • Документация и легкость осваивания
  • Работа с различными БД
  • Простота настроек
  • Скорость работы
  • Расширяемость за счет своих модулей
  • Поддержка PHP 4 и 5
  • Поддержка MySQL 4 и 5

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

Я склоняюсь к CodeIgniter. Прежде всего из-за двух вещей: скорость работы (считается, что это самый быстрый фреймворк), а также из-за его удачной структуры. Поскольку я никогда не работал ни с CodeIgniter, ни с CakePHP, то сравнил насколько быстро и просто можно с нуля разобраться что к чему.

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

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

Сравнивая эти фреймворки я естественно, обратился за информацией на другие сайты и у меня сложилось впечатление, что CakePHP преподносится не сколько как фреймворк, сколько как «пред-CMS», где уже содержатся все необходимые модули. И действительно в CodeIgniter содержится примерно в два раза меньше php-файлов и «весят» они в три раза меньше, чем в CakePHP. При этом оба они содержат примерно одинаковое количество модулей (больше 30)...

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

Model-View-Controller (MVC). Модель-Вид-Контролер

Современые фреймворки работают по принципу MVC. Данная схема позволяет разделить вывод данных, то есть окончательный вывод в браузере от внутреннего представления и управления. На самом деле про Model-View-Controller написано немало (можно погуглить), но понять что это такое можно только на практике. На мой же взгляд MVC - это скорее теория, потому что неизбежно возникнут ситуации, когда нужно будет формировать конечный html-код например в «контролере». Другое дело, что можно/нужно стремится следовать этой идеологии - как минимум это улучшает и понимание кода, и его поддержку в будущем.

Админ-панель

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

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

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

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

При этом нужно решить вопросы управления данными. Можно сразу же в модуле администрирования прописать вызовы к БД, но лучше сделать их на уровне CMS. Объясняю для чего. Предположим у нас есть функция add_page. Если она расположена в CMS, то мы можем вызвать её как из админ-модуля, так и из XML-RPC. Последний позволит управлять системой с помощью блог-клиентов. Если же мы пропишем add_page в админ-модуле, то нам придется либо её еще раз дублировать для XML-RPC, либо подключать сам модуль. Все это естественно нерационально, да и путаницу может внести изрядную.

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

При этом должна быть единая база пользователей. В WordPress'е мы столкнулись с ситуацией, когда пользователи могут быть зарегистрированными и незарегистрированными. При этом разница между ними по-сути гипотетическая. Я бы сделал так.

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

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

Related Posts
Comments (28) RSS
1 Александр@WP-web 2008-01-04 21:45:19

глобально, однако.

неужели вы решились на написание своей CMS?


2 cross 2008-01-04 22:05:36

Их уже столько, этих, CMS что наверное хватит :)


3 mekal 2008-01-04 22:13:05

по-моему учитывая професионализм Максима это правильное решение - начать зарабатывать на своем продукте, а не на чужом


4 Yaroslav 2008-01-04 22:15:47

Поддерживаю. По поводу админки у меня были мысли вообще вывести всю бизнес логику на уровень XML-RPC, а админка пусть будет сама по себе. Тогда, представляешь, что можно будет с одной админки рулить несколькими блогами находящимися на разных хостах...


5 Максим 2008-01-04 22:24:47

Ну пока это все теория. Я не хотел бы сейчас давать какие-то обещания. Но, думаю, что сам процесс будет интереным. :)

Ярослав, абсолютно верно. Давно уже были такие мысли, я даже более радикально придерживался мнения, что админка вообще не нужна - все делается через блог-клиенты, а значит вообще отпадает необходимость и в дизайне, и во всех этих сложных пользовательских интерфейсах. Но, как ни крути, а должен быть какая-то точка доступа через браузер, поэтому от админ-панели никуда не денешься. Полностью же вывести на уровень XML-RPC не получится по причинам того, что некоторые модули будут работать только через свои формы, и, самое главное, блог-клиенты просто не будут поспевать за столь развитым XML-RPC. :wink:


6 Brim 2008-01-04 23:11:49

> Их уже столько, этих, CMS что наверное хватит

Угу. А реально известных и используемых всего 3. :) И то, решить нестандартную задачу там не всегда выходит.


7 Владимир 2008-01-04 23:34:31

Полностью согласен в отношении CodeIgniter.

Я с ним немного работал, и остались только положительные впечатления.

Самое главное, это возможнось заменить практически любые компоненты.

Кстати, советую сразу изменить поддержку сессий (подробнее здесь http://codeigniter.com/wiki/Category:Libraries::Session/).

Удачи!!!!!

P.S. Делать админку доооооолго!


8 Tapac 2008-01-05 02:12:37

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

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

Отсюда и работа с шаблонами и множество "ненужных" параметров у функцмй, видимо старались учесть всё.

Хотя согласен, что много не рационального, а уж сколько народ упрашивает переделать WP под какой-нить "шустрый" фреймворк - даже и вспоминать страшно)

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

Не забывай обновлять двиг, пока он на вордпрессе, а то хакнут ещё)


9 cerber 2008-01-05 05:08:09

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

из кмс, имхо дле - рулит на рынке.

очень устойчивый движок к нагрузкам и дырок в паблике нет.

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


10 ABTOP 2008-01-05 09:56:32

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

Поясню на пальцах. Всем известны отвёртки и авторучки. Это специализированные решения конкретных задач. Если кончик ручки сделать в виде крестика, то ею можно будет откручивать шурупы типа "Филипс". Но это будет не очень удобно, т.к. не будет нормальной рукоятки, чтобы покрепче ухватиться рукой. Если приделать рукоятку, то такой авторучкой будет не так удобно писать.


11 Уникальный Человек 2008-01-05 11:08:53

Классно! Давай делай свою CMS, удачи тебе! :cool:

Буду во всем поддерживать, если сделаешь :roll:


12 Vagur 2008-01-05 12:35:28

Поддерживаю! Даеешь национальнный Open Source CMS!!!

Если даже и взяться за разработку отечественного движка, то делать это сообща, тоесть командой.

Церберу: а по поводу CMS без мускула - это был Dinamik CMS dinamikcms.info проект похоже закрылся. Да там все летало, и все просто было. Могу кому надо последние сборки кинуть для ознакомления.


13 Максим 2008-01-05 12:48:27

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


14 Yaroslav 2008-01-05 12:54:03

Когда писал про XML-RPC как раз и подразумевал, что можно вообще без админки обойтись и можно будет юзать с десктопного клиента. А десктопный клиент можно и свой написать. Главное что если будут доступны все функции администрирования через XML-RPC, то админить можно будет из любого места и админку можно будет на чем угодно написать.


15 Александр@WP-web 2008-01-05 16:51:21

Кого интересуют живые ЦМСы без SQL - opensourcecms.com, раздел Lite

Максим, а ты ван-фейсом.ру пользуешься - на их главной есть ссылка на тебя?


16 Andrey Troy 2008-01-05 18:56:08

Ну и сразу придумать процесс перехода с wordpress на твою cms! Так чтоб одним махом, экспортом так сказать.


17 fe-nix 2008-01-05 19:47:11

Максим, Благое дело делаешь!

Была мысль создать свою CMS. Жива и по сей день. Но только мысль.

Как думаем об объемах работ, все опускается.

В статье все верно и правильно описано. Готов подписаться под каждым словом!

Спасибо за сайт, За труды во благо всех!

Желаю тебе написать-таки свое детище!

Уверен, что с твоим уровнем, она превзойдет все аналоги!


18 bublik 2008-01-05 20:00:55

Хотите наверно wordpress 2.4 написать? :smile:


19 Коля Дубр 2008-01-05 23:55:39

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

Это по моему скромному опыту.


20 Tod 2008-01-06 00:35:54

Писать свою ЦМС это не просто круто, а даже МЕГА-круто, но имхо слегка утопическая идея. Во-первых, зачем это нужно? Этих систем сотни, понятно, что многие из них "заточены" под конкретные нужды, но есть и реально мощные, способны решать практически любые задачи. Конечно не все там идеально и просто, скорее наоборот, а для супер нестандартных вещей 100% нужна доработка, но это проще и быстрее написания "своего". Потому что выйти на подобный уровень самому опять же имхо нереально. Особенно это касается Опен-сорс ЦМС, которые поддерживают сразу несколько человек, а если там еще и "модульность" есть, то и подавно догнать их не удастся.

Во-вторых, нужно реально представлять что из этого ты получишь? Опыт в ПХП, думаю у тебя его и так много? Деньги? Для этого нужно потратить оооочень много времени на создания действительно качественного и конкурентного продукта. К тому же есть платные системы проигрывают бесплатным аналогам. А на спонсорство у нас не проживешь:)

А вообще - удачи:)!


21 Коля Дубр 2008-01-06 02:04:33

Ну, я например не видел ни одной CMS, где нормально реализована шаблонизация средствами XSLT + возможность работать с БД через объектный интерфейс (хотя бы для самых простых действий и выборок). У многих студий были внутренние разработки такого рода, а чтоб купить (скачать) и поставить - не было. Поэтому написал свою :) В сторону фреймворков не смотрел, т.к. мало что о них тогда было известно.


22 g_i 2008-01-06 16:44:50

НУ и правильно.

давно пора своё написать.

лично я СРАЗУ как релиз - ставлю:)

плюс сразу хотелось бы возможность перевода иметь (это я об украинском)


23 aquablog 2008-01-07 17:53:20

Идея создать ИДЕАЛ преследует каждого, кто хоть что-то пытается создать... Лично я - двумя руками за!!!


24 Sonic 2008-01-15 08:59:22

Свою CMS писать надо обязательно. Но при этом надо помнить что функционал должен быть расширяемым, т.е. раздел ФОТО ГАЛЕРЕЯ, например, при добавлении новых параметров получает новые возможности, как ПУБЛИКАЦИЯ ФОТО В ОПРЕДЕЛЕННОМ РАЗДЕЛЕ, НА ГЛАВНОЙ СТРАНИЦЕ, ПОКАЗ ПОПУЛЯРНЫХ ФОТОГРАФИЙ и т.д. То же относительно разделов новости, статьи и т.д. При таком построении сайта функционал легко расширяем и из визитки строится портал с возможностями е-коммерса.


25 Александр 2008-01-18 15:06:00

Максим, а ты не копал в сторону modx?


26 Максим 2008-01-18 15:17:28

Смотрел когда-то, но это что-то совсем монстроподобное.


27 Александр 2008-01-18 20:13:43
Смотрел когда-то, но это что-то совсем монстроподобное.

На самом деле он проще, чем кажется с первого взгляда. Покопайся, с твоей любовью "доточить CMS напильником", modx может оказаться намного гибче и функциональнее, чем wp.


28 zhulanov 2008-01-30 15:00:50
При таком построении сайта функционал легко расширяем и из визитки строится портал с возможностями е-коммерса.

@Sonic

Хаха, вот из-за таких мыслей и появляются всякие говно-cms типа mambo/joomla, phpnuke и прочего шлака.