Модули book и wiki в CMS Drupal

Аватар пользователя Макс К. Макс К. 21 сентября 2007 в 2:04

Книги Часто владельцы Drupal-сайтов сравнивают модули book и wiki. Обычно считается, что wiki-модули дают больше возможностей.
Но я не могу сказать, что модуль "book" более ущербный, чем wiki-модули. Они просто созданы для разного. И в целом на Drupal-сайте модуль book гораздо более уместен, чем wiki-модули.
Сразу оговорюсь, что в Друпале несколько модулей wiki. Под словами "wiki-модули" я буду понимать не конкретный модуль под названием Wiki (он уже умер вместе с информацией, накопленной им), а модули, которые создают wiki-подобную структуру информации.
Wiki-модули создают свою структуру данных и реализуют основные возможности wiki. Главная цель у них - дать на Drupal-сайте возможность создавать и хранить материалы в wiki-стиле. Есть фанаты wiki, они с удовольствием ставят wiki-модули. Они рискуют, что в один прекрасный день поддержка wiki-модулей может прекратиться и на сайте окажется куча повисшего в воздухе материала, который не вписывается в стандартные структуры Друпала.
Модуль "book" не пытается создавать комфорт для фанатов wiki. "Book" берет от wiki только возможность совместно редактировать страницы. Все остальное в "Book" сильно завязано на стандартные структуры информации в Друпале. Модуль "Book" обслуживает стандартные структуры информации Друпала, совершенно не беспокоясь, что скажут заядлые wiki-сты. В этом сила модуля "book", он плоть и кровь от Друпала и интегрирован в Друпал на 200%. Пока жив Друпал, будут живы все материалы, накопленные через модуль book.
Но любителям wiki модуль "book" конечно не нравится. Улыбка
 
Функции модуля "book"
Основных функций 3.
1-я функция. Создание подшивок (книг).
Любой материал, опубликованный на сайте (статья в дневнике, сообщение на форуме и т.д.) может быть включен в подшивку (книгу).
Например, можно создать подшивку (книгу), целиком состоящую из чужих статей, опубликованных на сайте. Одно из очевидных применений - FAQ. Если на форуме появился удачный вопрос и длинная дискуссия по нему, то его можно подшивать в подшивку (книгу) "FAQ".
Таких подшивок может быть много. Авторы у каждой страницы в подшивке могут быть разные. Авторы могут менять свои страницы. Они даже могут и не знать, что их страницы включены в книгу.
 
Подшивка (книга) в сравнении с таксономией (классификацией)
Классификацию создает администрация сайта. Авторы статей получают возможность выбрать нужную рубрику в классификации. Но часто они делают выбор неправильно или классификация не предусматривает каких-то редко встречающихся вариантов.
Подшивка (книга) готовых статей это способ для администрации объединить материалы на одну тему, созданные разными авторами.
И таксономия и подшивка раскладывают материал по полочкам. Но если в таксономии авторы самостоятельно выбирают подходящую рубрику, то подшивку (книгу) создает администрация в соответствии со своими нуждами.
Также в таксономии под каждый элемент рубрики создается отдельный канал. В нем появляются время от времени статьи, качество их может быть самым разных, от хорошего до совершенно дилетантского или вообще статья может быть не в тему.
А в подшивку отбираются только самые лучшие статьи.
Поэтому подшивка всегда компактнее, чем таксономия и качество подшивки всегда выше, чем качество таксономии.
Можно сказать, что таксономия делит весь поток информации на динамические потоки разных тематик. А подшивка (книга) старательно отбирает из всех материалов самое лучшее и подходящее по теме подшивки и собирает отобранное в удобном для просмотра виде.
 
