LINUX.ORG.RU

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


0

0

CMS ориентирована в первую очередь на построение community-сайтов - блоги, форумы, возможности коллективной модерации и рейтингования контента. Среди юниксовых сайтов этот движок можно видеть например на kerneltrap. org, debianpla net.org, kded evelopers.org. Отечественных сайтов пока совсем мало (разве что русск ий клуб пользователей Debian). Из интересных возможностей CMS: встроенная поддержка коротких URL, чтобы не показывать длинных плохозапоминающихся адресов (камешек в огород linux.org.ru ;) и URL-псевдонимов (можно заменить практически любой URL создаваемый CMS на собственный вариант), оригинальная схема задания логической структуры сайта - т аксономия. CMS в активном развитии и еще больше изменений ожидается к следующему релизу, который выйдет вероятно где-то к весне следующего года.

>>> Подробности



Проверено: maxcom

Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

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

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

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

axel
() автор топика
Ответ на: комментарий от axel

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

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

anonymous
()
Ответ на: комментарий от axel

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

axel
() автор топика
Ответ на: комментарий от ivoronin

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

axel
() автор топика
Ответ на: комментарий от anonymous

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

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

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

axel
() автор топика
Ответ на: комментарий от axel

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

xlex
()
Ответ на: комментарий от xlex

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

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

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

axel
() автор топика
Ответ на: комментарий от axel

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

axel
() автор топика

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

axel
() автор топика
Ответ на: комментарий от axel

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

anonymous
()
Ответ на: комментарий от axel

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

anonymous
()
Ответ на: комментарий от anonymous

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

axel
() автор топика
Ответ на: комментарий от anonymous

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

axel
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.