» CMS Drupal

Цитата:

До чего же мне нравятся некоторые фишки на форуме ru-board Хотя бы это грамотное слияние сообщений от одного пользователя в одно, вместо заведения новых комментариев. Рулез.

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

Harzah

Цитата:

Кстати, Textile в Drupal тоже есть, причём двух версий одновременно, можно выбирать или ту или другую или все вместе...

А мне Textpattern не только из-за Textile нравится ;-) Textile сейчас только ленивый не подключает.

Кстати, господа админы, почему бы не подключить Textile к ru-board?

Ну, а как Drupal не сильно хуже, чем Textpattern? Просто, я надеюсь, что у Drupal всё-таки есть что-то такое, за что отказаться от него просто невозможно? Мне вот например понравилось то, что аватары можно использовать в каждом документе (ссылках, статьях, форумах, блогах), несмотря на то, что сделать это вроде не сложно, других cms, которые предоставляют такую возможность - я не видел...

Harzah

Цитата:

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

Среди бесплатных — последние версии Textpattern, а среди платных тоже есть.

Цитата:

Среди бесплатных — последние версии Textpattern, а среди платных тоже есть.

Среди платных, назови, если нетрудно, хоть одну, просто, чтобы знать... Хотя я думаю, таксономия+ноде+коммент (или аналогичное) точно мало у кого есть... Или я не прав? Во всяком случае, из бесплатного я перепробовал почти всё...

А чем Textpattern лучше, чем Drupal? Какие в ней есть особые фичи, которых в Drupal'e нет? Я именно спрашиваю конкретно для сравнения между обоими cms, а не просто по Textpattern...

Harzah

Цитата:

Среди платных, назови, если нетрудно, хоть одну, просто, чтобы знать...

Bitrix, s.Builder


Цитата:

А чем Textpattern лучше, чем Drupal? Какие в ней есть особые фичи, которых в Drupal'e нет?

В ней просто другая философия и идея. Textpattern и Drupal нельзя сравнивать просто из-за того, что это разные весовые категории — портал и блог, и потому, что Drupal уже в 4+ версии, а Textpattern только в gamma-версии.
Я бы не сказал, что из Drupal выйдет удобный блог, а из Textpattern — полноценный портал.

fathersGrave
Спасибо. Мне, в принципе, блог не нужен... но раз он есть в Drupal'e - то пусть будет. А вот всё остальное мне как раз нужно... Статьи писать, заметки всякие... и главное чтобы удобно всё было - это главное...

расскажите что такое Textpattern и Textile.
я вот раньше и нюку ставил и вики разные но только на друпале остановился )

надо мне только дезайном заняться. никто не хочет помочь?

Zepplock
Textile — лучшая альтернатива bb-коду. Автоформатирование текста в xhtml. Синтаксис типа *bold*, _emphasys_, +подчеркивание+ и т.п. Класс встраивается в любое приложение. Попробовать можно здесь.

Textpattern — cms от автора Textile с встроенным же Textile ;) CMS имеет явную ориентацию в сторону блога, но не делает упора на дату сообщений, и соорудить "статический" сайт просто элементарно. На ней даже е-магазины делают: нужно только написать плагин корзины и оформления. Шаблоны xhtml+css => можно valid, никаких проблем с созданием нет.

Короче, очень масштабируемая система. Читай подробнее на офсайте.

Спасибо. Попробуем.

Цитата:

Textile — лучшая альтернатива bb-коду. Автоформатирование текста в xhtml. Синтаксис типа *bold*, _emphasys_, +подчеркивание+ и т.п. Класс встраивается в любое приложение.

Не знаю ничего лучше, чем bbcode. И "изобретение велосипеда", на мой взгляд, тем более такого велосипеда как textile, ничего не решает. На мой взгляд лучше пользоваться или обычным html или bbcode, а всякое усложнение ни к чему хорошему не ведёт. Конечно, каждый пользуется тем, чем хочет, но главным остаётся всё равно размещение информации и комментирование её различными способами, а всё остальное, в том числе и форматирование - вторично.

