Вопрос поднимался и Wowa даже ответил - "для блондинок". Это конечно спорное утверждение, solenko уже говорил - софт выбирает тех-отдел (программисты, админы). И это правильно, менеджер должен ставить задачу, специалисты должны её решать наиболее эффетивным способом, в первую очередь с финансовой стороны, а заглядывание "в будущее" есть один из главных финансовых нюансов.

Вывод - не конечный пользователь, а свой программист или хотя бы админ, будут решать что поставить. Эти люди любят простую установку (время до демки не более часа) и рабочие дефолтовые конфиги. После специалист разберётся в основных деталях, что бы заточить софтину под нужды своей фирмы - он реально будет читать инфу (если нет, то эта фирма без денег, нанявшая студента, зачем вам этот сорняк?). Затем допилит/допишет мелкие детали функционала, пользуясь API движка. Когда проект будет готов, то можно посадить и "блондинку", но она будет "тыкать сцылки" строго по инструкции, что напишет сам админ, эти люди боятся гибкости и возможности "нажать не ту кнопку".

Отпишитесь кто на что смотрит, когда выбирает движок/CMS. Просьба писать как реально было, а не то что считаем "правильным" ;-)
Хорошо бы привести популярные движки, к примеру "Ставил Drupal, понравилось, допилил к нему .... и стало ....".

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

Раньше считал, что страницы как "взвесь", не имеют привязки к какой либо навигации на прямую (могут помечаться тегами). Различные меню собирают страницы воедино, отдавая запросы разным "content handler'ам", но сами не являются чем то необходимым (частью модели). В Joomla всё строиться от меню, создаём узлы, вбиваем содержимое. Заказчица почти довольна 

Плюс: удобно когда содержимое организуется от чего то видимого на странице, наиболее удачно пока древовидное меню. Понятие "у меня где то там N страниц в базе" и выборка по тегам всё таки вещь не удобная.

Не понравилось как движок работает с модулями, "за 10 минут" не напишешь, потребуется долго и муторно регистрировать его в системе. Движок хранит в базе упоминания и конфиги всех своих компонент, достаёт их при каждом запросе. Вёрстка вшита в код движка, что очень мешает.

Улучшить: установка модуля == копирование папки в каталог с модулями, там всё, конфиги, ресурсы и т.п.  Движёк должен всегда уметь видеть свои компоненты, а не только если те каким либо образом зарегистрированы в базе/конфиге. Хотя движёк может создать кешь списка своих компонент, что бы не искать их при каждом запросе. При обновлениях система обходит все свои компоненты и перестраивает этот кеш, заодно проверяя работоспособность своих подсистем (в идеале).


Впечатления:

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

я для лабы выбрал plone.
в лабе делают:
1. проекты
2. курсы
3. семинары

нужно было:
1. документацию и проекты организовать 
2. найти автоматическое решение резервации ресурсов
3. найти решение дискуссий/форумов
4. не заморачиваться с дизайном и разработкой.
5. роли доступа
6. аутентификацию через LDAP( active directory )
7. unicode + RTL (иврит, арабский )

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

воспользовался небезызвестной табличкой CMS из википедии. что проверял:

• xaraya
• drupal
• typo3
• typo
• joomla, mambo
• ez publish
• OpenCMS
• php-Nuke
• MediaWiKi
• Bricolage
• Plone

poчему отбрасывал:
1. неудобный бэкенд
2. плохая поддержка postrgres (если идти в нишу RDMS )
3. долгая история глупых проблем с безопасностью
4. мало модулей/некачественные модули
5. маленький коммьюнити (не достаточно живые проекты выкинул ффтоппку )
6. нет поддержки одного из того что нужно.

Остановился на plone. пока юзаю 2.5, после полного внедрения перейду на 3.0
думаю они шли и идут правильным путём.

Sardar, ты сам определись-то, тебе нужно определить целевую аудиторию или выплескнуть эмоции в виде сочинения "Мой первый раз с Joomla" 

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

Я использовал XOOPS для создания небольшого портала.

Моё субъективное мнение!  

1) модульность
там тоже модули грузятся из БД каждый раз. Но система добавления и отключения модулей 
оказалось достаточно удобной при разработке и при изучении создания модулей *)

2) шаблонизатор
я лично всегда юзал смарти: удобно, быстро как создание так и работа (уж точно быстрее str_replace)
писать свой шаблонизатор или использовать существующий. Лучше готовый.

3) бизнес процессы
безусловно должны быть разработаны как модули

3) ядро
В ядре должен быть реализован класс работы с модулями, класс для раздачи прав доступа юзерям(для каждого модуля) и класс для абстрактного доступа к различным БД,
а также основные библиотеки (типа фреймворка) работы с графиками и т.п.

4) Юзать ли XSL, XSLT хз (и без этого жизнь прекрасна *) )

5) Веб службы
Как бонусы. Вроде не надо, но было бы хорошо. Взять Веб мани. Свой интерфейс для веб служб, и удобно, и просто.

Но может быть самое главное: CMS как ОС будет моноядерной (я так понял про такую разговор *) типа PHPNuke) 
или многоядерной, т.е. отдельно: админка( в том числе всех модулей), индекс (просмотр контента) и ещё чего-нибудь

ezPublish - адский монстр. Поставил, посмотрел, удалил.
UMI CMS - уж очень нравится мне там админка

Чем? Вспомни детали.


