Какая CMS лучше?

Та, которая подходит под конкретную задачу.

которая mvc 8]

для корпоратива joomla, для новостного ресурса wordpress. если нужно будет допиливать - CMS-фреймфорк (django и прочие).

>для корпоратива joomla

Пых в корпоротиве/энтерпрайзе? Не характерно.

видел и Zope и Plone, вполне себе. Да и Django/Pylons/TG ничуть не сложнее.

Та, что в среднем потребляет меньше ресурсов.

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

joomla хороша для небольших и средних фирм, которым в вебе визиточку выложить, пару статей, каталог товаров (без вебмагазина), новостную ленту. в общем, покрывает потребности 90% фирм.

>для корпоратива joomla
ха-ха

>для новостного ресурса wordpress
это кривое школьное поделие годится для чего-то кроме локалхост-блога?

по теме - от задачи зависит.
в большинстве случаев лучше взять Zend/Catalyst/django и состряпать нужное самому.

первый вариант - ок.

второй - еще раз ха-ха. под визиточки берется простенькая [самописная] цмс-ка, а не монстрокомбайн жрущий ресурсы.

> в большинстве случаев лучше взять Zend/Catalyst/django и состряпать нужное самому.

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

> простенькая [самописная] цмс-ка, а не монстрокомбайн жрущий ресурсы.

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

Заглянул недавно внутрь джумлы - до сих плююсь. Типичная "радость студента". Корпоратив, буагага. Это корпоратив в стиле "русский бизнес" - когда один ушел искать вагон тушенки, другой чемодан долларов а третий пошел ставить джумлу.

впрочем, не совсем понятно зачем именно топикпастеру ЦМС - может ему и вправду джанга и подобное подойдет больше.

А "самописные CMS" это вообще какой то "я у мамы программист". Вам в детстве программировать запрещали и вы никак не накодитесь в волю ?

> Это корпоратив в стиле "русский бизнес" - когда один ушел искать вагон тушенки, другой чемодан долларов а третий пошел ставить джумлу.

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

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

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

wordpress страшен, не надо его использовать :}

Если что-то довольно большое, то можно допилить админку джанги, у нас так и сделали.

> мы потратили месяц на разработку маленькой шустренькой...

то есть мало того что месяц, так еще и "мы"?

> ровно столько же было бы потрачено на изучение допиливание джумлы (от шаблонов которой до сих пор тошнит, кстати).

у меня на шаблон джумлы уходит день от силы. потом день-три на занесение материалов. все.

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

но вот скажите мне, зачем этим http://www.oao-ratep.com/ делать свою ЦМС?
или вот - крупнейший в Европе комбинат по обогащению урана (деньгами ворочают неимоверными) - http://vostgok.com.ua/ (дизайн дерьмище еще то - но кому какое дело).

естественно, визивиг (tinymce), немного аякса (всякие драг-н-дропы для переупорядочивания)

ой не надо. вордпресс вполне мебе неплох. мало того, на днях наткнулся на материалы по поводу того, как его в kohana скрестить - так вообще краса получается.

вы, простите, в исходники его заглядывали?

про "месяц" и "мы" - "мы" = фирма, в данном конкретном случае "мы" = дизайнер, верстальщик и я. и фреймворков там не используется, т.е. всё с нуля.

нет, в исходники вордпреса я не смотрел. немного меня напрягают их шаблоны - но не в этом суть.

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

но если для фирмы сайт - это визитка с контактами и каталогом продукции - на кой им свое городить?

Все встречающиеся сайты на нём как-то не порадовали. И в плане вёрстки в том числе. Без понятия, может «повезло», но опыт такой.

> А как по мне - это когда за копейки можно получить пристойную визитку
> в инете.

А я согласен с тем что для этого как раз в том числе FOSS CMS и нужны.

PS
Но вот жумла ваша полный г. Ужос как postnuke.

> ровно столько же было бы потрачено на изучение допиливание джумлы (от
> шаблонов которой до сих пор тошнит, кстати).

Джумла это г., но вы неправы.

Тут идея не в том что бы с нуля изучать Джумлу. И соревноватся в этом с написаннием с нуля CMS. Это бред.

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

> Но вот жумла ваша полный г. Ужос как postnuke.

какие есть альтернативы?

> взяли некий нормальной FOSS CMS и на нем уже сделали некое количество сайтов, то очередной пройдет гораздо быстрее

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

> какие есть альтернативы?

Холиварные :)

Друпал.

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

>Друпал.

Пардон, что вмешиваюсь, но системы не имеющие MVC должны иметь очень мало шансов на жизнь :)