Как не захлебнуться в информации
Когда сайт мал, то можно публиковать статьи без всякой рубрикации, их слишком мало. Просмотреть одну статью в неделю посетителям сайта не составит труда. Равно как и окинуть одним взглядом все 5 статей, которые есть на сайте.
Когда количество статей начинает измеряться десятками, приходится делить их на разные рубрики с помощью таксономии.
Когда статей сотни и тысячи, число рубрик измеряется десятками, авторам уже лень искать подходящие рубрики и каждый день добавляется новая информация. Здесь на поле выступают подшивки (книги).
Для простоты можете представить себе, что параллельно каждой рубрике в словаре заводится отдельная подшивка (книга) с этой же тематикой. В подшивку отбираются лучшие статьи из этой рубрики. Подшивка - сгусток лучшего, что наработано в рубрике.
На практике подшивка не обязана "курировать" какую-то рубрику классификации. Обычно сначала заводят подшивку FAQ. Затем тематика статей на сайте сама подскажет, какую сделать очередную подшивку. Если классификация создается из представлений администрации сайта о том, что должно быть на сайте, то подшивка подстраивается под то, что уже наработано на сайте.
Можно легко перемещать страницы внутри подшивки или вообще удалять некоторые страницы из подшивки. Можно удалить и саму подшивку. На страницах, включенных в подшивку это никак не сказывается. Они как жили самостоятельной жизнью, так и будут продолжать жить.
 
2-я функция модуля book, подача информации в подшивке
Набранный в подшивку материал Друпал укладывает в древообразном виде.
У каждой страницы подшивки внизу текста страницы есть навигация в виде списка подчиненных страниц и строки с 3-мя ссылками:

  • название предыдущей страницы
  • на уровень вверх
  • название следующей страницы.

С помощью стороннего модуля можно создать страницу, где все страницы книги развернуты в оглавление. Само оглавление делается из заголовков, которые дают авторы своим страницам.
 
3-я функция модуля book Это включение в подшивку (книгу) коллективно написанных страниц.
Подшивка (книга) создается трудом многих авторов. Модуль "book" доводит идею совместного труда до конца и позволяет включать в подшивку страницы, созданные совместным трудом многих авторов. Назову такие страницы общественными. Если в обычных статьях и комментариях авторство строго поддерживается и редактировать текст может только администрация и редактора, то в общественных страницах круг редакторов расширяется до круга пользователей, которые получили право на редактирование общественной страницы. В этот круг можно включить даже гостей. Причем в качестве автора общественной страницы показывается последний автор, который вносил изменения.
Ведется история версий. Пользователи с соответствующими правами могут откатить неудачную правку общественной страницы на одну из предыдущих версий.
 
Применение общественных страниц
Пример 1. Нужна инструкция по обновлению сайта на Друпале.
Кто-то из администрации создает набросок шагов для обновления и оформляет его в виде общественной страницы. Другие друпальщики пользуются этой инструкцией и по ходу дела дополняют ее своими примечаниями. Так, шаг за шагом, инструкция приобретает очень подробный вид. И становится такой, что в нее ни добавить, ни убрать.
Пример 2. Описание модулей
Для каждого модуля заводится отдельная общественная страница. И дается первичное описание, можно даже на английском языке. У кого из пользователей есть время, переводит описание на русский или пополняет его своими впечатлениями.
Пример 3. Инструкция для посетителей сайта
Можно создать подшивку с общественными страницами, в которых подробно рассказывается, что и как может делать посетитель на сайте, начиная от авторизации и кончая использованием редактора и подпиской на новости. При соответствующей настройке модуля "book" доверенные пользователи смогут не только сообща править общественные страницы в такой книге, но и даже сами создавать структуру такой книги.
 
Терминология
Теперь надеюсь читателям понятно, почему результатом работы модуля book является структура, которая имеет 2 перевода на русский язык - подшивка и книга.
Когда подшивка (книга) набрана целиком из чужих материалов, то уместнее назвать такую структуру подшивкой в знак того, что страницы подшивки живут самостоятельной жизнью и подшивка только удобный способ объединения разрозненных удачных страниц.
Когда подшивка (книга) состоит целиком из общественных страниц, специально написанных для подшивки (книги), то здесь уместнее аналогия с настоящей книгой, где все страницы написаны для книги и не существуют отдельно от книги.
Но для самого Друпала все равно, из чего набивается подшивка (книга) - из чужих статей, из общественных страниц или из того и другого вместе. И чужие статьи и общественные страницы для Drupal равноправные составляющие подшивки (книги).
 
