20 декабря 2009 в 15:27
Как-то натыкался на модуль, который позволяет каждому термину таксономии создавать свою ноду, которая будет отображаться на его странице вместо списка нод с этим термином.
Только забыл название этого модуля, а поиском на друпал орг уже третий день найти не могу.
Подскажите, пожалуйста.
Нашёл сам. Пришлось перебирать все возможные поисковые запросы, поэтому так долго.
Тогда я натыкался на Taxonomy Node, но после испытаний выяснилось, что намного лучше его аналог - NAT. Они оба в стадии беты, но последний работает нормально.
К сожалению, NAT выводит только тело ноды, так что все CCK-поля и прочие примочки останутся "за кадром".
Однако, опять же методом тыка выяснил, что если воспользоваться этим патчем, то можно добиться нужного отображения через Views.
Заодно узнал как ставить патчи. Если кто тоже не знает: сперва, потом.
Надеюсь, кому-нибудь пригодится.
Попутно разобрался, как сделать удобный интерфейс для работы с иерархией через таксономию. Если успею текущий проект сдать раньше времени - накатаю тут полный урок.
Комментарии
Хм... что то мало чего понятно. Может быть проще и лучше использовать модуль category?
Возможно. Но судя по описанию на самой странице модуля Category, он жутко бажно-глючный и тормозной. а NAT добавляет в базу всего 1 таблицу с 2 полями, в которой нода привязывается к термину.
В принципе, можно и вовсе без доп. модулей.
Через Views перекрываем страницу термина. Создаём спец. тип, который будет содержать описания для категорий. Формируем вьюшку так, чтобы в качестве описания выводился текст из связанных нод этого типа, а в качестве анонсов - все прочие связанные типы.
Но:
1) Если потребуется переместить/изменить/удалить раздел сайта, удобнее это делать через NAT.
2) С NAT можно будет сделать различные вьюшки для вывода материалов в категории - через viewreference, прикреплённый к ноде с описанием категории.
У страха глаза велики.
Судя по своему опыту, если буржуйские коллеги обсуждают производительность, то в уме, по умолчанию они подразумевают 100-500 тыс. загрузок в сутки. Коллеги рунета в этом же уме - 1-5 тыс. Мой сайт (5-ый Друпал) без заметных внешних эффектов с более сотней модулей (в том числе таких тяжеловесов как Category, Views, Panel), с Path и другими "пожирателями" ресурса, с 15-и минутным кешированием, на обычном хостинговом плане (т.е. по соседству с энным количеством сайтов на традиционном хостинговом сервере), с зашкаленным требованием по оперативной памяти (64Мб на сессию, поскольку активно используется административная часть CMS) выдержал 20 тыс. загрузок страниц в час. Для 99% обсуждаемых здесь проектов вопрос производительности Друпала - это чистая гипотетика. Category - действительно мощный модуль и обсуждаемую здесь задачу (плюс кортеж связанных с ней приятных нюансов) он решает по умолчанию. И это стоит того, что бы смириться с рядом недостатков и багов, которые действительно есть, но которые кардинально не мешают его использованию.
Pozniy, cпасибо за наводку. Сорри, что не ответил сразу - ушёл тщательно разбираться с Category по Вашей рекомендации. Итак...
Category, бесспорно, весьма достойный модуль. Функционал у него намного шире, чем у NAT, а простота использования - выше. Но в этом-то и пробема. Ключевой минус Category - в том, что он представляет собой замену стандартной таксономии (в гибриде с book, кстати), а не расширение (как у NAT). Т.е., если когда-нибудь возникнет необходимость отказаться от этого модуля, в случае с Category будет затруднительно сохранить структуру сайта. Другое следствие "заменности" - в том, что Категории, прямо скажем, очень криво работают с другими модулями. В частности, сInternationalisation, что для мультиязычного сайта критично.
Через некоторое время также выяснилось, что этот модуль очень любит генерить ошибки "Соединение было сброшено" при посещении его категорий, при генерации алиасов к нодам конфликтовать ими с самими же собой, а также выдавать "Fatal error: Call to undefined function _taxonomy_term_select()..." при попытке редактирования терминов сопоставленного словаря вручную. Не знаю - может, это в комбинации с работающим у меня модулями, но - факт. Да и честное признание автора модуля вкупе со статистикой использования как бы символизируют.
Кроме того, в Category я не нашёл способа сопоставить категориям в определённом контейнере свой тип материала, а также проинтегрировать это дело с Content Taxonomy.
Теперь о плюсах. Тут, пожалуй, из пригодившегося мне можно отметить только "родную" поддержку формирования списка через Views да иерархию через одни только ноды, безо всякой путаницы с терминами таксономии. По первоначальной задумке модуль очень хорош, но его конфликтность заставляет отказаться от него раз и навсегда. Если когда-нибудь он войдёт в дистрибутив Друпала вместо стандартных book и taxonomy (со всеми вытекающими) - я с радостью перейду на него, а пока - увольте.
Итог: ИМХО, необходимость доробатывать напильником через темизацию и Views (NAT) - куда меньшее зло, чем несовместимость, ошибки и риск потерять в будущем структуру сайта напрочь (Category). Хотя я допускаю, что на совсем небольших сайтах с минимом доп.модулей Category будет куда более удачным решением.
P.S.: вообще, по моему сугубо личному мнению, концепция модуля такого рода до банальности проста: взять NAT, но изменить его так, чтоб при посещении термина таксономии вместо описания выводилась целиком сопоставленная нода (включая все CCK-поля и другие доп. функции). Жаль, что php сам не владею...
Решил описать подробнее, как у меня реализована иерархия через NAT - вдруг кому пригодится.
Этот модуль, хоть на данный момент ещё далеко не совершенен, но достаточно активно развивается, набирается фич, и определённо он стабильнее аналогов.
На данный момент он не работает с мультиязычнотью, не совсем "напрямую" поддерживает формирование списка нод-потомков через Views, и во многом нуждается в доработке напильником. ОДНАКО я рекомендую использовать его.
К сожалению, pathauto обрабатывает эти строки как регистрозависимые, поэтому приходится добавлять варианты типа "WOW" и "WoW". Это первый напильник.
Указанный мной способ привязки к Views, как выяснилось, основной. Но он имеет массу недостатков, которые я описал здесь, и предложил решения здесь.
Надеюсь, что другие члены русской коммьюнити друпала тоже приложат усилия для развития этого модуля, т.к. он, по сути, является единственным потенциально вменяемым из серии "а-ля Category". Лично я считаю, что если исправить эти 2 здоровенных недочёта (интеграция с Views и i18n) - то его можно будет признать основным модулем для данной задачи.
Плохая новость. В последнем pathauto конструкции типа
больше не работают, т.к. он не обрабатывает нормально пробелы в первой части (та что без кавычек).
[##754350]Ответа[/##] в ветке модуля я не получил. Единственное - в новой линейке версий, как я понял, собираются реализовать вообще всё [##686234]через т.н. "преобразования"[/##] - там это будет возможно напрямую в интерфейсе. А пока - никак.
Человеческое спасибо за постоянное подробное описание вашего опыта.
Если интересно - сейчас я вообще отказался от NAT. Для поставленной задачи использую Panels+Views.
А связываю созданные ноды с терминами, которым они соответствуют, вручную. (Можно через Rules, но руки пока не дошли).
Алсо, для долее удобного связывания с терминами таксономии я почти "мастхэвно" использую Content Taxonomy. Особенно он незаменим при связывании со сложным ветвлёным словарём.