Создание галереи с помощью CCK & Views. Часть 1

Аватар пользователя Dan Dan 12 июня 2009 в 15:58

Введение

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

В этом маленьком HowTo я расскажу о рецепте галереи от Lullabot. Скринкаст можно посмотреть тут. Некоторые модули придётся пропатчить, почему - поясню позже.

Материал предназначен как для новичков, которые смогут по шагам сделать галерею, не написав ни строчки кода, так и для опытных друпалеров, которые ранее не использовали модули nodereference_url или views_attach. Все настройки будут показаны на английском языке. Это сделано из-за возможных различий в переводах. Если вы работаете в Drupal'е на русском языке и у вас проблемы с пониманием той или иной настройки, просто включите английский интерфейс.

Модули

Что нам понадобиться (в скобках указана версия модуля, которую использовал я):

cck (2.3)
Этот модуль предназначен для создания собственных типов материала. Мы создадим два - Галерея и Изображение.
nodereference_url (1.2)
Очень полезных модуль. Добавляет UI к организации отношения "один ко многим" при использовании модуля node_reference. На это модуль можно наложить патч 477598, это позволит автоматически возвращаться в галерею после добавления в неё нового изображения (другими словами патч добавляет в URL создания ноды destination). Пропатченная версия для ленивых: nodereference_url-6.x-1.2.patched Патчить не надо, патч вошёл в релиз.
imagefield (3.0)
Это подмодуль модуля CCK. Позволяет прикреплять к материалам изображения. Must have :)
imageapi (1.6)
Требуется для imagefield
filefield (3.0)
Требуется для imagefield
views (2.6)
Модуль создаёт списки материалов, которые можно очень гибко настраивать. Один из самых популярных модулей для Drupal.
views_attach (2.0)
Позволяет внедрять в материлы и/или профили списки, созданные модулем views. По сути выполняет views_embed_view в теле ноды. Если вы создаёте для своего типа материала шаблон, то можно обойтись и без этого модуля, выполнив views_embed_view в препроцессинге. На модуль придётся наложить патч 485832 - он исправляет баг работы с модулем token, без него галерея не заработает. Уже препарированный модуль: views_attach-6.x-2.0-patchedПатчить не надо, патч вошёл в релиз.
token (1.12) (для views_attach)
Требуется для views_attachУже не требуется, просто рекомендуется
imagecache (2.0-b9)
Также необязательный, но очень полезный модуль. Создаёт изображения разного размера от исходного.

Создание типов материалов

Итак, приступим.

Сначала, на странице типов контента (admin/content/types) создадим (admin/content/types/add) два новых типа: Gallery (Галерея) и Image (Изображение).

  1. Gallery
    • Name: Gallery
    • Type: gallery
    • Submission form settings: исправляем "Body" на "Description" (Описание) (по желанию)
    • Workflow settings: убираем галочку с "Promoted to front page" (помещать на главную) (по желанию)
    • Comment settings: отключаем (по желанию)
  2. Image
    • Name: Image
    • Type: image
    • Submission form settings: удаляем "Body" (по желанию) - у изображения будет своё поле для описания. Оно будет однострочным. Если надо многострочное, исправляем "Body" на "Description".
    • Workflow settings: убираем галочку с "Promoted to front page" (помещать на главную) (по желанию)
    • Comment settings: включаем (по желанию) - можно будет комментировать

Настройка типов материалов

Теперь, созданные типы контента необходимо настроить. В галерее пока особо настраивать нечего, поэтому займёмся изображением. В него нам надо добавить пару полей: ссылку на галерею, к которой принадлежит изображение и собственно само изображение, которое будет загружаться.
Итак, путь - /admin/content/node-type/image/fields, добавляем поля Gallery и Image (дежа вю :)

  1. Gallery
    Добавляем поле. Параметры:
    • Label: Gallery nid
    • Field name: image_gallery
    • Type of data to store: Node reference
    • Form element to edit the data: Reference from URL

    Настраиваем поле:

    • Fallback behavior: Display page not found error
    • Create a link on referenceable content: For full node view
    • Link title: Add photo
    • Link hover title: Add photo
    • Return path: The page the link was clicked on
    • Required: on
    • Content types that can be referenced: Gallery

    На скриншоте 1 показана страница настроек поля.

  2. Image
    Добавляем поле. Параметры:
    • Label: Image
    • Field name: image_image
    • Type of data to store: File
    • Form element to edit the data: Image

    Настраиваем поле:

    • Permitted upload file extensions: jpg jpeg png gif
    • Required: on
    • Description field: on

    На скриншоте 2 показана страница настроек поля.

После этих манипуляций, страница полей для Image должна выглядеть так

Чуть подрихтуем тип Image на странице настройки отображения полей (admin/content/node-type/image/display): "Title" для "Gallery nid" сделаем "inline", А для "Image title" - спрячем ("none"). Должно получиться вот так

Основа готова. Можно создать галерею и добавить в неё фотографии. После каждого добавления - возвращаемся обратно в галерею. Пока изображения в галереи не отображаются. Настроим во второй части.

ВложениеРазмер
Файл views_attach-6.x-2.0-patched.tgz11.68 КБ
Файл nodereference_url-6.x-1.2.patched.tgz10.31 КБ
0 Thanks

Комментарии

Аватар пользователя Dalay Dalay 12 июня 2009 в 16:34

Без обид, коллега: по сути - полезно, но я бы назвал сие обучалово частью направления «Сделай свой Друпал неповоротливым». Вы тестировали предлагаемое на шаред-хостинге?

Я вообще не понимаю повсеместную любовь к «святой троице» - imagefield и imagecache с ImageAPI. Ну не жизнеспособны подобные решения для большинства проектов. Есть же IMCE с «прибамбасами», Node Images... Зачем городить многотонные наборы, когда мудрее взяться за выпрямление своих рук и следовать путем простоты?

Аватар пользователя Nikit Nikit 13 июня 2009 в 6:40

А можно получить практичный ответ, почему они жизнеспособны, и чем "имсе" с прибамбасами хорош?

Аватар пользователя Stan.Ezersky Stan.Ezersky 12 июня 2009 в 16:41

imagefield
filefield
imageapi
imagecache
views
cck
и знания (x)html+css

всё, куда огород городить. С этими модулями галерея делается за 15 минут максимум, включая темизацию.

P.S. Всё приходит с опытом

Аватар пользователя vovkama@drupal.org vovkama@drupal.org 12 июня 2009 в 17:32

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