Модуль Book в тени
Таксономию (классификацию) пользователи Друпала осваивают быстро и используют с удовольствием.
Сторонние wiki-модули тоже ставят с охотой. Как же, wiki это круто.
Подшивки (книги) это довольно необычная структура информации, которая не встречается в других CMS. Поэтому ее ставят редко. Хотя это самая рабочая лошадка Друпала.
Поэтому, как ни странно, владельцы Друпал-сайтов готовы скорее мучаться со сторонними wiki-модулями, чем включить штатный модуль book.
 
Рекомендации
1. С первых дней жизни сайта используйте возможности подшивки чужих материалов для создания хотя бы FAQ. Подшивки можно делать даже на сайтах с парой десятков статей.
2. Когда немного набьете руку на создании подшивок и на сайте появится сообщество, переходите к освоению общественных страниц. (На сайтах с маленьким сообществом общественные страницы будет просто некому редактировать).
Сделайте для старта подшивку с несколькими страницами с инструкциями, отражающими тематику сайта. Объясните посетителям с правом редактировать общественные страницы, что от них ожидается помощь в редактировании.
3. Только когда сообщество на сайте очень большое и возможностей book перестанет хватать, только тогда можно подумать (но не ставить) wiki-модули.
Линия, до которой даже и думать о wiki не стоит, это 5-10 тысяч посетителей в день. Модуля Book для обслуживания такого сообщества хватает за глаза.
Если сообщества стало больше, то можно начинать думать (но не ставить) wiki-модули.
Для примера, на сайте Drupal.org в день ходит десятки тысяч посетителей. Там через подшивки ведется FAQ, причем из чужих страниц. Но wiki-модули на Drupal.org почему-то не ставят, хотя силы сообщества Drupal.org вполне хватило бы наполнять wiki материалами и поддерживать их. На многих русских Друпал-сайтах wiki-модули начинают ставить с посещаемости в 100-1000 раз меньшей. При этом даже не попробовав включить штатный модуль book.
Дело в том, что концепцию wiki знают все, даже не друпальщики, а концепцию book - единицы из друпальщиков. Надеюсь, моя статья привлечет внимание к использованию модуля book и его начнут чаще включать на Друпал-сайтах.
 
Ссылки

  • Модуль Booktree, создает на одной странице оглавление подшивки (книги), демо
  • Модуль Diff, красиво показывает разницу между разными версиями одной страницы
  • Модуль Wiki, есть только для устаревшей версии Друпала 4.6. Иллюстрация того, как на глазах умирают сторонние модули
  • Модуль Liquid, запускает на сайте полноценный wiki-движок, хранит данные в собственном формате. Тоже когда-нибудь может умереть, как и модуль Wiki
  • Модуль WikiTools, а-ля wiki модуль, но хранит данные в стандартном друпаловском виде. Даже если умрет, накопленные данные останутся живыми. Если без wiki жизнь не мила, то попробуйте сначала поставить его.

Источник: http://www.razgonka.ru/book-vs-wiki

Комментарии

Аватар пользователя axel axel 21 сентября 2007 в 10:37

Википроекты в друпале развиваются в настоящее время медленно. Но поскольку идея вики в интернете популярна (см. пример - wikipedia.org) и полагаю со временем будет только набирать обороты, адекватно поддерживаемый викимодуль к друпалу рано или поздно появится. И я прогнозирую, что со временем викифункциональность будет поддерживаться в движке на уровне стандартных "ядерных" модулей. Пока же могу только согласиться с большинством утверждений статьи - меньше проблем с book. Хотя на drupal.org (точнее на groups.drupal.org) вики используется - среди прочих видов контента.

Аватар пользователя andron13 andron13 21 сентября 2007 в 14:59

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

Аватар пользователя VladSavitsky VladSavitsky 21 сентября 2007 в 11:13

'''Очень-очень полезный материал!!!'''

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

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

