Комментарии

Удобство все же вполне осязаемая штука. Если взять две системы и попробовать научить использовать их секретаршу, а потом еще предложить ей консультирование в течении месяца, то все становится довольно быстро понятным. Учить 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, подумайте, что вам от неё нужно.

Почему я не люблю российские коммерческие CMS

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

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

А задача то стояла простая, найти готовую систему которая бы не отнимала времени у сотрудников на создание однотипного функционала. Вторая задача, найти систему с максимально быстрой настройкой шаблона под свои нужды, ну и соответственная кастомизация тех или иных модулей. Сам я то, в прошлом программист но последнее время все ближе по духу к дизайнерам (фраза грубая но суть я думаю вы уловили). К разным дизайнерским мини-фичам на сайтах отношусь достаточно трепетно, и всячески отстаиваю права фичей на существование. Былой программист посмотрит на фичу и скажет: — «Да ну, что Вы господа придумали, херня полная, никому не нужна, да и мне с ней ковыряться долго, давайте-ка сделаем как на прошлом сайте». С таким порядком дел я вообще не согласен и при выборе системы управления считал тонкую кастомизацию тех или иных частей какого либо модуля – основным параметром качества системы.

С быстрой прикруткой шаблона, некоторые системы еще справлялись, а вот с кастомизацией уже сложнее. У меня сложилось такое впечатление что некоторые разработчики создают систему под единожды спроектированный демо сайт. Например новости: заголовок, краткое содержание, подробное содержание и еще миллиард параметров. Ну нахера? Как минимум один параметр (из набора заголовок, анонс, содержание) лишний. Ну кто будет каждый раз херачить здоровенный пресс релиз, с аносами и приблудами? На самом деле кто то конечно будет, и вот из за них разработчики все это и делают (Алан Купер про концентрирование программистов на исключительных случаях). Разработчики стараются создать швейцарский армейский нож, одинаково подходящих как для сайта компании «1С», так и для ремонтной мастерской в Урюпинске. А в швейцарском армейском ноже, самим ножом пользовать то не удобно.

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

Во всех этих системах видно главенство программистов. Создавая функционал того или иного модуля, они навязывают использование своих стандартов (опять хорошо подходит пример со «стандартными» 3 параметрами новостей). Что в свою очередь уродует сайт, если конечно студийные разработчики не обработают систему напильником.

А бредовость отдельных модулей вообще поражает, например: каталог ссылок. Что это и нахера?

Что касатеся архитектуры систем (не знаю что у них там внутри) они все однотипные. Ну посмотрите чем концептуально отличается Битрикс от УМИ, или Хост от Амиро? Да ничем, та же страница ориентированная структура, такие же модули. Переходя от одной системы к другой, отличия видел одни – другой интерфейс. А принципиально все одно и тоже. «Ну и что?» скажите вы, ну на самом деле ничего такого. Дело в том что мне не понятно, почему никто не хочет попробывать новые подходы и найти новые решения, а не развивать тупиковую страницо-ориентированную архитектуру.

А эти ужасные WYSIWYG. Это вообще кошмар. Сидишь делаешь стили для сайта, выверяешь межстрочные расстояния, заголовки и прочую белеберду которая делает сайт вкусным. А эти WYSIWYGи на все это плюют и генерят свой «могучий» код. А что мне на это отвечают: секретарши с ним проще работать. Ну а результат каков? Плачевен друзья мои, плачевен.
Вкраце суть: все известные мне российские коммерческие системы управления сайтом – не годятся, как базис для создания разнотипных сайтов. Разработчики навязывают свои стандарты информационной архитектуры (которые далеки от совершенства, да и далеки от народа). Хотя CMS априори должна давать гибкость.

Если кому интересно приведу примеры в комментах. Вы называете систему, а я говорю что в ней мне не нравится.

Вообщем я долго мучился с вышеописанными проблемами. Пока не нашел DST Platform. Но это уже другая история