Комментарии

Большое спасибо за подробную статью о SPA и MPA и в целом развитии веб приложений, это было очень интересно и познавательно.

Удобство все же вполне осязаемая штука. Если взять две системы и попробовать научить использовать их секретаршу, а потом еще предложить ей консультирование в течении месяца, то все становится довольно быстро понятным. Учить Joomla например будет весьма непросто. Люди просто забывают как там и что работает, как только закрывают ее больше чем на неделю. И посмотрите для примера MODx. Для понимания всех основных и необходимых возможностей управления уходит примерно 3-4 часа (включая последующие консультации).

Разумеется сначала человеку нужно разобраться в интерфейсе. Так вот скорость изучения как раз и зависит от удобства.

В общем-то правда, что данные CMS делаются программистами для программистов. Потому что именно программисты потом проводят внедрение этих систем, допилку напильником под нужды заказчика. У всех систем свои интерфейсы, так как слишком разная у всех концепция хранения, представления и управления информацией. Унифицированного ничего нет. Даже windows вам удобна только потому что вы к ней привыкли. А если посадить человека первый раз за компьютер, то интерфейс любой CMS будет ему не на много отличаться от интерфейса винды — также неудобен и незнаком.

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

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

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

Joomla — не пользовался, но в багтраках проскакивает очень часто. Будте осторожнее

И потом, у любой CMS есть, скажем так, некий баланс между легкостью разработки и возможностями, и сложностью и возможностями админки. Т.е. система, которая создана программистами для обычных пользователей, скорее всего проиграет в возможностях и скорости. «программистами для обычных пользователей» — в данном случае имеется ввиду кастомизация системы под определенный проект с помощью админки без знания каких-либо специальных знаний (языков программирования и т.д.)

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

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

А чтобы все было более менее гибко_ CMS должна быть (IMHO!!! — это на тему должна и если мы говорим о гибкости) объектно-полиморфичная, и если уж привязанная к БД, то к какой-нить более мощной. Oracle, PostcgreSQL. Помимо прочегоЮ было бы очень даже правильно, чтобы параметры внутрь передавались целочисленные (коротенький кусочек PHP (int) лечит бошльшинство SQL инъекций).

А еще — и это уже сугубо IMHO — в идеале объем кода CMS не должен превышать 100 Кб кода. чем меньше — тем лучше. Достигается адекватным проектированием.

Мы с 1999 по 2004 работали с модульной системой собственного изготовления (поскольку оно изначально работало на postgresql, одной засады мы благополучно избежали), где-то во времена PHP5 RC1 собрали первый прототип фреймворка для клепания на лету кастоимзированных CMS. Не могу сказать, что все получилось идеально (например интерфейс, в свое время придуманный программистом, борется до сих пор и пока, к сожалению, побеждает), но вот при необходимости «с нуля» сотворить за неделю сайтик с уникальной функциональностью у нас вроде бы ка получается.

Господа — проектируйте, а не воюйте!

Вы точно внимательно читали заметку?
То что вы говорите, есть пункт первый. Это маркетинговое преимущество, типа «с нашими сайтами оооочень удобно работать, потому что они использую НашаSuperCMS, там можно делать то-то и то-то, так-то и так-то».

И даже тут, лучший вариант изменения сайта владельцем, это не админ панель вовсе, а хитроумный AJAX JavaScript. Когда нет необходимости обучатся админ-панеле, а можно менять свой сайт на своём сайте.

А автоматизация процесса всё равно нужно, потомучто увелечение производственной мощности только с помощю увелечения персонала, не есть хороший тон ведения бизнеса…

Все указанные автором комментария цели – частный случай. Со стороны разработчика.
Вы бы лучше посмотрели на CMS со стороны владельца сайта. На то ведь она и _CMS_ (content management system, т.е. система управления контентом), а не система создания сайтов.

Вообще говоря, мне не совсем понятны такие отзывы. Товарищ в первом комментарии жалуется на недостаточную гибкость существующих CMS. Но тут не может быть идеального решения. Либо негибкая система, но очень простая, либо гибкая, но сложная в освоении. Делать сайт вообще без использования CMS, на чистом PHP, к примеру, вообще максимально гибко. Но и максимально сложно.

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

Выбирал для себя подходящую CMS, перепробовал кучу вариантов, ни одного оптимального не нашел. В итоге, полностью перешел с CMS на фреймворк DST Platform — проблем нет

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