==Почему мне нужна вики-функциональность?==
*'''Удобное и быстрое создание контента.''' Форматирование в стиле wiki быстрее и является логической разметкой. Админ может поменять стили на сайте и весь контент будет "в теме". Если пользователи правят HTML-код, то форматирование жёстко прописано в тексте статьи.
*ИнтерВики ссылки в контенте любого типа. Нужны перекрёстные ссылки между документами. В wiki это делается очень просто и быстро. Решения: Freelinking - в любых статьях, Liquid Wiki - только в своих статьях

==Это Wiki-юзабилити==
*Пользователи могут создавать ноды, когда они набирают имя ноды, которая не существует.(Wikitools).
*Пользователи могут искать ноды, если они набрали имя ноды, которая не существует.(Wikitools).
*Пользователи могут искать ноды, если они набрали имя ноды, которая не существует.(Wikitools).
*Если был введен заголовок перемещённой страницы - автоматическая переадресация.(Wikitools).
*Следит, чтобы заголовки были уникальными во всех wiki-нодах(Wikitools)

==Ну и ложка дёгтя (очипятки):==
*"Обычно сначала заводят подшивку заводят FAQ."
*"Сделайте для затравки в готовой подшивке несколько страниц с инструкциями по каким-то сторонам работы сайта."

Ещё раз спасибо - в закладки!

Аватар пользователя axel axel 21 сентября 2007 в 12:09

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

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

Аватар пользователя igdrasil@drupal.org igdrasil@drupal.org 21 сентября 2007 в 12:20

Если пользователи правят HTML-код, то форматирование жёстко прописано в тексте статьи.
а кто отменил CSS???

а вот как раз разметка в вики - больное место, пока не выработан стандарт
из-за разных версий wiki-разметки я до сих пор предпочитаю BBCode

Аватар пользователя axel axel 21 сентября 2007 в 12:36

Bbcode тоже стандартом не назовёшь. Да и удобств по сравнению с чистым html в bbcode не много добавляет. Наиболее часто употребимые теги один к одному транслированы - только угловые скобки заменены на []. Офигеть какое удобство. В викиразметках (хотя и приходится для незнакомой разметки смотреть сначала синтаксис) хотя бы теги продуманы, чтобы минимизировать число нажатий на клавиши.

Аватар пользователя PVasili PVasili 21 сентября 2007 в 12:22

Читал все - ниасилил...
Чем одно лучше другого? И чем wiki лучше(хуже) book? Притом принципиально!
В wiki можно легко реализовать book собрав на отдельной странице[цах] все нужные ссылки.
У book только жёсткая прямолинейная нумерация(которую можно менять), в wiki все более "объемно".

При всей любви и уважении к drupal сравнивать http://drupal.org и http://wikipedia.org imho бессмысленно по любым показателям.

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 21 сентября 2007 в 13:49

"На многих русских Друпал-сайтах wiki-модули начинают ставить с посещаемости в 100-1000 раз меньшей." - Примеры?..

Аватар пользователя Макс К. Макс К. 21 сентября 2007 в 15:15

"На многих русских Друпал-сайтах wiki-модули начинают ставить с посещаемости в 100-1000 раз меньшей." - Примеры?..

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

http://www.razgonka.ru/info/142
http://www.razgonka.ru/info/164

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

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

Модуль Book удачно вводит механизм подшивок, когда авторы творят себе как хотят в своих дневниках, а администрация собирает сделанное в подшивки. И авторам хорошо и администрации.

Рискну повторить крамольную мысль. На всю планету достаточно одной Wikipedia.org. Местечковые вики большей частью стоят полумертвые. И только 1-2 человека из администрации наполняют их материалами.

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

Аватар пользователя SolarWind SolarWind 21 сентября 2007 в 14:17

Огромное спасибо за статью.

Возник вопрос. Я посмотрел на модуль Booktree. Насколько я понял, он делает оглавление только для одной подшивки. А если у меня несколько подшивок и для каждой нужно оглавление? Есть ли такой модуль? Что-то я не нашел такого на drupal.org. Sad

Аватар пользователя beer_destroyer beer_destroyer 22 сентября 2007 в 16:11