Dalay, будте добы, расскажите чем imagefield и imagecache с ImageAPI хуже IMCE с «прибамбасами» и Node Images?

Аватар пользователя Dalay Dalay 12 июня 2009 в 21:03
<a href="mailto:vovkama@drupal.org">vovkama@drupal.org</a> wrote:

Dalay, будте добы, расскажите чем imagefield и imagecache с ImageAPI хуже IMCE с «прибамбасами» и Node Images?

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

Аватар пользователя Dan Dan 12 июня 2009 в 18:35
"Dalay" wrote:

Без обид, коллега: по сути - полезно, но я бы назвал сие обучалово частью направления «Сделай свой Друпал неповоротливым». Вы тестировали предлагаемое на шаред-хостинге?

"Dec0der" wrote:

На мой взгляд неоправдано громоздкое решение.

Обратите внимание на начало статьи: "...если у вас на сайте используются модули CCK и Views...". Если вы _уже_ используете эти модули, то в дополнительных я не вижу смысла, если же не используете, то да, установка такого кол-ва модулей ради галереи возможно будет и лишней, а возможно и нет, всё зависит от специфики сайта.

"<a href="mailto:vovkama@drupal.org">vovkama@drupal.org</a>" wrote:

отя views_attach лучше выбросить и через аргументы блоки сделать.

Можно и так. Во второй части может быть опишу и это решение.

Аватар пользователя Dalay Dalay 12 июня 2009 в 21:06
Dan wrote:

...если у вас на сайте используются модули CCK и Views...

... то установив еще «пяток» хуже уже не станет... :)

Аватар пользователя boodooboo boodooboo 12 июня 2009 в 18:37
"EzS" wrote:

P.S. Всё приходит с опытом

А опыт, как и половое бессилие, приходит с годами.

Аватар пользователя Dalay Dalay 12 июня 2009 в 21:12
boodooboo wrote:
"EzS" wrote:

P.S. Всё приходит с опытом

А опыт, как и половое бессилие, приходит с годами.

:) Точнее, с годами приходит знание о том, что приходит бессилие. Мой дед в 70 с лишним лет «прыгал» на каждую «шевелящуюся» бабку, потому, что никогда не читал умных книжек, только газеты. :)

Я это вообще к тому, что не всякий опыт одинаково полезен.

Аватар пользователя kodo kodo 12 июня 2009 в 20:23
"Dalay" wrote:

Вы тестировали предлагаемое на шаред-хостинге?

да чего тут такого??? я не притендую на особую красоту исполнения, но как пример используемой связки imagefield + filefield + imageapi + imagecache + views + cck

Это на штатовском шаред-хостинге http://hamamatsumoto.com/en/motorcycle

Аватар пользователя Dalay Dalay 12 июня 2009 в 20:54
kodo wrote:
"Dalay" wrote:

Вы тестировали предлагаемое на шаред-хостинге?

да чего тут такого??? я не притендую на особую красоту исполнения, но как пример используемой связки imagefield + filefield + imageapi + imagecache + views + cck

Это на штатовском шаред-хостинге http://hamamatsumoto.com/en/motorcycle

Я не о том, что работать не будет, а о «монструозности» задумки. Ваш пример - медленно и не для большой посещаемости.

В чем тогда прелесть Друпала, если решать каждую задачу установкой нескольких модулей. Чем меня сия CMS «торкает», так это своей гибкостью. Обламывает - своей «тяжестью», что подобные вышеописанному решения усугубляют во много раз.

Примерно так.

Аватар пользователя Dan Dan 12 июня 2009 в 21:43
"Dalay" wrote:

... то установив еще «пяток» хуже уже не станет... :)

Этого я не говорил :)
У связки CCK+Views+Company есть неоспоримые преимущества:
а) масштабируемость и интеграция - с ними интегрирована половина модулей Drupal (а в 7-ке CCK вообще в ядре) и навешивание любой фишки делается в два клика (или две строчки кода);
б) прототипирование - сторонние модули ограничены в функциональности и допиливание их под свои нужды отнимает много времени, а уж если вдруг случается изменение в архитектуре сайта, то замена одних контриб модулей на другие проходит гораздо болезненней, чем изменение полей и связей в ССК-полях.
в)если вы их хорошо знаете, то нужда в доп. модулях отпадает. Половина модулей, описанных в данном HowTo не нужна человеку, хорошо знающему CCK&Views.

Мне кажется или так и есть, что некоторых страшит _количество_ используемых модулей? Господа, не бойтесь, в данном случае это не страшно :) Здесь работает *nix-подход: каждая программа выполняет одну задачу, но делает это хорошо.

Аватар пользователя glu2006 glu2006 12 июня 2009 в 22:49

Не знаю кому как я IMCE использую только как загрузчик картинок в контент под FCK эдитор :) и то в случаае крайней необходимости поскольку стандартный FCK не работает с модулем транслитерации, а в остальном Dalay при вашем подходе к проблемам, расскажите как решать вопрос импорта большого числа галлерей? если через сск + все остальное я могу это решить путем прямой записи в БД + node_save, а как в Вашем случае решается данная проблема?

Аватар пользователя Dan Dan 12 июня 2009 в 23:02
"Ilya1st" wrote:

жутко тормозя. ага

То есть ты предлагаешь вместо CCK писать свой тип контента, а вместо Views - свои запросы? Можно и так, но это уже тема для другого Howto :)

Вообще всегда есть выбор: либо тормозишь ты (долго пишешь и отлаживаешь), либо тормозит машина (ибо ты всё сделал быстро, используя готовое). Я предпочитаю, чтобы сначала тормозила машина :)

Аватар пользователя andypost@drupal.org andypost@drupal.org 13 июня 2009 в 2:53

Забавно читать такие коменты... хоть кто-нить из "стремящихся всё сделать быстро" смотрел во внутренности модулей?

Чем же 3 модуля хуже одного? вы качественно или количественно оцениваете?

Далее - кто-нить из вас, потрудился написать пост для новичков? Хотя бы как "делать правильно"? Где вы умники?

Человек написал отличный пост, потратил изрядное количество времени на оформление, а в коментах какие-то бестолковые "отрыжки" некомпетентных потребителей...

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

Аватар пользователя Dalay Dalay 13 июня 2009 в 6:56
<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

Забавно читать такие коменты... хоть кто-нить из "стремящихся всё сделать быстро" смотрел во внутренности модулей?

Чем же 3 модуля хуже одного? вы качественно или количественно оцениваете?

