Вышел релиз 4.3 системы управления контентом Drupal

Такое же дерьмо как и все *nuke

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

horoshaya CMS - svoya CMS - ili CMS na zakaz.. a url eto mod_rewrite v apache..

horoshaya CMS - svoya CMS - ili CMS na zakaz.. a url eto mod_rewrite v apache..
---
увы тоже начинаю склонятся к такому мнению, но неужели нет такой ЦМС, чтобы удобно было самому темы (хэх.. дизайн :)клепать?

Хороших CMS вероятно вовсе не существует :) Я пока не нашел ни одной, которая бы по всем параметрам была удобной. По-моему опыту Drupal определенно обходит существующие *Nuke по многим параметрам (но интересно было бы сравнить с Xaraya).

Насчет трюков с URL - да, разумеется здесь задействован mod_rewrite. Однако в тех же *nuke его требуется прикручивать, что судя по количеству сайтов это использующих удается далеко не всем ;) Хотя фича хорошая, не только эргономичностью, сколько хорошим отношением поисковиков к таким сайтам :) - не все поисковики любят разбирать параметры скриптов в URL и ходить по ним. В Drupal это работает "из коробки" - короткие URL без "?" и т.п. и возможность в веб-интерфейсе указывать свои алиасы к любым URL, которые генерит движок.

PHP - язык как язык, имхо можно считать его стандартом для web. Мне больше нравится Python, но если работаешь с web по-моему дешевле выучить PHP, чем пытаться с ним бороться ;)

Собственные движки - конечно рулез, когда есть время и ресурсы на их написание. Или когда задачей стоит создать "движок" рулящий какой-нибудь домашней страничкой ;) Не вижу ничего плохого в тех же расплодившихся *Nuke, если они вписываются в задачу и сайт на них можно сделать быстро и при этом он _работает_, а не глючит как разные необкатанные самопальные решения.

PHP - язык как язык, имхо можно считать его стандартом для web. Мне больше нравится Python, но если работаешь с web по-моему дешевле выучить PHP, чем пытаться с ним бороться ;)
---
ну не знаю, напоминает анекдот про леммингов..

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

Темы кстати выглядят изнутри достаточно просто, по сравнению с реализацией их для разных форумных движков или например PostNuke - мне они показались проще. Хотя идеи в общем похожие. В Drupal идеология по моему впечатлению - PHP everywhere :) На нем завязаны темы, его же предлагается применять на страничках для генерации чего-нибудь нестандартного - т.е. прямо из веб-интерфейса можно создать свой блок на PHP написав в окошке код или сказать, что данная страничка будет не HTML ная, а PHPшная и использовать в ней также PHP. Можно однако без всего этого обойтись даже в темах (как альтернатива там предлагается движок для построения тем на XML - Smarty).

а infoglue не пробовали?

Осталось только дождаться когда темы и модуль weblinks портируют под новую версию :-)

weblinks "лечится" за несколько минут :) - там таблички без поддержки префикса (эту возможность добавили только в 4.3), в остальном успешно работает (на "Русском Debian" например). Надо отослать разработчикам пожалуй поправленную версию, хотя может уже кто-нибудь это сделал. Темы тоже в большинстве своем работают (на упомянутом "Русском Debian" фактически 4.3 стоит, только пререлиз из cvs).

> а infoglue не пробовали?

Нет, infoglue сделан на Java, не люблю я с ней возиться :( (sorry, религиозные предубеждения, ничего объективного :) Если с PHP себя все-таки пересилил и начал в нем разбираться, то в Яву лезть до сих пор не хочется, хотя поводы по жизни были не раз ;) Да и не все хостинги поддержку Java предоставляют.

Если что-нибудь вместо PHP, то скорее Python, хотя он по распространенности в web как-то довольно скромно все еще выглядит. Надеюсь у него еще все впереди :)

Собственный движок есть гуд в любом случае, кроме ограничения времени/денег.
Объяснюсь:
-1. Ресурсоёмкость (поспрашайте хостеров мнение о *NUKE и им подобных)
-2. Определённая тупость движка, как следствие универсальности
-3. Код... Нюки не видел, но начав переделывать Drupal под себя, как-то незаметно написал совсем новый движок... Код Drupal-а без поллитры не поймёшь (ИМХО)
-4. Некоторые идеи переросли себя, в результате чего имеем бредовую ситуацию - node & taxonomy имеем в виде модулей, хотя они, вроде как ядро...
-5. Вы смотрели какое количество запросов у друпала на составление только одной страницы? Пусть даже пустой... Для меня это было последней каплей... =)

Повторюсь, в сравнении с PostNuke и PHP-Nuke (остальные мало смотрел) Drupal выигрывает. В том числе по ясности кода (в отличие от PostNuke пока удается разбираться без поллитры и прочих расширяющих сознание стимуляторов ;) Ноды и таксономия - красивые идеи с отличным потенциалом, но имхо не реализованным еще полностью.