> а что, друпал не плох. только шаблон в нем верстать тяжелее чем в
> джумле.

Там были какие то попытки сделать theme engine что бы темы были как в джумле но по моему его никто особенно не использует и до массового примения дело не дошло. Наверное оказалось ненужным...

А что вам кажется там таким сложным в средних друпаловских темах - три-четыре файла и css :) ?

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

> Пардон, что вмешиваюсь, но системы не имеющие MVC должны иметь очень
> мало шансов на жизнь :)

А ООП не совсем заховало ваш мозг ? В друпале есть MVC согласно описанию из википедии. Там оно только не отморожено-обьектное и не кристалльно чистой сепарации на M V и C. :)

Там вообще очень практичная система, без доминирования концепции над реальностью.

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

Это какая еще часть движка, в каком смысле ? :)

Там вот API для шаблонов меняется, и это требует аудит шаблона, да. Но так вся идея именно в том что там шаблоны плотно натягиваются на структуру, а не находятся на "отдалении".
Соотвественно если то что темизируют меняется - меняется и шаблон.

А насчет запутанности - так весь друпал немного такой. :) Немного хитрый для продвинутого изучения. Да и альтернативные "простые" энжины популярности не получили.

>В друпале есть MVC согласно описанию из википедии. Там оно только не отморожено-обьектное

О какой отмороженности и объектности может идти речь, когда генерация HTML идёт прямо внутри PHP? И, ладно бы это для скорости особой было бы применено, но, ведь, тормоза подобного Друпалу поискать... В итоге:
- Скорость хреновая
- Модульность хреновая
- Расширяемость никакая
- Шаблоны невразумительные

Что в нём ещё остаётся после этого? :)

>Там вообще очень практичная система, без доминирования концепции над реальностью.

Да нет, там, как раз, в логике системы - доминирование концепции над реальностью, а в коде нет никакой концепции вообще.

Вот за подобные системы нормальные программисты PHP и за язык-то не считают :)

вот этот самый API меня и смутил. у джумлы тоже есть нечто похожее - но в более тривиальной реализации.

> когда генерация HTML идёт прямо внутри PHP? И, ладно бы это для
> скорости особой было бы применено,

Вот оно, то самое доминирование концепции над реальностью. В php изначально встроена поддержка темплейтов путем применения самого php. Ну и кому это мешает ? Но нет же - надо что обязательно было все раздельно "не внутри PHP", что бы удовлетворить "принципу раздельности" Иначе некошерно. :)

> но, ведь, тормоза подобного Друпалу поискать... В итоге:

В своем классе он быстрее аналогов. Есть независимые тесты. :)
И да - за универсальность расплачиваемся скоростью. Нужно быстрее - кеширование и оптимизация позволяют разогнать друпал на конкретной задаче до нужной скорости. Чему есть много пдтверждений создания на друпале сложных и нагруженых сайтов.

> - Скорость хреновая
> - Модульность хреновая
> - Расширяемость никакая
> - Шаблоны невразумительные

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

И кстати насчет расширяемости c модульностью - моя телепатия подсказываети что под расширяемостью вы имеете в виду использование друпал даже вообще не как CMS :) Так вот - это хоть и CMF но там CMF для CMS а не для хитро^%$%банных вебприложений. Для этого вперед к питону и прочей яве.

> Что в нём ещё остаётся после этого? :)

Все что вы перечислили только со знаком плюс :)

> Да нет, там, как раз, в логике системы - доминирование концепции над
> реальностью, а в коде нет никакой концепции вообще.

вот это уже интересно - это какая же концепция там в логике которая не в коде ?

> Вот за подобные системы нормальные программисты PHP и за язык-то не
> считают :)

Нормальные программисты последнее время вызывают у меня странное чувство отторжения. Своей тягой программировать там где это не просто не нужно, но и вредно. :) Прямо набигают, тысячи их, и начинают программировать как бешенные. А потом ноют что им не платят денег ;)

>>это кривое школьное поделие годится для чего-то кроме локалхост-блога?

А на твое поделие столько денег вложили? Вот сиди и молчи в тряпку, быдло

А на жабе CMS есть?

да, толстячок.

А почему про drupal никто ничего не говорит?

>В php изначально встроена поддержка темплейтов путем применения самого php

Как думаешь, зачем придумали Vala, если он занимается трансляцией в GCC и зачем придумали GCC, если он занимается трансляцией в ассемблер? :)

>Но нет же - надо что обязательно было все раздельно "не внутри PHP", что бы удовлетворить "принципу раздельности"