Далее - кто-нить из вас, потрудился написать пост для новичков? Хотя бы как "делать правильно"? Где вы умники?

Человек написал отличный пост, потратил изрядное количество времени на оформление, а в коментах какие-то бестолковые "отрыжки" некомпетентных потребителей...

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

Человек потратил время на оформление-написание, а его читатели в свою очередь на прочтение и выражение своего мнения. Взаимодействие налицо. Или преследовалась какая-либо иная цель?

Называть же мнения читателей «бестолковые "отрыжки" некомпетентных потребителей» - банальное жлобство.

Аватар пользователя glu2006 glu2006 13 июня 2009 в 8:13
Dalay wrote:

Человек потратил время на оформление-написание, а его читатели в свою очередь на прочтение и выражение своего мнения. Взаимодействие налицо. Или преследовалась какая-либо иная цель?
Называть же мнения читателей «бестолковые "отрыжки" некомпетентных потребителей» - банальное жлобство.

Да не преследовалось никакой цели, Вы написали что IMCE с прибамбасами лучше чем то о чем написал топикстартер, так хоть обоснуйте это чем-то а не только одномодульностью и тем что Вам это милее, чем связка imagecache + imagefield + views медленнее или хуже?
Может Вы знаете то чего не знаем мы? Так поделитесь с народом, если это коммерческая тайна или данная информация продается так скажите :).

Аватар пользователя Dalay Dalay 13 июня 2009 в 17:26
glu2006 wrote:

Да не преследовалось никакой цели, Вы написали что IMCE с прибамбасами лучше чем то о чем написал топикстартер, так хоть обоснуйте это чем-то а не только одномодульностью и тем что Вам это милее, чем связка imagecache + imagefield + views медленнее или хуже?
Может Вы знаете то чего не знаем мы? Так поделитесь с народом, если это коммерческая тайна или данная информация продается так скажите :).

Если Вы поняли мой первый пост, как «с помощью IMCE с прибамбасами и Node Images можно сделать точно так же», то ошиблись. Речь шла о концепции, не раз «озвученной» тем или иным образом на данном сайте: гвозди забивать удобнее молотком, хотя топор тяжелее и забиваться они им, по идее, будут быстрее.

Касательно частностей, да, скорее всего можно повторить замысел ТС, используя лишь один «обработанный» Node Images. Но выписывать рецептов, не зная диагноза(отдельной взятой конкретной ситуации) я не стану.

To glu2006

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

Аватар пользователя glu2006 glu2006 14 июня 2009 в 23:15
Dalay wrote:

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

Мне просто технологически интересно, чем организация Вашей связки быстрее работает чем тут http://www.rest-ua.com/node/2083 или тут http://studiamaster.dp.ua/photo-gallery в моих вариантах это CCK+VIEWS+IMAGECACHE+IMAGEFIELD+своя галлерея. Это не "голимый подъебон" как Вы выразились а чисто профессиональный вопрос. Ситуаций с геммороем или чем-то иным в плане галлерей у меня нету Jquery библиотек хватает с избытком? За предложенную бескорыстную помощь спасибо, я думаю чте если мы сконнектимся, то оба сможем извлечь из общения определенные выгоды друг для друга.

Конечно если ставить задачу в голосовании за каждое фото или комменты к каждой фото из галлереи то мои варианты не пройдут, но в 90% случаев это не нужно. Делать из каждой фотки отдельную ноду это извращение (если проект не специфический), но для таких проектов я думаю проще написать что-то свое исходя из ТЗ чем лопатить существующее. А то что представил на наше обозрение топикстартер, это нормальный ход для реализации определенных идей начинающим и +тыщапицот ему за это.

Аватар пользователя kodo kodo 13 июня 2009 в 5:19
"glu2006" wrote:

IMCE использую только как загрузчик картинок в контент под FCK эдитор

Аналогично. Хотя больше года его не использовал, т.к. по началу показался глючным. Правда сейчас с доп модулем водяных знаков фактически станет стандартом на моих сайтах.

"Dalay" wrote:

Чем меня сия CMS «торкает», так это своей гибкостью.

Вот и меня так же. На каждую задачу есть несколько решений. Хотя это иногда и путает, но с опытом начинает радовать. :)
По поводу примера. На сайте сейчас не стоит вообще никакого кэширования (пока сайт в стадии разработки). С таблицей через view тормозов вообще никаких не замечал, если просматриваешь конкретный мотоцикл, то основное время занимает большая картинка... тут только одна оптимизация... ее не показывать. :)
Но вообщем-то действительно интересно на какую нагрузку может расчитывать такое решение? На пример заходят сейчас 100-200 анонимных уников. 2000-3000 потянет? или уже потребуется выделенный сервер?

Аватар пользователя Dalay Dalay 13 июня 2009 в 18:02

Перечитал внимательней HowTo ТС. Улыбнуло. Пожалуй, что и альтернативу этому сразу выдам.

И так, в описанном примере для функционирования галереи необходимы 10!!! модулей. Альтернативный вариант будет по словам гораздо короче:

Устанавливаем модуль Node Images. Правим стили. :)

Рабочие демки. Node Images работает совместно с Highslide.
_auto-piter.net/content/doc/396
_auto-piter.net/content/doc/396/image_gallery

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 13 июня 2009 в 18:38
"Dalay" wrote:

Устанавливаем модуль Node Images. Правим стили. :)

node_images в некоторых аспектах убог.
у меня вариация своя с ним. свой показ картинок черз JS - написан доп. модуль с каруселькой и сикбоксом + темизация.
на следущей неделе сайт запустим - выложу на выставку )

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

я его тоже пользую тока подперев кучей самописных костылей.
да и еще.
- после добавления картинок модуь НЕ ЧИСТИТ КЕШ без отдельного патча.
- кладет все файлы плоско в одну папку. что на количестве файлов изображений больше 1000 - а у нас уже порядка 4000 приводит к ТОРМОЗАМ файловой системы.

views+ссk:
- тормозно.
- дыряво - почти каждый месяц находят новые дыры с обходом прав доступа.
- для нормального не убогого интерфейса пользователя - все равно требует кодирования своих модулечков для НОРМАЛЬНЫХ форм ввода