Количество запросов (несколько десятков) к базе обычное для таких движков :) - зависит еще от темы, количества блоков и т.д., имхо, как помню в PostNuke получалось где-то так же. При этом в Drupal можно включить кэш и сократить число запросов в десятки раз. Это только для анонимных пользователей, но учитывая, что анонимусы рулят повсеместно, а не только на LOR, это дает значительное облегчение движку. Я вот заметил, что в запросах большие задержки дает локализация (англоязычным сайтам проще - она им не требуется). Идея хранить переводы вместе со всем остальным содержимым в БД - это конечно красиво, но имхо не особо эффективно. Хорошо что есть поддержка gettext, которую и собираюсь использовать. Впрочем для небольших сайтов это некритично - я бы тоже не дергался, если бы не проблемы с хостингом, хостер временно, но очень сильно ограничил ресурсы, сайты работают со скрипом :( В Drupal это проявилось тем, что при начиная с некоторого не особо большого числа посетителей locale.module не успевал пообщаться с базой и страничка генерировалась не до конца. Пришлось на период проблем выключить совсем локализацию. Когда с хостингом было все в порядке проблем не было, тем не менее решил, что это повод для оптимизации и вот теперь разбираюсь как это на gettext переводить. Выигрыш должен быть значительный, по идее.

Универсальность это однако не всегда минусы. Один раз изучил - применяешь везде. И не надо ничего дописывать/доделывать каждый раз под новые задачи (вру, надо конечно, но не в той степени которая требуется обычно для движков заточенных под что-то конкретное). Баланс определенно нужен между универсальностью и ориентированностью на какой-то круг задач. Drupal по-моему в отличие от многих CMS его еще не потерял и есть четкий круг задач где его применение по-моему удобно. Также как и много задач где он не пригоден и надеюсь разработчикам хватит здравого смысла в эти области не лезть.

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

EZ:
http://ez.no

На нём работает наш сайт: http://it.econ.msu.ru.

Уже больше на нём, супер!

На Zope:
http://www.plone.org/

В смысле больше года.

а как там с настройкой тем?

imho очень неплоха Mambo особенно release-candidate-версии. Проверял на версиях "из коробки" Drupal-4.3.0rc и Mambo-4.5-1.0.2 (rc) -- мамбо была быстрее в разы.

>EZ: >http://ez.no Да, интерсеная весч.

Подходит именно для создания корпоративных сайтов, а не community.

Да, Mambo интересная штука. Мне однако концепции Drupal показались более гибкими. Хотя я не особо вникал в Mambo, чего-то подобного taxonomy не нашел, а в Drupal мне эта концепция понравилась. Описываем произвольные списки категорий (задаем логику) и присваиваем их потом модулям (указываем способы ввода/вывода). Красиво и быстро можно получить например например форумы любой степени вложенности, или общий список категорий для всех разделов сайта.

По скорости Mambo и Drupal не сравнивал, тем более "из коробки" это слишком грубое сравнение - разные по тяжести темы, разный набор блоков и т.д.

Это от меня предыдущее сообщение.

Вот кстати, отчет о работе Drupal под нагрузкой на сайте kerneltrap.org:

http://radio.weblogs.com/0103807/documents/opensource_performance.pdf

Подходит именно для создания корпоративных сайтов, а не community.
---
дык комьюнити никому нах** не нужны. можно ставить нюк и всё... а цмс ИМЕННО для корпоративного сайта (с разделением оформления от содержания).. нет

Нюк уже всех достал, не надо его ставить...

Ну, с настройкой тем в EZ всё очень просто: есть темы, которые присваиваются статьям. У статьи может быть ещё добавочная категория, так что одна и та же статья может попасть в 3 списка.

anonymous (*) (07.11.2003 0:12:42)
> дык комьюнити никому нах** не нужны. можно ставить нюк и всё... а цмс

Ну почему же не нужны? А например этот вот сайт, где ты запостил свою реплику - разве не community? :) Но здесь самописный движок неплохо справляется, а много разных сообществ и интересных проектов, которым такие CMS как Drupal предлагают практически готовое решение и избавляют от значительной возни с подготовкой сайта. Коммерческие проекты могут себе позволить купить _коммерческие_ решения, community как правило - не могут. Предоставлять им помощь куда приятнее, чем удовлетворять смутные коммерческие запросы. Мне во всяком случае эта коммерция "нах** не нужна" и не интересна ;) Хотя тот же Drupal к слову, вполне катит и для некоторых коммерческих решений - по-моему первый сайт который на нем появился в Рунете, как раз сайт какой-то фирмы (juristical.ru)

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

говоря, что комьюниты нах*** не нужны я имел ввиду мертвые комьюнити. знаешь, куча пхпнюков в сети настроенных по дефолту с 10 новостями.. вот такое плохо и дискредетирует.

Мертвые сайты - это не проблема их движков. И на phpnuke настроенном по дефолту сайт может быть посещаемым, если там контент полезный. Тут любой супер-пупер движок, который сам все разруливает не поможет, если энтузиазма авторов сайта хватает на первые пару недель работы ;) Дискредитирует это разве что тех кто сайт такой сделал.

Насчет гибкости - по-моему тут главное, чтобы движок предоставлял простой в понимании API, к которому просто можно прицеплять свои доработки. В Drupal на мой взгляд API пока несложный - с принципами создания модулей под него разобрался за полчаса, на PostNuke для примера ушло побольше времени. Конечно в Drupal есть свои границы, но это достаточно гибкое решение. Разумеется не универсальное. Но под совсем уж нестандартные задачи вероятно имеет смысл что-то свое с 0 создавать, тем более если это для фирмы делается.

спасибо, буду фигачить :-)