Harzah
Если будем выражаться в колесной технике, то Textile — это не изобретение велосипела, а изобретение мотоцикла или мопеда.. какая разница?
Важно другое:

- bbcode форматирует в чистом xhtml или применяет указанные стили?
Нет

- скорость набора в bbcode?
Если все время то тыкать мышкой в автоподстановку кода, а потом тянуться к клаве, то не серьезно. Если набирать самому [no] , [url] [/no] — итого около 3-6 символов на оформление одного открывающего тега — то тоже долго.
Textile позволяет увеличить скорость набора, используя теги из спец.символов, например: *[b]жирный*, @код@ и т.п. Таким образом человек может набирать текст, не отрываясь от клавиатуры и особо не отвлекаясь на форматирование.

- про html
Если кому-то легче набрать <strong>ляля</strong>, чем *ляля*, то у этого кого-то очень странное понятие о юзабилити...

Мне даже xml не нужен, не то что xhtml, неважно, чистый он там или нет. Для форматирования и разных стилей мне css достаточно. Также и насчёт отображения документов. Сколько ни поют дифирамбов этому xml (и будущему xhtml) всё равно на мой взгляд с ним одни проблемы. Отображение отдельно от содержания - это конечно хорошо, но, если использовать xml, то этого не будет, будет привязка содержания и отображения к xml, а зачем мне это нужно? Чтобы избавиться от этой привязки уже к xml опять нужно будет форматировать документ...

Теперь о textile. Я не спорю, что для английского языка это неплохое приобретение. Но для русского - вряд ли. Каждый раз надо переключать раскладку клавиатуры, чтобы выделить что-то жирным цветом... По-моему, один раз ткнуть мышкой в автоподстановку гораздо проще...

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

Harzah

Цитата:

Почему собственно "@" это жирный?

Цитата:

например: *жирный*

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

Цитата:

Для форматирования и разных стилей мне css достаточно.

Вот Textile как раз и позволяет указывать классы и селекторы стилей через элементарную разметку.

Цитата:

Отображение отдельно от содержания - это конечно хорошо, но, если использовать xml, то этого не будет, будет привязка содержания и отображения к xml, а зачем мне это нужно?

http://www.csszengarden.com — xhtml везде один, при переключении дизайна меняются только файлы стилей. И что большая это привязка, ограничивает она возможности для дизайна?
Еще можно почитать про XML, XSLT и SVG, но, видимо, с такими консервативными взглядами это бессмысленно.

Проблема в том, что в чистый текст вставляются теги xml. И их там много. Я вообще просто за чистый текст, если честно. Жаль, что нельзя выдумать такую технологию, которая позволяла бы без правки самого текста форматировать его. Вот это бы была революция, а все эти xml xhtml и textile - это всё одно и тоже...

Harzah
Это все мечты, а пока что xhtml и xslt технологии обеспечивают наиболее гибкую привязку к форматированию, чему указанный выше сайт и является подтверждением.

Против CSS я, кстати, ничего и не имею. Согласен с тем, что вот это как раз была замечательная идея, отделить контент от дизайна. Хотя вставка посредством того же rel link на медленных серверах или просто, если до сервера далеко позволяет увидеть совсем голый текст без всяких цветов, то есть, текст без CSS, что некрасиво.

Поэтому вставку css-файла лучше всего делать или через import или вставлять его другими средствами, например php.

Harzah
С относительными ссылками на тормозных серверах narod.ru у меня не было никаких проблем. А то, что стили лежат на другом серваке, решается элементарным их переносом. Хотя, максимальное время задержки перед загрузкой стилей за весь мой серфинг не превышало 2 секунд. Можно потерпеть? ;-)

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

Это же основы CSS. CSS и сделан был для того, чтобы сайт был красивым. Сейчас многие уже стали использовать import, благо его уже все основные браузеры поддерживают... Да вот, не надо далеко ходить: у Drupal одна тема сделана с применением import, другая с rel link, первая никогда не смотрится плохо, а вот вторая бывает так, что виден голый текст...