Для себя решил так: если мне будет нужно хорошее вики, я его поставлю отдельно. В меню дам ссылку и вообще не понимаю, что там, собственно, интегрировать-то так необходимо?

Что за мания все интегрировать, а потом плакаться о вылезающих глюках?

Аватар пользователя beer_destroyer beer_destroyer 23 сентября 2007 в 9:20

Не зеленым, типа, а голубым? Smile

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

Аватар пользователя igdrasil@drupal.org igdrasil@drupal.org 22 сентября 2007 в 19:25

возможно ББКод - несовершенен, но в отличии от хтмл - это изначально фильтр, плюс основные теги - практически стандарт, например тот же [IMG]транслируется практически везде одинаково
мне лично удобнее использовать html, но у меня есть пользователи, которые просто из-за привычки не пользуются даже визуальными редакторами, только BBCode

Аватар пользователя VladSavitsky VladSavitsky 26 сентября 2007 в 9:11

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

Точно. 100%!

'''Макс Кириленко:'''
''На мой взгляд, ориентация на wiki еще не правильная и по той причине, что wiki не особенно нужна авторам, которые пишут статьи. Вики нужна администрации сайта. А авторам нужны личные статьи, которые будут сохраняться под их именем и накапливаться в их дневнике. Авторы не против читать статьи в wiki, но обезличенно писать статьи в wiki - это уж пусть администрация делает, если хочет.''

Да. Это правда. Именно поэтому я слоняюсь к использованию wiki в drupal, а не движка МедиаВики. Дело в том, что для создания энциклопедии имена авторов и не нужны, потому что каждый пишет лишь часть статьи... А те, кто ищут - хотят получить материал с Нейтральной Точкой Зрения (ru.wikipedia.org/wiki/Википедия:Нейтральная_точка_зрения - так и не удалось заставить ссылку работать....), а этого можно добиться только, если над статьёй работало много человек. Один автор - это всегда субъективность.

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

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

Аватар пользователя marazmus marazmus 26 сентября 2007 в 10:59

Кстати, Axel, дашь нам модуль book на друпал.ру? Smile
Уж больно руки чешуцца кое-что подсобрать в подшивки, чтобы не терялось.

Аватар пользователя jason32 jason32 1 октября 2007 в 3:52

Ну вот, вот!!!! Ни слова о Зелени и одни восторженные возгласы, к которым присоединяюсь и я. С интересом прочитал, ибо за более чем полтора года работы с системой НИ РАЗУ не ставил этот модуль и в принципе не особо предполагал, зачем он. Теперь понятно, что штука полезная для больших проектов. Скоро как раз пригодится, так что второе спасибо!

Аватар пользователя Оболганная вандальной администрацией Алиса Оболганная ванд... (не проверено) 3 октября 2007 в 4:49

Ну вот как всегда, собралась толпа Друппалят и устроила натуральную потасовку на пустом месте! Типа обсуждения умности перевода одной строки или даже слова. Конечно хочется просто обматерить участников за чрезвычайную простоту мысли. Вот заводила видите ли функциональность осознал и разложил и терминами обозначил. Ну хватит, а то администрация и это вряд ли стерпит, а уж повизгиваний про флуд будет в избытке (больше чем даже переводов одной строки).
Никаких "вики" и даже "wiki" не существует в природе, впрочем также как и bookов. Это плоды напрочь блокированного мышления юродствующих по этим поводам.
Существует потребность в организации коллективной работы над коллективным содержанием. И это веяние и однозначный запрос времени. От этого никуда не деться.
И покамест этот запрос остаётся неудовлетворенным, несмотря на множественные старания общественности. Пока не сложилось. Пока не получилось. Но сложится и получится, особенно если перестать болтать о концепциях wiki и book, а просто думать над нормальными удобствами коллективной работы.
И какая такая особая разметка ну просто необходима современному автору, которой не было у Александра Сергеевича. Каждый захолустный писатель энциклопедии - так просто дизайнер в корне! И не может обойтись без особенных присущих ему стилей. Максимум что положено, это писать в строчку, отделять абзац, курсив, жирный, и ссылки. И никакого идиотизма с wiki разметками. И вообще есть свободные-свободные XML теги - вообще какие хочешь, без всякой болтовни про фильтры. А те кто не способны осознать и освоить идею xml разметки вообще не достойны быть при компьютере и называться человеком разумным.
Совершенно ясно также и то, что одномерная деревянная структура обречена, также как и плоские базы в конце концов. Нужна удобная многомерная структура и кстати drupal ближе к реализации этой задачи из всех прочих скриптовых недоразумений.
Резюме: Нужно в стандартном модуле book улучшить создание новых статей как в вики при вызове несуществующей ссылки.
И улучшить (юзабилити) вообщем то и без того гениальную идею создания нодов (каналов) на лету.
И никакой викки-букской болтовни.
Оболганная местной вандальной администрацией Алиса В.