Вывод. хорошая галерея - это нормально проработанный САМОПИС(пусть и в виде друпаловского модуля). а не объединение кучи модулей в целях сделать из гавна конфетку. что вы все в этом топике и пытаетесь изобразить.
ЗЫ: сам делаю галеры на основе node_images чисто потому что для наших задач этого пока хватает. это компромис между дырявыми бюджетами проектов и непомерными хотелками заказчиков.
ЗЗЫ: хочется самому нормальной кошерной летючей галеры. но каг бы нет желающих оплатить ее изготовление.
ЗЗЗЫ: не тему большого числа файлов в каталоге. image, imagefield и прочая забуда - тоже ТУПО скидывают все свое в один каталог кучей. так что same shit

Аватар пользователя Dalay Dalay 13 июня 2009 в 18:52
"Ilya1st" wrote:

node_images в некоторых аспектах убог...

...Вывод...

С выводом полностью согласен. Нет совершенства в мире живых, ждем смерти...

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 13 июня 2009 в 19:48

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

А если представить как такое случается на довольно сложном проекте?
У меня пару раз после апдейтов 5ки отказывал функционал в модулях - патчили систему безопасности там - так это решалось за 5 минут.
не скажу что сложную вьюху пересоздать будет быстрее. опть же - если таких вьюх пара десятков и на них заязаны все новостные ленты? :)

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

"Dalay" wrote:

С выводом полностью согласен. Нет совершенства в мире живых, ждем смерти...

не спеши. успеется

Аватар пользователя Dan Dan 14 июня 2009 в 11:22
"Ilya1st" wrote:

ЗЗЗЫ: не тему большого числа файлов в каталоге. image, imagefield и прочая забуда - тоже ТУПО скидывают все свое в один каталог кучей. так что same shit

imagefield также поддерживает токены. pictures/[uid], как пример.

Аватар пользователя kodo kodo 14 июня 2009 в 18:23
"Ilya1st" wrote:

кладет все файлы плоско в одну папку. что на количестве файлов изображений больше 1000 - а у нас уже порядка 4000 приводит к ТОРМОЗАМ файловой системы.

К image_gallery есть патч для хранения файлов в различных директориях. Я храню в директориях соответсвтующим названиям галерей.

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 15 июня 2009 в 10:10
"kodo" wrote:

К image_gallery есть патч для хранения файлов в различных директориях. Я храню в директориях соответсвтующим названиям галерей

у меня свой патч к node_images - разбииваю номера нод на цифры - делаю по ним подпапки и кладу в конечную файлы...
при том патч не влияет на совместимость с "оригинальным" модулем

Аватар пользователя t1mm1 t1mm1 15 июня 2009 в 13:53

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

Автору спасибо за статью. Своеобразный левел Ап. Хотя я и не сторонник cck - слишком много мусора в коде (используется около 20-30% от возможностей, а грузит то тоже)...Либо использовать модули - где идет интеграция уже отдельного ядра галлерей. Но там другие бока..

Как по мне - лучше писать свою библу модулей. и Использовать их в будущем. Ничего сложного нет в этом.

по поводу кеша. настраиваешь крон и пишешь модуль по его очистке. был уже этот бак по моему. решалось.

юзайте имейджмейджик, тумбсайлз и будет вам счастье.

Автору спасибо за статью. В спорах рождается истина. и Знания.

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

Аватар пользователя Dalay Dalay 15 июня 2009 в 15:01
"glu2006" wrote:

Мне просто технологически интересно, чем организация Вашей связки быстрее работает чем тут http://www.rest-ua.com/node/2083 или тут http://studiamaster.dp.ua/photo-gallery в моих вариантах это CCK+VIEWS+IMAGECACHE+IMAGEFIELD+своя галлерея. Это не "голимый подъебон" как Вы выразились а чисто профессиональный вопрос. Ситуаций с геммороем или чем-то иным в плане галлерей у меня нету Jquery библиотек хватает с избытком? За предложенную бескорыстную помощь спасибо, я думаю чте если мы сконнектимся, то оба сможем извлечь из общения определенные выгоды друг для друга.

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

"Ilya1st" wrote:

у меня свой патч к node_images - разбииваю номера нод на цифры - делаю по ним подпапки и кладу в конечную файлы...
при том патч не влияет на совместимость с "оригинальным" модулем

У node_images для «шестерки» в настройках изначально предложено складывать пикчи в разные папки с номером ноды. Ваша привязанность к «архаичным» версиям программных продуктов имеет серьезные обоснования?

Аватар пользователя glu2006 glu2006 15 июня 2009 в 16:50
Dalay wrote:

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

Не убедило :). Может я все таки чего-то недопонимаю, ну да бог с ним. Нравится самому ваять костыли, как говорится код Вам в руки. По мне проще один раз сделать и подписать кусочек кода и потом с чистой экономией времени продавать свое готовое решение, чем каждый раз писать по новой код под каждый проект. Я согласен что за универсальность мы расплачиваемся производительностью, но времена хостингов с 16мб проходят. ССК в 7-й ветке друпала уже в ядре, значит разработчики системы не считают это не нужным тяжеловесным модулем, равно как и вьюс.
Я не могу понять зачем изобретать собственный велик если он и так уже есть, подшаманить чуток это да т.е. улучшить ходовые качества.

Аватар пользователя t1mm1 t1mm1 15 июня 2009 в 18:58

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

представьте, что вы разрабатываете большой проект. и где доли на каждый контроллер (в нашем случае модуль) времени выполнения высчитываются и оптимизируются по самые яйца. А теперь представьте, что у вас задача стоит убрать лишние куски обработчиков, а не писать новые. Поверьте, заи..ся реально, чем писать свое.
Помимо все прочего. Модули, фришные разработки - это все здорово, но никакой гарантии, что у вас в определенный ммоент не слетит что либо. Не по вашей вине. К тому же все требует доработки напильником. Я по этой причине и пользуюсь пятеркой, потому что она более стабильна чем 6ка. При правильном подходе. ССК модуль хороший. Не спорю. Даже соглашусь, но для небольших проектов. То что ССК включили в ядро 7ки - говорит о юзабилити. Но не о производительности. Ничего не хочу сказать плохого, но все же оптимизация продукта - это 30% бюджета проекта.

И продать сайт (готовый продукт) - это одно. Расширяемость же позволяет его легко поддерживать с минимальными затратами. А за поддержку, если вы о заработке, платят не меньше, чем в целом за разработку.

Вообще полемика ни к чему.

Друпал удачно реализовал объекную модель, хоть, и как было замеченно, со своими стандартами (зенда является несколько другим аспектом), которые позволили создать действительно самое большое сообщество не только в рунете.. Я вообще к чему? а к тому что даже разработчики рекомендуют ознакомиться (хотя бы) с апи. Кстати, писать на нем - одно удовольствие. хотя бы потому что организация кеширования довольно прозрачная..
P.s.Я юзаю и модули и свои разработки. Нужно уметь и то и другое. Все зависит от поставленных задач.. И адекватности заказчиков =))) ббгггг...