Harzah

Цитата:

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

Они просто не могут ее учесть, потому что стили и графика(!) лежат непосредственно у их авторов(то есть они могут в любой момент все убрать, подкорректировать и т.п.).

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

Harzah
Т. к. Вы знаток этой CMS, вопрос к вам.
Стоит ли затевать перевод на Drupal сайт работающий на PHP-Nuke, юзеров -- 13.000, форум -- 53.000 и форум оснавная часть сайта? Знаю что отработанной схемы перехода ещё нет, да и форум на Drupal несколько сыроват. Так ли это?

Цитата:

Стоит ли затевать перевод на Drupal сайт работающий на PHP-Nuke, юзеров -- 13.000, форум -- 53.000 и форум оснавная часть сайта

Перевод имеет смысл для небольших форумов, которыми рулит один админ или несколько модераторов с равными правами, для средних как в вашем случае (активность судя по отношению сообщений к юзерам не высокая, но сообщений достаточно много) уже стоит задуматься. Я склоняюсь к тому, что рановато - в форуме Drupal отсутствуют средства модерации (т.е. можно конечно админить сообщения средствами CMS, но например средств массовой модерации нет вовсе), нет разграничений прав по форумам (без установки доп. модулей типа groups или term_access) - т.е. работать все это будет, но рулить будет неудобно. А для больших форумов точно нет смысла пока соваться. Drupal - отличная CMS, но форум в ней еще предстоит сделать хорошим Сейчас например активно развивается функциональность блогов, в будущем и до форумов доберутся.

PS. На http://drupal.ru поднят новый движок - 4.4.1 (последняя стабильная версия) и некоторые изменения в дизайне (на всех страничках кроме главной убраны боковые блоки - теперь вид сайта похож на какой-нибудь форумный скрипт с прицепленной к нему "портальной" мордой

gregor
Да, я согласен с тем, что Drupal пока не готов к тому, чтобы на нём развёртывались форумные баталии. Модераторов назначить нельзя, а значит и форум для большого количества участников не подходит.

Пока, Drupal - это больше CMS, чем форум. Но например ни одна СMS (из мною виденных) не имеет возможности, например, перенести статьи в форум или запись блога в форум. А Drupal потенциально эту возможность имеет, потому что форум здесь полностью интегрирован в CMS, это просто другой раздел собственно говоря. Так что с точки зрения управления информацией - Drupal лучше подходит для сайта, чем PHPNuke не смотря на отсутствие функций модерирования.

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

Насчёт конкретного вопроса, про "сыроватый форум" отвечу, что он не сырой, он нормальный. Просто в Drupal'e нету такого разделения на "форумы" и на "блоги" и прочее, здесь всё разделяется по возможностям. Есть возможность комментирования, есть возможность разделов, но нет возможности модерации. Когда эта возможность появится, то она будет работать для всего Drupal'a, а не только для форума...

Добавлено

Цитата:

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

Почему же неприлично? Они рекламируют CSS, хотят, чтоб везде было всё красиво и правильно, ну так надо идти на какие-то жертвы. Иначе из рекламы - это превращается в антирекламу. Люди смотрят и думают, что CSS - это некрасиво. Тем более, что картинки, я больше чем уверен, не займут больше, чем 100мб места. Не так уж это и много, чтобы показать красоту...

У меня вопросы спецам по Drupal

1. Какой механизм компиляции пользовательской разметки там используется. Хранятся отдельно исходный текст и скомпилированный. Или компилится на лету. Или декомпилируется для редактирования? Если первый вариант - то просто замечательно. Если нет - то опять досадная фичность, которой страдают все современные форумы и CMS, из-за которых их потом приходится грубо хачить...

2. Может ли быть у ноды более одного родителя. Т.е. опять тупое дерево, или же, наконец, направленный граф? (На самом деле полноценную графовую систему я делаю для своего сайта, но до "релизного" варианта ещё далеко.)

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