И тут ты не прав. Шаблонизаторы в нормальных системах - отдельные модули. И могут использовать разные компоненты. Даже в рамках одного проекта. Принцип раздельности тут не первичен, а вторичен. Первично - удобство программирование и отладки.

>И да - за универсальность расплачиваемся скоростью.

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

>Сплошное 4.2 и "о вкусах не спорют".

Только если ты не видел нормальных систем :)

>И кстати насчет расширяемости c модульностью - моя телепатия подсказываети что под расширяемостью вы имеете в виду использование друпал даже вообще не как CMS :)

CMS - это конкретное решение. Если речь идёт о расширениях - то мы уже автоматически выходим на уровень CMF.

>вот это уже интересно - это какая же концепция там в логике которая не в коде ?

Таксономия.

>Нормальные программисты последнее время вызывают у меня странное чувство отторжения. Своей тягой программировать там где это не просто не нужно, но и вредно. :) Прямо набигают, тысячи их, и начинают программировать как бешенные.

Это ты видел не нормальных программистов, а быдлокодеров. Нормальные программисты пишут по десятку (одному) строк в день и им этого хватает :)

> Как думаешь, зачем придумали Vala, если он занимается трансляцией в
> GCC и зачем придумали GCC, если он занимается трансляцией в
> ассемблер? :)

И ? Очень намекающе намекаешь, ничего не понять.

> И тут ты не прав. Шаблонизаторы в нормальных системах - отдельные
> модули.

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

Тут я тебя потерял. Какие именно разные компоненты ?

> Принцип раздельности тут не первичен, а вторичен. Первично
> - удобство программирование и отладки.

Ага ага. Удобство _программирования_. Понимаешь, удобство программирования первично именно в том случае когда надо много и со вкусом программировать. А это нужно когда тебе не подходит репозиторий в овер 2к модулей и ты пишешь сайт фактически с "нуля". И тебе нужны не модули друпала которые предоставляют функционал сразу пользователю, а всякие "компоненты" и "классы", гибкость которых ты меряешь по степени доступных с ними программистских извращений. Программистский подход ко всему.

> У Друпала универсальностью и не пахнет. Узкозаточенный,
> нерасширяемый, неинтегрируемый.

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

> Только если ты не видел нормальных систем :)

Приведи пример. Уже боюсь фреймворков на лиспе написанных жестоко overqualified программерами сокращенными из ИИ лаб вследствие budget cut.

Это кстати вообще проблема человечества - когда какой нибудь форум в интернете делает сокращенный из узконавороченой области лисп(форт :) )-уберпрограммист. Он там не на месте. :)
Так как в результате мы получаем не доступный любому для чтения код, а хрень понятную исключительно после прочтения горы талмудов, зубрения жосткого матана и овер 10 лет опыта в индустрии.

> CMS - это конкретное решение. Если речь идёт о расширениях - то мы
> уже автоматически выходим на уровень CMF.

Вот вот. Уже подозрительно.

> Таксономия.

Считаете что если таксономия в дистрибутиве, значит это было "по дизайну" ?

Разочарую - таксономия там как популярный аддон. По этому его "внутри" и нету. Вообще друпал почти весь это "популярный аддон". Из 29 модулей дистрибутива лично я использую 8, все остальное это невходящие в дистрибутив расширения.

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

> Это ты видел не нормальных программистов, а быдлокодеров. Нормальные
> программисты пишут по десятку (одному) строк в день и им этого
> хватает :)

Это я боюсь не нормальные программисты :) а редкие исключения. Смотря что считать нормальным, как говорится. :)

PS
Да и не уверен что нормальным программистам в вашем смысле место в вебдевелопменте, за исключением мест вроде яндекса(речь про зону .ру).

> А почему про drupal никто ничего не говорит?

КРОН73 говорит что он очень плох :)

>И ? Очень намекающе намекаешь, ничего не понять.

Поясняю. Люди ленивы. И поэтому сложные решения упрощают.

>И в друпале отдельные.

Да ладно. Т.е. он в качестве шаблонизатора может использовать произвольный движок? Ткни в пруфлинк.

>Тут я тебя потерял. Какие именно разные компоненты ?

Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то что удобнее на PHP - на PHP. Можно так?

>Понимаешь, удобство программирования первично именно в том случае когда надо много и со вкусом программировать.

Демонстрация полного отсутствия опыта программирования или непонимание вопроса. Удобство программирования первично всегда, когда приходится программировать. Точка. Если тебе для решения одной задачи в одном случае нужно написать 10 простых строк, а в другом 50 сложных, то в первом случае мы имеем более удобную схему при любом раскладе.

>Это я боюсь не нормальные программисты :) а редкие исключения