В css уже должны быть стили для всех h1/2/3… strong и т.д. а так же кастомные стили для различного рода контента и ОБЯЗАТЕЛЬНО приучить клиента ими пользоваться…
ИМХО если контент будет добавлять человек, который хоть как умеет работать в Word, то тут ничего сверхсложного не будет для него, ну а если не способен работать в Word, то и тут ему не место заниматься добавлением контента…

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

Вероятно, Вы просто не умеете готовить Drupal.

Вообще говоря, если не рассматривать проекты вроде яндекса или гугла (то етсь проекты действительно большие и не то, чтобы относящиеся к категории сайтов, создаваемых на CMS), все прочие проекты, фактически, маленькие. И, посему, если есть в наличии CMS (а правильнее — framework для быстрого — в течение, скажем, пары рабочих дней, как максимум — создания кастомизированной CMS), способной потянуть достаточно сложный из этих «маленьких» проектов — тогда, вероятно, нет прямого смысла заморачиваться на 2 -3 cms, которые будут уметь меньше, чем основная.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.

Только не забудьте сказать, что в комплекте для программиста должна быть валерьянка. :)
Лично изучая Drupal Form API чуть не повесился, и до сих пор нервничаю делая там формы. А уж сколько волос на голове останется у верстальщика, который рискнёт научиться писать шаблоны для Drupal (там даже Smarty всего не решает, увы) я и предположить боюсь. Но за то те, кто прошёл этот «Курс молодого бойца» конечно могут свысока смотреть на программистов UMI и Bitrix, поскольку гибкость Drupal даёт делать любую экзотическую кастомизацию достаточно небольшии затратами времени и сил.

Друпал, ИМХО, ориентирован на социальные проекты и «личные» сайты. Но никак не корпоратив. Слишком уж сложно получается для конечного пользователя. Иди пойми с ходу, что в друпале новости — это набор статей с тэгом «новости», а фотогалерея — такой же набор статей с тэгом «фотка» и что таким макаром можно сделать что угодно. Хорошо, конечно, что все это прекрасно вписывается в умолчальный дизайн и органично в нем смотрится. Но изнутри это все администрируется с тяжелым трудом и выглядит жутковато. Друпал и есть яркий пример системы от программистов для программистов.

Да, нужно сначала задуматься о целях CMS, которую хочешь приобрести. Какая CMS нужна web-студии, которая держит много проектов? Большинство делают сайты на одной и той же системе. А может быть стоит подумать в сторону «разные cms для разных целей»? То есть иметь арсенал(ну это грубо сказано, штуки 2-3) cms для проектов разных размеров?

Почему я так мыслю: чем универсальнее система, тем сложнее с ней справляться как в пользовательском отношении, так и в программном.

Называю систему: Drupal
А DST Platform это все таки уже фреймворк, сравнить с CMS не совсем объективно и честно

Студии штатов и Австралии часто используют joomla и drupal.
95% клиентов нашей студии оттуда, так что знаю на своем опыте за последние 3 года

Первоначально, до разработки какого-либо комерческого программного обеспечения разработчик должен (по идее) спросить у себя «Какую пользу принесёт покупка моего ПО?».

Для чего пишутся CMS/CMF в принципе?
На мой взгляд, есть такие основные цели:

Построение маркетинга студии («Наш сайт может обновлять любой ваш сотрудник»)
Автоматизация процесса вёрстки («Мы делаем сайты быстро»)
Автоматизация процесса программирования («Мы пишем нереально сложные вещи»)

По-сути, конечно, цель одна — увеличить прибыль. В данном случае путём сокращения времени на разработку и обновление. Только в первом случае, за счёт конечной реализации полей,
во втором, за счёт скорости внедрения популярных скриптов на оригинальный дизайн,
в третьем, ускорить процесс написание оригинальных фич, на которые и делается ставка на разрабатываемых сайтах.

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

CMS которая имеет все три направленности, я пока не встречал, да и не сильно пытался это сделать.
Сейчас пробую проектировать свою CMS, но это уже другая история…

Можно ещё сравнивать CMS по UI, но это не затронет технических характеристик.
Можно сравнивать по возможности кеширования, устойчивости, системе back-up'ов, шаблонов, но если не выяснен вопрос «А зачем Вам CMS?» все эти технические характеристики только загонят вас в тупик выбора.

Так что, до того, как искать CMS, подумайте, что вам от неё нужно.