Не могу сказать, что я такой уж большой специалист по Drupal, но на некоторые вопросы отвечу. Мне просто нравится логичность построения структуры этой CMS, но логика в стратегии развития и здесь также далека от программистов, как и везде в других продуктах.

1. Насколько я понимаю речь идёт о выдаче текстов? Да, к сожалению, должен вас огорчить, Drupal - это полностью динамичная CMS, фильтры и всё вообще здесь создаётся на стадии выдачи документа пользователю (это хорошо, конечно, потому что всё изменяется "налету"), что в тоже время иногда приводит к некоторой "медлительности". Для минимизации этого недостатка, опять же, используется кэш БД (хорошее решение, на самом деле и мало где используется), что на мой взгляд если и повышает скорость выдачи документов, но зато, в свою очередь, добавляет ещё больше проблем увеличивая нагрузку на БД. А если ещё прибавить сюда то, что буквально всё хранится в БД (в том числе и переводы и хелпы), то получается достаточно грустная картина.

Локализация такая же, динамическая. То есть, прямо в тексте модулей, ядра и всех скриптов разработчики пишут текст (на английском) потом его можно перевести на любой другой, но всё это хранится в БД, английский текст заменяется на неанглийский динамично, потом это кэшируется, но на больших сайтах модуль locales (который всем этим занимается) иногда занимает очень уж много памяти, до 30-40%. Есть правда и альтернативные варианты, ввиде .po файлов. Но пока это не всегда и не везде работает и не поддерживается официальными разработчиками.

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

3. Нет, скорее всего, Drupal - это не объектная среда, здесь нет собственно говоря и объектов. Здесь есть только документы, которые соотносятся с определённой таксономией, а она с модулями. Более того, нет отдельных элементов, для которых возможно было бы создать какие-либо параметры. Так, например, чистый текст в определённую папку не положишь и не применишь к этой папке какие-либо параметры. Хотя подобный модуль, я думаю, можно будет написать, но на этом не строится структура Drupal'a. Зато, например, существует разделение по таксономии. Если и можно создать объектную модель, которая бы нормально работала, то я думаю, это возможно только так. То есть, создаётся раздел таксономии, ему даются определённые свойства и все документы в этом разделе будут этим свойством наделены.Но, к сожалению, пока это возможно только с помощью модулей (то есть, для новых своейств разделов требуется создавать модуль, который бы эти свойства поддерживал). В будущем планируется, я думаю, создать что-то вроде простого управления параметрами разделов, но пока этого нет.

Что же касается шаблонов и программирования, то к сожалению, в этом я не силён. Они написаны на php и я подозреваю, что с их помощью можно сотворить всё что угодно, главное, чтобы шаблон это учитывал. Не знаю, ответил ли я на ваш вопрос, но кое-что вроде прояснил...

Balancer

Цитата:

Какой механизм компиляции пользовательской разметки там используется. Хранятся отдельно исходный текст и скомпилированный. Или компилится на лету. Или декомпилируется для редактирования? Если первый вариант - то просто замечательно. Если нет - то опять досадная фичность, которой страдают все современные форумы и CMS, из-за которых их потом приходится грубо хачить...

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

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


Цитата:

Может ли быть у ноды более одного родителя. Т.е. опять тупое дерево, или же, наконец, направленный граф? (На самом деле полноценную графовую систему я делаю для своего сайта, но до "релизного" варианта ещё далеко.)

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

В этом обсуждении выше Voll из Xaraya указал, что у них тоже есть подобная реализация в одном из модулей для публикации статей. Отличие Drupal - здесь таксономия является центральной идеей, к ней привязываются практически все модули. В этом суть друпаловской идеи построения сайтов.


Цитата:

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

Здесь немного другая идеология, нет в таком виде я не могу это наследование ни с чем соотнести, не нахожу аналогов в Drupal. Впрочем, есть модуль flexinode, позволяющий создавать "на лету" новые типы документов, со своими элементами интерфейса. Но чего-то мне сдается мы о разном думаем, говоря об объектной модели Тогда наверное ее все-таки нет