Аватар пользователя glu2006 glu2006 15 июня 2009 в 22:35
t1mm1 wrote:

Я по этой причине и пользуюсь пятеркой, потому что она более стабильна чем 6ка. При правильном подходе. ССК модуль хороший. Не спорю. Даже соглашусь, но для небольших проектов. То что ССК включили в ядро 7ки - говорит о юзабилити. Но не о производительности. Ничего не хочу сказать плохого, но все же оптимизация продукта - это 30% бюджета проекта.
И продать сайт (готовый продукт) - это одно. Расширяемость же позволяет его легко поддерживать с минимальными затратами. А за поддержку, если вы о заработке, платят не меньше, чем в целом за разработку.

1. т.е. исходя из высказываний некоторых коллег складывается картина, что кругом все ничего не понимают о больших проектах о нагрузках на сервера и т.д. конечно если поднимать проект с более менее серьезным функционалом на шареде в лучшем случае за 2 доллара в месяц, то конечно куда уж там ССК, Вьюс и других аналогичных им монстров там проще свой запрос написать и потом всю жизнь мучатся со своим кодом периодически вспоминая, "а что это я там год назад написал"? За универсальность решений мы платим производительностью, я не спорю против этого факта и как следствие больше платим за машинные ресурсы, но поверьте это не 10-15-20 долларов в час, а вот иметь бесплатное обновление продукта который может менеджерить даже "домохозяйка", продукт который обновляется на ура, и никому не надо платить за перенос кода из одной версии модуля в другую (а если там еще и логика поменялась, то и дописывать придется, соответственно ищи того разработчика и плати ему денег немеряно) вот это действительно огромный плюс и экономия.

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

3. Из личного опыта у нас в саппорте до сих пор есть проект сделанный еще на 4.7 за его поддержку платят нет вопросов, однако портировать его стоит огромное количество времени и денег поскольку была сделана на начальном этапе огромная ошибка было пропатчено достаточное количество модулей и теперь костыли на костылях (тоже думали что умнее всех на свете).
Кстати почему-то наши западные заказчики в последнее время стали требовать сайты на acquia а в этой сборке есть все монстры названные коллегами выше, наверное потому-что они "тупые пиндосы" так могут ответить многие, а я считаю что они гораздо продуманнее подходят к таким вещам, потому что в отличие от наших они реально умеют считать деньги и знают цену каждой строчке качественного кода и эта цена в разы выше чем та которую платят на просторах рунета если я скажу что беру $200-$300 за верстку темы для друпала меня там не поймут и подумают что я либо халтурщик либо пройдоха, зато на просторах нашего любимого в 70% случаев обзовут хапугой зажравшимся и загордившимся собой жлобом ломящим цену.

ЗЫ. Я нисколько не против написания своего функционала, то только в тех случаях когда это действительно необходимо, а не пихать свои идеи куда ни попадя, тем более что в большинстве случаев это уже реализовано, но к сожалению не Вами :).

ЗЫЫЫ. Все наши беды в своем большинстве в том, что мы жадные т.е. любим все на халяву, но когда эта халява появляется начинает играть так сказать "национальная гордость", как это они такое сделали а мы что не можем? да они тут косяков напороли, да это все монстроподобно да это двумя запросами решается и всю их бодягу надо оптимизировать потому что .... см п.1 (про шаред в лучшем случае за 2 доллара). А так называемые "тупые пиндосы" используют машинные ресурсы, они в разы дешевле человеческих вот так коллеги.

Аватар пользователя t1mm1 t1mm1 16 июня 2009 в 1:29

позвольте я прокомментирую Ваш коммент =)

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

2. Короткое время...Знание Апи...Это все опыт. Проще переписать заново/переставить, чем разгребать чужие баги и искать хэтчколбэки и прочие мелочи. И не работать с неадекватными клиентами..И не брать работу, которая по скиллу выше. Тоже по этим причинам отказывался от некоторых проектов.

3. 200-300уе за тему - это нормально. но не для нашей страны. Но вы ж учитывайте - там совсем другой порядок цен. Им проще заплатить вам 300уе, чем 600 по месту. И по поводу сборки в целом. Они не тупые и не умны. Это все относительно.

ЗЫ. про машинные ресурсы.. оптимизация, оптимизация и еще раз оптимайзинг =)) Вам приходилось доказывать что вам нужен мощный хост для проекта, пытаясь "домохозяйке" объяснить - зачем? (ну что бы не пугать заказчика выражениями на мЭстном жаргоне о серваках и тэдэ). В некоторых случая - получалось =)

Гы. Я сам юзаю модули, переписываю их части под свое усмотрение, ломаю, изучая апи т.д.. Реализованно далеко не все. Порой надо поставить 10 модулей, только лишь для вывода одной строчки. Было и такое. Вьюсы - да, модуль незаменим. Но есть и куча других. Кстати, под 5ку нет яндекс мапы =) от и тема для размышлений. Есть она под 6ку правда. Но чето на 6ку не хочется переходить пока что... Жду 7ку..

Мир вам. Любезнейший.

Про машинные ресурсы. Нагрузки разные бывают =) Как и проекты =)

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 15 июня 2009 в 17:38
Dalay wrote:

У node_images для «шестерки» в настройках изначально предложено складывать пикчи в разные папки с номером ноды.

как бы не совсем так. патчилось.

Dalay wrote:

Ваша привязанность к «архаичным» версиям программных продуктов имеет серьезные обоснования?

30 тысяч строк своего кода. большой проект. 5ый друпал. сколько времени/денег портирование съест?

Аватар пользователя PVasili PVasili 15 июня 2009 в 19:25
"Dan" wrote:

Вообще всегда есть выбор: либо тормозишь ты (долго пишешь и отлаживаешь), либо тормозит машина (ибо ты всё сделал быстро, используя готовое). Я предпочитаю, чтобы сначала тормозила машина :)

я бы перефразировал, что +$5 за нормальный хостинг стоят гораздо дешевле чем недели ..ханья со своими великами их глюками, обновлениями и т.д..

Аватар пользователя PVasili PVasili 15 июня 2009 в 19:47
"t1mm1" wrote:

по поводу кеша. настраиваешь крон и пишешь модуль по его очистке. был уже этот бак по моему. решалось.

проще уж триггером в действиях почистить, странно, что Илья об этой возможности забыл :)