Аватар пользователя run run 6 октября 2007 в 16:07

Оболганная местной вандальной администрацией Алиса В разъясните поподробней мысль о многомерности: "Нужна удобная многомерная структура и кстати drupal ближе к реализации этой задачи из всех прочих скриптовых недоразумений." - это как, что имеется ввиду?

Аватар пользователя Запрещенная местной вандальной администрацией Алиса Запрещенная мес... (не проверено) 7 октября 2007 в 22:23

Плоские базы, несмотря на эффективный математический аппарат под ними довольно условно отражают действительность. С расширением практического их применения проблема обострилась. Проблемы неадекватности wiki и book частный случай. Есть коммерческие и перспективные решения базирующиеся на традиционных базах MS, Oracle, DB и др. Классовая обёртка, ну бывает что и сложней. В этом смысле PHP реально может справиться с такой задачей. Модули для коллективной работы по сути пытаются сделать практические решения Smile Таксономия. В сущности XML решает проблему данных. Но вот их эффективная их обработка

Аватар пользователя VladSavitsky VladSavitsky 29 октября 2007 в 15:16

Перевожу последние 3 коммента на русский язык с элементами логики:
*разница между модулями wiki и book незначительна.
*для её устранения в модуле book нужно предусмотреть создание страницы, при переходе по ссылке на несуществующую страницу (как в wiki)
*обеспечить более удобную коллективную работу над материалом (автор с длинным именем считает, что именно эта возможность имеется ввиду, когда говорят о wiki). Так и есть.

*'''От себя''': лёгкие внутренние ссылки (интервики ссылки). Чтобы можно было легко ссылаться на другие ноды. Без путей и др. Видел для этого модуль: [http://drupal.org/project/linktocontent Link to content]

Всё остальное в комментариях автора с длинным именем - словоблудие.

Лично я за book с такими доработками.

Аватар пользователя Гость Гость (не проверено) 26 ноября 2007 в 11:28

актуальный вопрос:
а как перенести накопленные материалы из book в wiki???
сохраняя перелинковку и форматирование во всех материалах.

Аватар пользователя sirmax07 sirmax07 26 февраля 2009 в 21:03

Классная статья. Мне как раз надо определиться, как организовать коллективную работу на сайте. Теперь буду пробовать book.
Для VladSavitsky:
"Предусмотреть создание страницы, при переходе по ссылке на несуществующую страницу (как в wiki)" - было бы здорово, и вообще "лёгкие внутренние ссылки (интервики ссылки). Чтобы можно было легко ссылаться на другие ноды." - конечно очень нужны. Только, ИМХО, эти вещи невозможны - ведь Друпал очень легко относится к человеческим названиям документа: позволяет дублировать, и вообще не считает ссылками. Для этого пришлось бы всю систему менять.
Или я глупость говорю?

Аватар пользователя marelos marelos 21 ноября 2009 в 17:48

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

Аватар пользователя comerer comerer 19 декабря 2009 в 22:29

Доброый день.

вот настраиваю друпал, под некий каталог слов.

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

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

Аватар пользователя comerer comerer 19 декабря 2009 в 22:34

вот, примерно так нужно:

http://setegnom.com/drupal/project

там сверху алвавитный порядок

нажав на букву появиться список слов на эту букву

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