Комментарии

Очень хорошие, мотивирующие советы. Главный совет — доводите начатое до конца и все получится

Большое спасибо за подробную статью о 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 года