Не знаю. Вот лет 10 назад видел статистику. Что среднетемпературный по больнице программист пишет в день в среднем 8 строк. Это если число строк проекта разбить на число дней его разработки. При чём эта величина мало меняется от языка к языку - на более выразительных языках просто продуктивность выше получается.

...

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

>КРОН73 говорит что он очень плох :)

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

> Поясняю. Люди ленивы. И поэтому сложные решения упрощают.

То есть ты считаешь что применение PHP внутри PHP по прямому назначению это сложно ? Я правильно понял ?

> Да ладно. Т.е. он в качестве шаблонизатора может использовать
> произвольный движок? Ткни в пруфлинк.

Лично я об этом узнал из сорцов - файл include/theme.inc и каталог
themes/engines где один подкаталог phptemplate соответсвующий любимому всеми движку на нелюбимом тобой принципе. Другие произвольные движки реализуются имплементацией вызовов соотв функций в этом самом движке.

Хотя вот, погуглил - сам удивился. http://drupal.org/node/176129
Даже смарти твой есть - чему собственно и удивился.(Да, естественно чтобы любой движок прикрутить надо модуль прикрутки писать и все такое.)

> Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то
> что удобнее на PHP - на PHP. Можно так?

Можно. Но мне такая потребность в голову не приходила. Даже поломал немного голову как это было бы удобно сделать.

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

> Демонстрация полного отсутствия опыта программирования или
> непонимание вопроса. Удобство программирования первично всегда,
> когда приходится программировать. Точка. Если тебе для решения одной
> задачи в одном случае нужно написать 10 простых строк, а в другом 50
> сложных, то в первом случае мы имеем более удобную схему при любом
> раскладе.

Неа, не при любом. Если у тебя есть овер 9к модулей которые уже отлажены и неплохо стыкуются друг с другом, то для определенной группы задач не важно 10 строк или 50. Так как ну будет у тебя в другой системе 100 строк связки вместо 500 на неудобной. И 10М строк для написание тех модулей которых в "удобной для программирования" системе нет. А есть в неудобной.

Ну и мерять удобство строками кода это тоже не совсем правильно. Ну напишет там какой perl-изверг или крейзи-хаскель 10 строк больше похожих на tty мусор, и ? Спасибо, лучше уж я в системе поработаю где таких суперпрограммеров нету, а есть 50 срок просто и понятно.

> Не знаю. Вот лет 10 назад видел статистику. Что среднетемпературный
> по больнице программист пишет в день в среднем 8 строк. Это если
> число строк проекта разбить на число дней его разработки. При чём
> эта величина мало меняется от языка к языку - на более выразительных
> языках просто продуктивность выше получается.

А, ты про это ! Я уж подумал что ты про тех программистов что реально садятся и каждый день не больше 10 строк пишут. Напишут там 10 строк и идут в гольф играть :)

А у среднетемпературного программиста 10 строк получаетс когда он сначала много много кодит а поттом они всей больницей баги ловят месяцами.

>того, что я могу неделю почти ничего не делать, а пото за ночь
> сделать недельную "норму" :))

Я все таки думаю что у тебя твои 8 строк статистически получаются. Или вес таки 8 строк а потом гольф ? ;)

> Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то что удобнее на PHP - на PHP. Можно так?

А зачем? Смарти избыточен. Ничего ровным счетом не даёт, то есть вообще ничего. Только отжирает ресурсы.

Существование смарти вообще опровергает твой тезис по поводу стремления людей к упрощениям :) Зачем писать пхп на пхп и вызывать его из пхп, когда можно просто использовать пхп? :)

>А зачем? Смарти избыточен. Ничего ровным счетом не даёт, то есть вообще ничего. Только отжирает ресурсы.

Поскольку у меня сейчас и Smarty, и Pure PHP используются равнозначно, есть, как бы, приличный опыт использования и того, и другого на одной задаче.

Smarty в подавляющем большинстве случаев компактнее и нагляднее (и, в отличии от PHP, является валидным с точки зрения синтаксической подсветки, он не требует писать невалидных конструкций вида alt="<?=$alt?>"). А дальше - самое смешное. Я PHP-шаблонизаторы вводил для особо критичных по скорости мест. Оказалось - фигня. Потеря производительности редко превышает 10-20%. Всё же, Smarty не интерпретируется, а компилируется. Так что на PHP сейчас пишу только там, где реально получается проще (когда логика представления _очень_ сложная) или когда скорость важна настолько, что даже эти 20% - существенны.

>Зачем писать пхп на пхп и вызывать его из пхп, когда можно просто использовать пхп? :)

Зачем писать Python на Си и вызывать его из Си, когда можно просто использовать Си?