2taron123, хорошо бы ты описал стороны XOOPS, идеи по архитектуре лучше в отдельном топе.

Вопервых Дизайн очень сильно привлекает, во вторых 
смотри картинки:
http://slil.ru/25514942
http://slil.ru/25514949

Sardar, не упускай из виду, что софт хоть и выбирает тех отдел, руководствуется при этом он интересами пользователей. 

И если мы хотим написать успешную CMS нам нужно ориентироваться не на тех отдел, а на пользователя и его интересы. 

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

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

Зачастую возникает дилема. То что удобно программисту, абсолютно неудобно пользователю. И наоборот. Самый наглядный пример - Windows и Linux. 
Это возникает потому что у программистов и пользователей совершенно разные задачи и требования. Программисту в первую очередь нужна функциональность, гибкость и т.д. А пользователю удобство, наглядность и интуитивность. А функциональность и гибкость - это противоположность удобству, простоте и наглядности. 

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

Добавлено через 10 минут и 48 секунд

• Drupal 
• Joomla    
• Mambo
• MediaWiki
• PHP-Nuke 
• TYPO3
• Wordpress
• XOOPS
• DotNetNuke
• PHPShop
• WikkaWiki
• OSCommerce

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

Добавлено через 11 минут и 35 секунд
Вот обширный список CMS, для тех кто хочет освежить память. http://www.cmslist.ru/catalogue/

хорошие слова. я думаю, что теоритически ты полностью прав.
Фактически же среди пользователей "все звери равны, но некоторые звери равны больше чем другие"  [Дж.Оруэлл]
т.е. если директору или начальнику что-то нравится больше, то тех. отделу надо будет лавировать между общим знаменателем, и не совсем общим. т.е. может быть это и есть "золотая середина" ? я сумлеваюсь.
Тут мы как раз можем выбрать то направление, которое действительно будет ближе всех к оптимуму для целевой группы.

Теперь о CMS-ках:
То что меня совершенно убило в положительную сторону в plone, то что она придерживается стандартов не только кодинга и хорошего дизайна в софте, но и в пользовательском интерфейсе.
Всё масштабируется, организованы на странице объекты очь правильно, есть кномпочки увеличить/уменьшить текст, перейти на другой язык. очень цельный стиль и вообще юзебельность очень высокая:

• контент хорошо организован [повторяюсь]
• редактор в стиле WYSIWYG
• плоноэкранное редактирование (остается только редактируемая часть)

всем превед.

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


IMHO это миф, что удобно мне, обычно удобно и моей маме. Впрочем обратное утверждение не всегда верно 


По теме, за последние пару лет заметил, стандартный движок по началу обычно покрывает до 80% потребностей, потом он всё больше обрастает собственными расширениями. Поэтому важно, что бы внедрение нового модуля было как можно проще, без регистрации его в десятке конфиг-файлов и прописывания в базе. Второе: вёрстка не должна быть вшита в код, это очень мешает. Всё равно многие вещи, например WYSIWYG редакторы, листинги меню и прочее обычно меняется на что-то более удобное, очень важно что бы процедура модификация движка была предельно проста. Это всё можно отнести к минусам Joomla постом выше, для меня это самый важный критерий выбора.

Joomla!
Сразу должен предупредить, что работал довольно таки давно, так что если что-то изменилось -- поправьте
Плюсы:
1. Легкость управления и первоначального освоения
2. Большое community и, как следствие множество модулей и готовых тем.

Минусы:
1. Верстка прошита в модули, а в некоторых модулях даже не разделена с логикой (отношу это к проблемме CMS, т.к. joomla не преподносит разделение как философию)
2. Уж очень жесткая привязка к меню (никто не пробовал сделать стартовую страницу и первый пункт меню разными?)
3. Жесткая структура URL'ов
4. Очень громоздкие модули для админки
5. Невозможно единообразно управлять контентом

Drupal:
Плюсы:
1. Система каталогизации контента (taxonomy) -- в двух словах не рассказать
2. Единообразное обращение к любому контенту (статья, это в первую очередь контент, а уже потом статья. Для видео, например, так же)
3. Возможность влиять на поведение модулей не влезая в код самого модуля (что потом позволяет обновлять основные модули не переделывая доработки)
4. Многосайтовость с возможностью своего набора модулей для каждого сайта.
5. Возможность задавать урл для каждой страницы (и есть модули, которые это автоматизируют)

Минусы:
1. Сложен для начального понимания
2. Тяжеловесен. Слишком много обращений к базе на одной странице.
3. Усложнена работа с несколькими БД для одного сайта -- соединение с базой хранится не как поле объекта, а как глобальная переменная.

Резюме:
Joomla:
Легка в освоении и управлении, но начинает мешать на сложных проектах. Идеальна для сайтов, основная направленность которых публикация статей и новостей.
Drupal:
Сложен в освоении, нет смысла применять для простых сайтов. На сложных проектах  требует более-менее квалифицированного персонала для обпровождения (я имею в виду, что на обучение девочки-секретря потребуется не 30 минут, а 4-6 часов)

Добавлено через 5 минут и 1 секунду
bilbobagginz, 

Вы не могли бы рассказать как именно, по каким принципам?

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

основной нажим на "интерфейс, который не нужно объяснять".
детальнее это не объяснить без скриншотов.

можно сказать так: множество маленьких деталей дизайна, которые вместе сливаются в общий "юзер экспириенс"