"Dalay" wrote:

У node_images для «шестерки» в настройках изначально предложено складывать пикчи в разные папки с номером ноды. Ваша привязанность к «архаичным» версиям программных продуктов имеет серьезные обоснования?

скорее всего огромное количество костылей

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 15 июня 2009 в 22:38
"PVasili" wrote:

что +$5 за нормальный хостинг

не спасут тебя на нагрузке в пару тройку десятков килоюников в день
а вытаскивать данные из cck + views и срочно писать велосипед надо будет "уже вчера".

Аватар пользователя Dalay Dalay 15 июня 2009 в 23:51
"glu2006" wrote:

Не убедило :). Может я все таки чего-то недопонимаю, ну да бог с ним. Нравится самому ваять костыли, как говорится код Вам в руки. По мне проще один раз сделать и подписать кусочек кода и потом с чистой экономией времени продавать свое готовое решение, чем каждый раз писать по новой код под каждый проект. Я согласен что за универсальность мы расплачиваемся производительностью, но времена хостингов с 16мб проходят. ССК в 7-й ветке друпала уже в ядре, значит разработчики системы не считают это не нужным тяжеловесным модулем, равно как и вьюс.
Я не могу понять зачем изобретать собственный велик если он и так уже есть, подшаманить чуток это да т.е. улучшить ходовые качества.

:) Знаете, такое у меня чувство, что тут(в комментах) уже давно каждый говорит о чем то своем, обращая внимание на вопросы/ответы других комментаторов постольку поскольку. Фиг знает, что за информацию считали Вы с моих слов, но под процитированными выше словами(Вашими) могу подписаться сам.

Аватар пользователя Dalay Dalay 15 июня 2009 в 23:52
"Ilya1st" wrote:

не спасут тебя на нагрузке в пару тройку десятков килоюников в день
а вытаскивать данные из cck + views и срочно писать велосипед надо будет "уже вчера".

А чего у Вас с русским? Не родной?

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 16 июня 2009 в 0:34
"Dalay" wrote:

А чего у Вас с русским? Не родной?

старые привычки. 6-8 лет назад не всегда успевалось подобрать аналоги в великом и могучем... в итоге аналоги подобраны, а привычки остались :)

Аватар пользователя t1mm1 t1mm1 16 июня 2009 в 1:31

хаха, ребята, вы спорите не о том =)))

лучше посоветуйте почитать что нибудь полезное =)

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

Аватар пользователя answer answer 16 июня 2009 в 7:58

Отличная статья. Не гоните на автора, для новичков самое оно, когда нужно быстро сделать галерею.
Dan, а когда будет 2 часть? Мы все ждем.

Аватар пользователя t1mm1 t1mm1 16 июня 2009 в 10:33

так никто ж и не гонит, как вы выразились. и слово йух не говорят вслух =)
просто спор. как рождение истины =))))

да, сделать быстро - самое оно. и я ЗА такой вариант. как для новичков, так и для профи. Но ведь галереи разные бывают. С различной архитектурой, которую вопроизвести с помощью вышеуказанно ну ни как не выйдет =) и наоборот. Соглашусь, что париться кучу времени ради того, что делается за пол часа - смысл? все зависит от поставленной задачи...

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

Аватар пользователя Dan Dan 16 июня 2009 в 10:34
"answer" wrote:

Dan, а когда будет 2 часть? Мы все ждем.

answer. она готова, надо просто её оформить. думаю будет сегодня.

Аватар пользователя Сашка Сашка 17 июня 2009 в 14:22

Прикольно слушать разных людей:) Я придерживаюсь принципа: «Больше подходов — больше свободы»:) Никогда не знаешь, кто именно будет конечным юзером, подумайте, может кому-то будет совсем грустно разбирать нахаканое-на-гольном-PHP? Отвечаю: большинство конечных юзеров не профи в веб–разработках и никогда не хотят с этим разбираться...

Аватар пользователя Алешка Алешка 22 июня 2009 в 15:30

Не мог не влезть....

"Dalay" wrote:

«Сделай свой Друпал неповоротливым». Вы тестировали предлагаемое на шаред-хостинге?

У меня на 000webhost.com работает....

"kodo" wrote:

да чего тут такого??? я не притендую на особую красоту исполнения, но как пример используемой связки imagefield + filefield + imageapi + imagecache + views + cck

Это на штатовском шаред-хостинге http://hamamatsumoto.com/en/motorcycle[/quote]
да еще и viewscarousel прикрутил. Достаточно нормально. Ну не летает, но и не тормозит.

з.ы. Правда на 000webhost imagecache не работает. победить не смог.

Аватар пользователя Limus Limus 25 июня 2009 в 22:18

сделал всё как указано но в итоге выдаётся вот такая вот страничка и на Gallery и Image

"Страница не найдена
To create a new Gallery, a referenced piece of content must be specified in the link you followed.
Запрашиваемая страница не найдена"

Аватар пользователя la_speranza la_speranza 2 июля 2009 в 8:04

Такая же ерунда, при создании типа документов Изображение, выдает эту ошибку. Сделала все по инструкции )))
Причем это сообщение выдается только, если в типе документов созданы 2 поля: и Gallery и Image.
Если присутствует только поле Image, то документ создается.
В чем может быть ошибка?

Аватар пользователя Dan Dan 2 июля 2009 в 18:12

Image можно создавать только из галереи, щёлкая на кнопке "Add photo".
Вы можете изменить это поведение, задав другую опцию, вместо "Fallback behavior: Display page not found error".

Аватар пользователя azsolutions azsolutions 21 июля 2009 в 3:00

День добрый. Судя по описаниям и подробности руководства решил попробовать такую вот галерею. Я уже пару недель пытаюсь что-то сделать для сайта, где приоритетом являются галереи изображений. Ничего не подходит, но это решение вроде то что может подойти.
Закончив с первой частью, всё создав, всё настроив был немного растроен тем, что у меня не создаётся новый материал "Галерея". Создано было как и надо и "Image" и "Gallery". Выдаёт при нажатии на тип материала "Gallery" : "To create a new Галерея, a referenced piece of content must be specified in the link you followed."
Что это значит?

По логике вещей надо ведь создать в начале галерею, а потом уже внутри неё добавлять изображения?