Harzah

Цитата:

хранится в БД (в том числе и переводы и хелпы), то получается достаточно грустная картина.

Harzah, в тему нашей беседы на drupal.ru об эффективности хранения всего в базе. Специально попробовал старый патчик из CVS, который переводит кэш на файловую систему. Так вот - ни хрена никакой разницы (долго гонял под разной нагрузкой посредством siege). Это правда в случае, когда база находится на том же хосте, если на другом, то предполагаю файловый кэш должен выигрывать. Но насколько не знаю. В любом случае, это не те объемы данных, когда сказываются преимущества линейного чтения с файловой системы, разница в милисекунды тут не играет роли.


Цитата:

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

См. flexinode, если не ошибаюсь там это можно (надо самому впрочем посмотреть сначала, сужу только по описаниям на сайте

Цитата:

Harzah, в тему нашей беседы на drupal.ru об эффективности хранения всего в базе. Специально попробовал старый патчик из CVS, который переводит кэш на файловую систему. Так вот - ни хрена никакой разницы (долго гонял под разной нагрузкой посредством siege).

Дело не в скорости, дело в нагрузке на БД. Разница в том, что в одном случае работают и Апач и БД, а в другом только Апач. В том случае, если на БД будет больше нагрузки, она просто будет медленней работать, да и всё. Это давно уже известно и тут даже говорить нечего о том что лучше. Для быстроты и надёжности пока ничего лучше обычных файлов нет...

Harzah
1. Если СУБД и Apache на одном хосте, то в принципе не важно чем занят проц - работой с базой или с Apache. Проц один и время его все равно тратится

2. Несомненно, в общем случае чтение с файловой системы быстрее чем из БД, поскольку БД можно считать надстройкой над файловой системой (случаев с raw-devices в расчет не берем )

3. Для тех небольших объемов данных, что перегоняются между базой и сервером в Drupal в большинстве случаев нет разницы брать данные с файловой системы или из базы. Но не во всех случаях

Я все это к тому, что не надо из этой не самой большой проблемы делать слона

Да я всём понимаю. Только всё дело в объёмах информации.
Сначала будет муха, а по мере накопления информации и
количества посетителей - будет слон.

Хранение "всё в БД" себя не оправдывало никогда, если нет
больших мощностей. Я согласен с тем, что если поставить Drupal
на кластер под Linux, то тогда наверное БД "не ляжет" никогда...

Если можно хранить в файлах (необновляемую информацию), то зачем
её хранить в БД? Мне это непонятно.

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

Или в modules, зачем спрашивается, туда загонять простой текст?
Можно же сделать проще, например в модуле пишем обозначение {название модуля_help_1(2,3,4...)} - оно подставляется из тех языковых файлов, которые мы используем. Вот и все дела... Без всяких там запросов к БД, без увеличения объёма модулей, без всего прочего.

Конечно, ты можешь сказать про патч и про .po файлы. Но у меня этот вариант не заработал. Не знаю, в чём там проблема, но язык он показывает английский, куда точно указать ru_ru locale я так и не понял, а ты так и не объяснил. Да и это плохой вариант, что делать например пользователям на windows-серверах? Переходить на linux? Я, конечно, люблю linux, но против такого способа борьбы...

Про utf-8 тоже. Ну не нравится мне она. Я хочу на cp1251 или koi8-ru. Но как минимум два важных модуля у меня работать не будут (агрегатор и друпал), а в будущем может быть и ещё какие-то. Зачем так сделано? Не понятно. Религиозность?

Конечно, это дело разработчиков, дали, я использую и спасибо им за это,
но где логика? Логики ведь нет.

Drupal мне всё равно нравится, конечно. У него количество положительных сторон перевешивают отрицательные. Но всё равно, все эти "маленькие ложечки дёгтя" не дают полностью насладиться работой с ним.

Может кто-нибудь заморачивался? Очень надо