Приступать ко второй части настроек нет смысла пока не создаётся галерея как тип материалов. :-(
Помогите разобраться, а? Очень уж нужна вменяемая галерея.

Аватар пользователя Dan Dan 21 июля 2009 в 11:17

Такое сообщение должно возникать только при создании изображения вне галереи.
Уверен, что вы неправильно создали галереи. Попробуйте импортировать типы материалов и списки.
Я уже отвечал на подобные вопросы, поищите во второй части.

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 14 августа 2009 в 19:57

Спасибо за подробный рассказ уже в двух частях. Я сперва посмотрел скринкаст, потом нашёл Views gallery, выполненный по его мотивам, а затем увидел, что вы всё тот же скринкаст так замечательно разобрали и растолковали. Лично для меня данное решение удобно тем, что все необходимые модули уже и так установлены и используются на моём сайте.

Единственное, что лично меня пока удерживает от использования модуля, так это сложности с полноценной привязкой Thickbox/Lightbox, которые бы были весьма полезны при работе с данным модулем. В комментариях к самому скринкасту один из пользователей сказал о том, что ему удалось разобраться в этом вопросе и у него всё заработало, но пока не растолковал, как именно он это сделал. Об этом его спросили и на орге.

Судя по всему, имеется ещё аналогичный по сути модуль Node Gallery, который почему-то у нас почти не упоминается. Модуль в альфе, но перспективы у него хороши, как мне кажется. Тем более, что в нём уже есть полноценная поддержка Lightbox2.

Аватар пользователя Dan Dan 15 августа 2009 в 1:22

Я вообще не вижу проблемы в LightBox - два щелчка мыши во views. А, ну ещё imagecache настроить, но это тожене проблема.

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 15 августа 2009 в 12:52
Dan wrote:

Я вообще не вижу проблемы в LightBox - два щелчка мыши во views. А, ну ещё imagecache настроить, но это тожене проблема.

Ну, у меня тоже проблем почти не возникло в случае с Lightbox. Единственное — я не могу выловить Лайтбоксом все изображения, находящиеся в галерее за раз — показываются только те, которые находятся на данной странице.

Аватар пользователя Dan Dan 17 августа 2009 в 19:10

Ну да, таков принцип LightBox'а. Если нужно вывести все фотографии, то необходимо сделать скрытый список ссылок, который будут вести на остальные фотографии галереи. Решения навскидку не вижу.

Хотя...

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

Аватар пользователя b-man b-man 19 августа 2009 в 15:23

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

Аватар пользователя Dan Dan 19 августа 2009 в 19:17

В настройке списка, в полях, там где указываете какую использовать настройку (preset) imagecache использовать, найдите строчки начинающиеся с Lightbox. Дальше понятно думаю будет.

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 21 августа 2009 в 14:44
Quote:

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

М-м-м... Да, возможно стоит это попробовать. Спасибо.

Аватар пользователя mirddin@drupal.org mirddin@drupal.org 10 октября 2009 в 9:07

После прохождения первой части получил вот такое
node/add/image

Page not found
To create a new Image, a referenced piece of content must be specified in the link you followed.
The requested page could not be found.

Перепроверил все раз пять :(

Если в поле field_image_gallery менять
Fallback behavior:
на
Use select list widget

то страница node/add/image отображается, но в выпадающем списке галерей пусто, хотя я парочку заводил.

заранее спасибо!

Аватар пользователя Dan Dan 10 октября 2009 в 10:28
"<a href="mailto:mirddin@drupal.org">mirddin@drupal.org</a>" wrote:

заранее спасибо!

Этот вопрос задан примерно раз пять. Добавлять изображения нужно из галереи.

Аватар пользователя Nikit Nikit 10 октября 2009 в 11:01
"Dan" wrote:

Этот вопрос задан примерно раз пять. Добавлять изображения нужно из галереи.

можно их перенаправить на галерку автоматом, если они заходят напрямую на add, типа защиты от дураков.

Аватар пользователя Dan Dan 10 октября 2009 в 11:12
"Nikit" wrote:

можно их перенаправить на галерку автоматом, если они заходят напрямую на add, типа защиты от дураков.

На какую? Если у вас 10 галерей, то на какую надо перенаправлять?
Разумнее просто скрыть пункт меню node/add/image.

Аватар пользователя Nikit Nikit 10 октября 2009 в 13:20
"Dan" wrote:

На какую? Если у вас 10 галерей, то на какую надо перенаправлять?

Ну хотя бы на "главную/первую/личную", или можно просто выдать сообщение что node/add/image недоступен.

Аватар пользователя Dan Dan 10 октября 2009 в 17:20
"Nikit" wrote:

или можно просто выдать сообщение что node/add/image недоступен.

Ну так и происходит. Просто сообщение перевести на рус. язык.

Итак варианты:
1. Редирект куда-нибудь.
2. Перевод сообщения.
3. Скрытие пункта меню.

Выбирайте нужный.

Аватар пользователя parch parch 26 ноября 2009 в 21:03

Доброго времени суток. Пытаюсь сделать галерею по описанию. У меня такая проблема: после добавления аргумента views, исчезает отображение галереи внизу, ну и в итоге ничего не получается. Подскажите, пожалуйста, в чем может быть дело?

Аватар пользователя parch parch 26 ноября 2009 в 22:23

Прошу прощения, получилось. Все-таки имела место ошибка. Вот только image cache перестал нормально работать: изображения не сжимаются, а обрезаются, так что у меня куча безголовых моделей получилась. Хотя в настройках scale and crop.

Аватар пользователя Dan Dan 27 ноября 2009 в 2:57
"parch" wrote:

Хотя в настройках scale and crop

Именно из-за "..crop" и обрезаются. Без обрезки - это просто scale.
Если у тебя все фотографии - "сверху - голова, ниже - остальное", то ставь обрезку по высоте не центр, а верх (top).
Ну и посмотри модулёк [module=imagecrop] - возможно лучше через него сделать обрезку.

Аватар пользователя Ink Ink 14 января 2010 в 19:21

Спасибо!

У меня все получилось, но не могу понять зачем нужны модули views_attach и token, ведь вывод всех фото (Gallery teaser images) и отдельного фото (Gallery full node images) можно сделать через views+Viewfield.

Может я чего-то не понимаю и views_attach+token делают что-то другое?

Аватар пользователя Dan Dan 14 января 2010 в 22:33
"Ink" wrote:

можно сделать через views+Viewfield.

Можно. Сделайте, если Вам так удобнее. Я например считаю, что использование Viewfield [в данном случае] менее удобно, нежели views_attach.

Аватар пользователя Ink Ink 14 января 2010 в 22:53

Dan, спасибо за ответ.

Я конечно понимаю, что в этом варианте можно так и так сделать, но мне интересно узнать о том какие преимущества дают эти модули (views_attach+token). Просто может с этими модулями в альбомах можно сделать что-то что нельзя сделать с Viewfield?

Аватар пользователя Dan Dan 15 января 2010 в 1:33

Дело не в преимуществе, а в удобстве использования для конечного пользователя. С viewfield пользователю при редактированиии материала необходимо что-то где-то выбирать, указывать, возможно даже думать :)
С views_attach закулисы от пользователя скрыты - он просто создаёт контент. От токена, кстати, он уже не зависит, просто рекомендует. Ну и несколько кирпичей в огород viewfield:
- стастика использования для 6.х в два раза ниже чем у views_attach
- отсутствие релиза для 6.х
- открытых багов - 19 (против 2-х у views_attach).
Всё это не критично, но при прочих равных условиях я предпочитаю views_attach.

Аватар пользователя blog.proektsb.ru blog.proektsb.ru 19 апреля 2010 в 2:27

Return path: The page the link was clicked on - у меня есть только пункты the new node, the previous page, the referenced node.
Что выбрать-то???

Аватар пользователя blog.proektsb.ru blog.proektsb.ru 20 апреля 2010 в 0:53
"blog.proektsb.ru" wrote:

Return path: The page the link was clicked on

Мда, скорость ответа на мой пост впечатляет. В общем, я поставил модуль CCK Gallery. Вроде работает, ничего настраивать особо не пришось. А по вашей статье не получилось сделать ничего из-за выше описанной проблемы, как я полагаю.

Аватар пользователя Stan.Ezersky Stan.Ezersky 20 апреля 2010 в 3:07
"blog.proektsb.ru" wrote:

Мда, скорость ответа на мой пост впечатляет.

А вам кто-то чем-то обязан?

Аватар пользователя Dan Dan 20 апреля 2010 в 3:11
"blog.proektsb.ru" wrote:

Мда, скорость ответа на мой пост впечатляет.

Ох простите, Ваше Сиятельство, не заметил что пост был от Вашей Милости! Иначе всенепременно ответил бы в тот же миг! Прошу - не будьте ко мне слишком строги, постараюсь непременно загладить вину свою!

"blog.proektsb.ru" wrote:

А по вашей статье не получилось сделать ничего из-за выше описанной проблемы

У других получилось.

Аватар пользователя blog.proektsb.ru blog.proektsb.ru 21 апреля 2010 в 0:11
Dan wrote:
"blog.proektsb.ru" wrote:

Мда, скорость ответа на мой пост впечатляет.

Ох простите, Ваше Сиятельство, не заметил что пост был от Вашей Милости! Иначе всенепременно ответил бы в тот же миг! Прошу - не будьте ко мне слишком строги, постараюсь непременно загладить вину свою!

"blog.proektsb.ru" wrote:

А по вашей статье не получилось сделать ничего из-за выше описанной проблемы

У других получилось.

Не серчайте, если что. Я не со зла.

Аватар пользователя blog.proektsb.ru blog.proektsb.ru 21 апреля 2010 в 0:21

За статью всё равно спасибо! Пусть не мне, но другим она точно поможет. Зато я научился немножко работать со вьюсами, когда настройки делал по вашей статье. Так что вы не напрасно трудились. Низкий вам поклон.

Аватар пользователя Dan Dan 21 апреля 2010 в 1:18

А вы вторую статью смотрели? Основное - там. Плюс там есть экспорт типом материалов и списков -- сделал специально для случая "быстро сделать, потом разбираться".

"blog.proektsb.ru" wrote:

Зато я научился немножко работать со вьюсами

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

Аватар пользователя blog.proektsb.ru blog.proektsb.ru 21 апреля 2010 в 10:25

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

Аватар пользователя avatar avatar 9 января 2012 в 14:36

Все супер, рецепт использую давно и с удовольствием.
Кстати, прикрутил таб "комментарии" - показывает комменнатарии к конкретной галереи (что-то вроде как вконтакте) - если надо кому, напишу.
Вот только вопрос: кто-нибудь пытался настроить права доступа к ссылке "добавить фото"? Ведь в текущей реализации ссылка доступна всем. А хотелось бы, чтобы в галерею мог добавить фото только автор (ну или роль). Почему field-permision на это поле не срабатывает.

Аватар пользователя Dan Dan 10 января 2012 в 1:09
"avatar" wrote:

Вот только вопрос: кто-нибудь пытался настроить права доступа к ссылке "добавить фото"?

[module=nodeaccess_nodereference]

Аватар пользователя avatar avatar 13 января 2012 в 12:52

Dan, простите, а вы сами этот модуль настраивали на такую задачу? Не могу врубиться в логику работы. Как галки не выставляю - ссылка "добавить фото" видна как автору галереи, так и не_автору.

Аватар пользователя Dan Dan 13 января 2012 в 13:33

Нет, я с ним не работал.
Насколько я помню (могу ошибаться), модуль nodereference_url формирует ссылки "добавить фото" как стандартные node-ссылки. Если это так, то их можно переопределить через hook_link_alter

Аватар пользователя Slavik_zest Slavik_zest 16 января 2012 в 15:20

Прочитал практически все, что написано тут про галереи. Но так и не смог разобраться. Буду очень благодарен, если поможете. Задача у меня такая: Нужно создать галерею таким образом, чтобы альбомы выводились в разных пунктах меню. Сейчас получилось только вывести в меню каждый альбом отдельно. Но альбомов много, поэтому это неудобно. Нужна подобная структура: Пункт меню 1, по клику на него выводятся как-бы миниатюры альбомов - альбом1, альбом2, альбом3; Пункт меню 2, по клику - альбом4, альбом5, альбом6. Ну и т.д. А уже по клику на миниатюру альбома, выводится сам альбом. И чтобы можно было листать фотографии во всплывающем окне.
Можно ли как-то реализовать такую структуру, не используя модуль Views? Или тут никак без него? Заранее спасибо всем, кто откликнется.

Аватар пользователя Slavik_zest Slavik_zest 17 января 2012 в 17:00

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

Аватар пользователя zahis zahis 3 февраля 2012 в 10:23

скачала более старые модули, которые в статье есть, пропатченные, теперь Arguments активные, добавила в них [nid], но все равно не помогло :( упорно выводятся только ссылки на изображения, а не картинки :((( 150 раз все перепроверила, не понимаю, что не так! Подскажите, пожалуйста, в чем может быть проблема? куда смотреть?