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 (Изображение).
- Gallery
- Name: Gallery
- Type: gallery
- Submission form settings: исправляем "Body" на "Description" (Описание) (по желанию)
- Workflow settings: убираем галочку с "Promoted to front page" (помещать на главную) (по желанию)
- Comment settings: отключаем (по желанию)
- 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 (дежа вю
- 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 показана страница настроек поля.
- 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.tgz | 11.68 КБ |
| nodereference_url-6.x-1.2.patched.tgz | 10.31 КБ |
Комментарии
Без обид, коллега: по сути - полезно, но я бы назвал сие обучалово частью направления «Сделай свой Друпал неповоротливым». Вы тестировали предлагаемое на шаред-хостинге?
Я вообще не понимаю повсеместную любовь к «святой троице» - imagefield и imagecache с ImageAPI. Ну не жизнеспособны подобные решения для большинства проектов. Есть же IMCE с «прибамбасами», Node Images... Зачем городить многотонные наборы, когда мудрее взяться за выпрямление своих рук и следовать путем простоты?
А можно получить практичный ответ, почему они жизнеспособны, и чем "имсе" с прибамбасами хорош?
imagefield
filefield
imageapi
imagecache
views
cck
и знания (x)html+css
всё, куда огород городить. С этими модулями галерея делается за 15 минут максимум, включая темизацию.
P.S. Всё приходит с опытом
хорошая статья, и приятная галерея получается. главное очень многим поможет. хотя views_attach лучше выбросить и через аргументы блоки сделать.
Dalay, будте добы, расскажите чем imagefield и imagecache с ImageAPI хуже IMCE с «прибамбасами» и Node Images?
Буду доб, расскажу. Тем, что один мудуль легче трех. Для меня это милее, скажем так. Ваш выбор - ваше же святое право.:)
На мой взгляд неоправдано громоздкое решение.
Обратите внимание на начало статьи: "...если у вас на сайте используются модули CCK и Views...". Если вы _уже_ используете эти модули, то в дополнительных я не вижу смысла, если же не используете, то да, установка такого кол-ва модулей ради галереи возможно будет и лишней, а возможно и нет, всё зависит от специфики сайта.
Можно и так. Во второй части может быть опишу и это решение.
... то установив еще «пяток» хуже уже не станет...
А опыт, как и половое бессилие, приходит с годами.
Я это вообще к тому, что не всякий опыт одинаково полезен.
да чего тут такого??? я не притендую на особую красоту исполнения, но как пример используемой связки imagefield + filefield + imageapi + imagecache + views + cck
Это на штатовском шаред-хостинге http://hamamatsumoto.com/en/motorcycle
Я не о том, что работать не будет, а о «монструозности» задумки. Ваш пример - медленно и не для большой посещаемости.
В чем тогда прелесть Друпала, если решать каждую задачу установкой нескольких модулей. Чем меня сия CMS «торкает», так это своей гибкостью. Обламывает - своей «тяжестью», что подобные вышеописанному решения усугубляют во много раз.
Примерно так.
Этого я не говорил
У связки CCK+Views+Company есть неоспоримые преимущества:
а) масштабируемость и интеграция - с ними интегрирована половина модулей Drupal (а в 7-ке CCK вообще в ядре) и навешивание любой фишки делается в два клика (или две строчки кода);
б) прототипирование - сторонние модули ограничены в функциональности и допиливание их под свои нужды отнимает много времени, а уж если вдруг случается изменение в архитектуре сайта, то замена одних контриб модулей на другие проходит гораздо болезненней, чем изменение полей и связей в ССК-полях.
в)если вы их хорошо знаете, то нужда в доп. модулях отпадает. Половина модулей, описанных в данном HowTo не нужна человеку, хорошо знающему CCK&Views.
Мне кажется или так и есть, что некоторых страшит _количество_ используемых модулей? Господа, не бойтесь, в данном случае это не страшно
Здесь работает *nix-подход: каждая программа выполняет одну задачу, но делает это хорошо.
Спасибо. Не знал про nodereference_url и views_attach .
жутко тормозя. ага
Не знаю кому как я IMCE использую только как загрузчик картинок в контент под FCK эдитор
и то в случаае крайней необходимости поскольку стандартный FCK не работает с модулем транслитерации, а в остальном Dalay при вашем подходе к проблемам, расскажите как решать вопрос импорта большого числа галлерей? если через сск + все остальное я могу это решить путем прямой записи в БД + node_save, а как в Вашем случае решается данная проблема?
То есть ты предлагаешь вместо CCK писать свой тип контента, а вместо Views - свои запросы? Можно и так, но это уже тема для другого Howto
Вообще всегда есть выбор: либо тормозишь ты (долго пишешь и отлаживаешь), либо тормозит машина (ибо ты всё сделал быстро, используя готовое). Я предпочитаю, чтобы сначала тормозила машина
Забавно читать такие коменты... хоть кто-нить из "стремящихся всё сделать быстро" смотрел во внутренности модулей?
Чем же 3 модуля хуже одного? вы качественно или количественно оцениваете?
Далее - кто-нить из вас, потрудился написать пост для новичков? Хотя бы как "делать правильно"? Где вы умники?
Человек написал отличный пост, потратил изрядное количество времени на оформление, а в коментах какие-то бестолковые "отрыжки" некомпетентных потребителей...
Если для вас сия информация бесполезна - не засоряйте коменты, а напишите совй пост - как сделать лучше!!!
Человек потратил время на оформление-написание, а его читатели в свою очередь на прочтение и выражение своего мнения. Взаимодействие налицо. Или преследовалась какая-либо иная цель?
Называть же мнения читателей «бестолковые "отрыжки" некомпетентных потребителей» - банальное жлобство.
Да не преследовалось никакой цели, Вы написали что IMCE с прибамбасами лучше чем то о чем написал топикстартер, так хоть обоснуйте это чем-то а не только одномодульностью и тем что Вам это милее, чем связка imagecache + imagefield + views медленнее или хуже?
Может Вы знаете то чего не знаем мы? Так поделитесь с народом, если это коммерческая тайна или данная информация продается так скажите :).
Если Вы поняли мой первый пост, как «с помощью IMCE с прибамбасами и Node Images можно сделать точно так же», то ошиблись. Речь шла о концепции, не раз «озвученной» тем или иным образом на данном сайте: гвозди забивать удобнее молотком, хотя топор тяжелее и забиваться они им, по идее, будут быстрее.
Касательно частностей, да, скорее всего можно повторить замысел ТС, используя лишь один «обработанный» Node Images. Но выписывать рецептов, не зная диагноза(отдельной взятой конкретной ситуации) я не стану.
To glu2006
Если есть реальная надобность, а не голимые подьебоны лишь, то в моем профиле указаны контактные данные, обращайтесь. Коли ситуация Ваша не особо гемморойна и не срочна, то помогу в меру сил-знаний и совершенно бескорыстно.
Мне просто технологически интересно, чем организация Вашей связки быстрее работает чем тут http://www.rest-ua.com/node/2083 или тут http://studiamaster.dp.ua/photo-gallery в моих вариантах это CCK+VIEWS+IMAGECACHE+IMAGEFIELD+своя галлерея. Это не "голимый подъебон" как Вы выразились а чисто профессиональный вопрос. Ситуаций с геммороем или чем-то иным в плане галлерей у меня нету Jquery библиотек хватает с избытком? За предложенную бескорыстную помощь спасибо, я думаю чте если мы сконнектимся, то оба сможем извлечь из общения определенные выгоды друг для друга.
Конечно если ставить задачу в голосовании за каждое фото или комменты к каждой фото из галлереи то мои варианты не пройдут, но в 90% случаев это не нужно. Делать из каждой фотки отдельную ноду это извращение (если проект не специфический), но для таких проектов я думаю проще написать что-то свое исходя из ТЗ чем лопатить существующее. А то что представил на наше обозрение топикстартер, это нормальный ход для реализации определенных идей начинающим и +тыщапицот ему за это.
По поводу примера. На сайте сейчас не стоит вообще никакого кэширования (пока сайт в стадии разработки). С таблицей через view тормозов вообще никаких не замечал, если просматриваешь конкретный мотоцикл, то основное время занимает большая картинка... тут только одна оптимизация... ее не показывать.
Но вообщем-то действительно интересно на какую нагрузку может расчитывать такое решение? На пример заходят сейчас 100-200 анонимных уников. 2000-3000 потянет? или уже потребуется выделенный сервер?
Перечитал внимательней HowTo ТС. Улыбнуло. Пожалуй, что и альтернативу этому сразу выдам.
И так, в описанном примере для функционирования галереи необходимы 10!!! модулей. Альтернативный вариант будет по словам гораздо короче:
Устанавливаем модуль Node Images. Правим стили.
Рабочие демки. Node Images работает совместно с Highslide.
_auto-piter.net/content/doc/396
_auto-piter.net/content/doc/396/image_gallery
node_images в некоторых аспектах убог.
у меня вариация своя с ним. свой показ картинок черз JS - написан доп. модуль с каруселькой и сикбоксом + темизация.
на следущей неделе сайт запустим - выложу на выставку )
да. node_images не позволяет:
- не делает картинки отдельными нодмаи что приводит к другому:
- не позволяет делать вложенность вида галерея в галерее и прочие группировки.
- к каждой отдельной картинке делать комменты - а так хотелось бы.
- не позволяет штатно хранить более двух размеров - для этого я применяю imagecache
я его тоже пользую тока подперев кучей самописных костылей.
да и еще.
- после добавления картинок модуь НЕ ЧИСТИТ КЕШ без отдельного патча.
- кладет все файлы плоско в одну папку. что на количестве файлов изображений больше 1000 - а у нас уже порядка 4000 приводит к ТОРМОЗАМ файловой системы.
views+ссk:
- тормозно.
- дыряво - почти каждый месяц находят новые дыры с обходом прав доступа.
- для нормального не убогого интерфейса пользователя - все равно требует кодирования своих модулечков для НОРМАЛЬНЫХ форм ввода
Вывод. хорошая галерея - это нормально проработанный САМОПИС(пусть и в виде друпаловского модуля). а не объединение кучи модулей в целях сделать из гавна конфетку. что вы все в этом топике и пытаетесь изобразить.
ЗЫ: сам делаю галеры на основе node_images чисто потому что для наших задач этого пока хватает. это компромис между
дырявымибюджетами проектов инепомернымихотелками заказчиков.ЗЗЫ: хочется самому нормальной кошерной летючей галеры. но каг бы нет желающих оплатить ее изготовление.
ЗЗЗЫ: не тему большого числа файлов в каталоге. image, imagefield и прочая забуда - тоже ТУПО скидывают все свое в один каталог кучей. так что same shit
http://drupal.org/project/filefield_paths[/module]
С выводом полностью согласен. Нет совершенства в мире живых, ждем смерти...
кстати про views могу добавить приятный факт.
после очередного обновления оного на форумах постоянно вылазят жалобы - "вьюха перестала пахать".
А если представить как такое случается на довольно сложном проекте?
У меня пару раз после апдейтов 5ки отказывал функционал в модулях - патчили систему безопасности там - так это решалось за 5 минут.
не скажу что сложную вьюху пересоздать будет быстрее. опть же - если таких вьюх пара десятков и на них заязаны все новостные ленты?
в общем то я и от вьюх не отказываюсь(служебные выкладки у меня идут через них. ну перестанут работать - чего то редакторы не увидят, зато сайт не потеряет лицо)
не спеши. успеется
imagefield также поддерживает токены. pictures/[uid], как пример.
К image_gallery есть патч для хранения файлов в различных директориях. Я храню в директориях соответсвтующим названиям галерей.
у меня свой патч к node_images - разбииваю номера нод на цифры - делаю по ним подпапки и кладу в конечную файлы...
при том патч не влияет на совместимость с "оригинальным" модулем
хм....
ну не знаю..
как по мне, для подобных вечей лучше все же разобрать api и не ставить кучу модулей, которые и так грузят в общем сервак.
по поводу фришных хостов - работоспособность стоит денег. и вообще запускать проекты на фри хостах - дурной тон. аматорство.
Автору спасибо за статью. Своеобразный левел Ап. Хотя я и не сторонник cck - слишком много мусора в коде (используется около 20-30% от возможностей, а грузит то тоже)...Либо использовать модули - где идет интеграция уже отдельного ядра галлерей. Но там другие бока..
Как по мне - лучше писать свою библу модулей. и Использовать их в будущем. Ничего сложного нет в этом.
по поводу кеша. настраиваешь крон и пишешь модуль по его очистке. был уже этот бак по моему. решалось.
юзайте имейджмейджик, тумбсайлз и будет вам счастье.
Автору спасибо за статью. В спорах рождается истина. и Знания.
по поводу складирования в одну папку. Друпал по умолчанию не предназначался для больших проектов. Как вариант - писать модуль для выбора пути, выбора папки, или используйте модуль браузера (есть такой, хоть и корявый)..
У node_images для «шестерки» в настройках изначально предложено складывать пикчи в разные папки с номером ноды. Ваша привязанность к «архаичным» версиям программных продуктов имеет серьезные обоснования?
Не убедило :). Может я все таки чего-то недопонимаю, ну да бог с ним. Нравится самому ваять костыли, как говорится код Вам в руки. По мне проще один раз сделать и подписать кусочек кода и потом с чистой экономией времени продавать свое готовое решение, чем каждый раз писать по новой код под каждый проект. Я согласен что за универсальность мы расплачиваемся производительностью, но времена хостингов с 16мб проходят. ССК в 7-й ветке друпала уже в ядре, значит разработчики системы не считают это не нужным тяжеловесным модулем, равно как и вьюс.
Я не могу понять зачем изобретать собственный велик если он и так уже есть, подшаманить чуток это да т.е. улучшить ходовые качества.
свой код пишеться по некоторым причинам.
одна из них - это свободная расширяемость и полное понимание архитектуры. Отсюда выходит то, что отбрасываются лишние обработчики. Это экономия времени обработки.
представьте, что вы разрабатываете большой проект. и где доли на каждый контроллер (в нашем случае модуль) времени выполнения высчитываются и оптимизируются по самые яйца. А теперь представьте, что у вас задача стоит убрать лишние куски обработчиков, а не писать новые. Поверьте, заи..ся реально, чем писать свое.
Помимо все прочего. Модули, фришные разработки - это все здорово, но никакой гарантии, что у вас в определенный ммоент не слетит что либо. Не по вашей вине. К тому же все требует доработки напильником. Я по этой причине и пользуюсь пятеркой, потому что она более стабильна чем 6ка. При правильном подходе. ССК модуль хороший. Не спорю. Даже соглашусь, но для небольших проектов. То что ССК включили в ядро 7ки - говорит о юзабилити. Но не о производительности. Ничего не хочу сказать плохого, но все же оптимизация продукта - это 30% бюджета проекта.
И продать сайт (готовый продукт) - это одно. Расширяемость же позволяет его легко поддерживать с минимальными затратами. А за поддержку, если вы о заработке, платят не меньше, чем в целом за разработку.
Вообще полемика ни к чему.
Друпал удачно реализовал объекную модель, хоть, и как было замеченно, со своими стандартами (зенда является несколько другим аспектом), которые позволили создать действительно самое большое сообщество не только в рунете.. Я вообще к чему? а к тому что даже разработчики рекомендуют ознакомиться (хотя бы) с апи. Кстати, писать на нем - одно удовольствие. хотя бы потому что организация кеширования довольно прозрачная..
P.s.Я юзаю и модули и свои разработки. Нужно уметь и то и другое. Все зависит от поставленных задач.. И адекватности заказчиков =))) ббгггг...
1. т.е. исходя из высказываний некоторых коллег складывается картина, что кругом все ничего не понимают о больших проектах о нагрузках на сервера и т.д. конечно если поднимать проект с более менее серьезным функционалом на шареде в лучшем случае за 2 доллара в месяц, то конечно куда уж там ССК, Вьюс и других аналогичных им монстров там проще свой запрос написать и потом всю жизнь мучатся со своим кодом периодически вспоминая, "а что это я там год назад написал"? За универсальность решений мы платим производительностью, я не спорю против этого факта и как следствие больше платим за машинные ресурсы, но поверьте это не 10-15-20 долларов в час, а вот иметь бесплатное обновление продукта который может менеджерить даже "домохозяйка", продукт который обновляется на ура, и никому не надо платить за перенос кода из одной версии модуля в другую (а если там еще и логика поменялась, то и дописывать придется, соответственно ищи того разработчика и плати ему денег немеряно) вот это действительно огромный плюс и экономия.
2. Так-же в случае неординарных ситуаций Ваш проект должен смочь поднять (разобраться что откуда и куда) любой знающий мало мальски АПИ проггер причем за максимально короткое время и я встречал очень много западных проектов в которых это действительно так, русскоязычных к сожалению не очень много в большинстве случаев просто смотрел и отказывался почему, поищите по форуму статей на эту тему хватает.
3. Из личного опыта у нас в саппорте до сих пор есть проект сделанный еще на 4.7 за его поддержку платят нет вопросов, однако портировать его стоит огромное количество времени и денег поскольку была сделана на начальном этапе огромная ошибка было пропатчено достаточное количество модулей и теперь костыли на костылях (тоже думали что умнее всех на свете).
Кстати почему-то наши западные заказчики в последнее время стали требовать сайты на acquia а в этой сборке есть все монстры названные коллегами выше, наверное потому-что они "тупые пиндосы" так могут ответить многие, а я считаю что они гораздо продуманнее подходят к таким вещам, потому что в отличие от наших они реально умеют считать деньги и знают цену каждой строчке качественного кода и эта цена в разы выше чем та которую платят на просторах рунета если я скажу что беру $200-$300 за верстку темы для друпала меня там не поймут и подумают что я либо халтурщик либо пройдоха, зато на просторах нашего любимого в 70% случаев обзовут хапугой зажравшимся и загордившимся собой жлобом ломящим цену.
ЗЫ. Я нисколько не против написания своего функционала, то только в тех случаях когда это действительно необходимо, а не пихать свои идеи куда ни попадя, тем более что в большинстве случаев это уже реализовано, но к сожалению не Вами :).
ЗЫЫЫ. Все наши беды в своем большинстве в том, что мы жадные т.е. любим все на халяву, но когда эта халява появляется начинает играть так сказать "национальная гордость", как это они такое сделали а мы что не можем? да они тут косяков напороли, да это все монстроподобно да это двумя запросами решается и всю их бодягу надо оптимизировать потому что .... см п.1 (про шаред в лучшем случае за 2 доллара). А так называемые "тупые пиндосы" используют машинные ресурсы, они в разы дешевле человеческих вот так коллеги.
позвольте я прокомментирую Ваш коммент
1. Я не спорю. В целом каждый прав по своему. Но по своему опыту могу сказать, что портация версий трудна изза корявости кода. ООП вещь не просто так. думаю мне Вам это рассказывать ни к чему. Как и основы ООП. Я сам использую вышеописанную связку. В некоторых случаях при мультизагрузке - свои библиотеки. В некоторых - вообще не использую встроенные модули. Все зависит от поставленной задачи изначально и архитектуры в целом. По поводу обновления, халявы и т.д.. Я уже писал, что это все здорово. Но корявости этим не избежать. Я лучше потрачу неделю на разработку архитектуры, два дня на писанину и день на отладку, чем постоянно мучиться из-за отсутствия гибкости в настройках. Тут сугубо личный подход из личного опыта. И поверьте, серьезными проектами домохозяйки не руководят. Если вы конечно не о клиентской части и не об открытых проектах. И есть совет. Что бы не искать разработчика - нужно следовать стандартам и работать с опытными людьми. А это документация, и гарантии в работоспособности.
2. Короткое время...Знание Апи...Это все опыт. Проще переписать заново/переставить, чем разгребать чужие баги и искать хэтчколбэки и прочие мелочи. И не работать с неадекватными клиентами..И не брать работу, которая по скиллу выше. Тоже по этим причинам отказывался от некоторых проектов.
3. 200-300уе за тему - это нормально. но не для нашей страны. Но вы ж учитывайте - там совсем другой порядок цен. Им проще заплатить вам 300уе, чем 600 по месту. И по поводу сборки в целом. Они не тупые и не умны. Это все относительно.
ЗЫ. про машинные ресурсы.. оптимизация, оптимизация и еще раз оптимайзинг
Вам приходилось доказывать что вам нужен мощный хост для проекта, пытаясь "домохозяйке" объяснить - зачем? (ну что бы не пугать заказчика выражениями на мЭстном жаргоне о серваках и тэдэ). В некоторых случая - получалось 
Гы. Я сам юзаю модули, переписываю их части под свое усмотрение, ломаю, изучая апи т.д.. Реализованно далеко не все. Порой надо поставить 10 модулей, только лишь для вывода одной строчки. Было и такое. Вьюсы - да, модуль незаменим. Но есть и куча других. Кстати, под 5ку нет яндекс мапы
от и тема для размышлений. Есть она под 6ку правда. Но чето на 6ку не хочется переходить пока что... Жду 7ку..
Мир вам. Любезнейший.
Про машинные ресурсы. Нагрузки разные бывают
Как и проекты 
как бы не совсем так. патчилось.
30 тысяч строк своего кода. большой проект. 5ый друпал. сколько времени/денег портирование съест?
скорее всего огромное количество костылей
не спасут тебя на нагрузке в пару тройку десятков килоюников в день
а вытаскивать данные из cck + views и срочно писать велосипед надо будет "уже вчера".
А чего у Вас с русским? Не родной?
старые привычки. 6-8 лет назад не всегда успевалось подобрать аналоги в великом и могучем... в итоге аналоги подобраны, а привычки остались
хаха, ребята, вы спорите не о том =)))
лучше посоветуйте почитать что нибудь полезное
интересует аякс на двигле. есть пару статей, но все не то.
Отличная статья. Не гоните на автора, для новичков самое оно, когда нужно быстро сделать галерею.
Dan, а когда будет 2 часть? Мы все ждем.
так никто ж и не гонит, как вы выразились. и слово йух не говорят вслух
просто спор. как рождение истины
да, сделать быстро - самое оно. и я ЗА такой вариант. как для новичков, так и для профи. Но ведь галереи разные бывают. С различной архитектурой, которую вопроизвести с помощью вышеуказанно ну ни как не выйдет
и наоборот. Соглашусь, что париться кучу времени ради того, что делается за пол часа - смысл? все зависит от поставленной задачи...
да, когда вторая часть? хочу узнать о темизации от того, кто это делал... больная точка ( (это не про тимплейты, это про темизацию)
answer. она готова, надо просто её оформить. думаю будет сегодня.
Спасибо за статью! Очень жду вторую часть. Как раз озабочена галереей.
[Вторая часть руководства]
Прикольно слушать разных людей:) Я придерживаюсь принципа: «Больше подходов — больше свободы»:) Никогда не знаешь, кто именно будет конечным юзером, подумайте, может кому-то будет совсем грустно разбирать нахаканое-на-гольном-PHP? Отвечаю: большинство конечных юзеров не профи в веб–разработках и никогда не хотят с этим разбираться...
Вообще есть модуль CCK Gallery... Сейчас смотрю на тему пригодности для пары сайтов.
Не мог не влезть....
У меня на 000webhost.com работает....
сделал всё как указано но в итоге выдаётся вот такая вот страничка и на Gallery и Image
"Страница не найдена
To create a new Gallery, a referenced piece of content must be specified in the link you followed.
Запрашиваемая страница не найдена"
Такая же ерунда, при создании типа документов Изображение, выдает эту ошибку. Сделала все по инструкции )))
Причем это сообщение выдается только, если в типе документов созданы 2 поля: и Gallery и Image.
Если присутствует только поле Image, то документ создается.
В чем может быть ошибка?
Image можно создавать только из галереи, щёлкая на кнопке "Add photo".
Вы можете изменить это поведение, задав другую опцию, вместо "Fallback behavior: Display page not found error".
День добрый. Судя по описаниям и подробности руководства решил попробовать такую вот галерею. Я уже пару недель пытаюсь что-то сделать для сайта, где приоритетом являются галереи изображений. Ничего не подходит, но это решение вроде то что может подойти.
Закончив с первой частью, всё создав, всё настроив был немного растроен тем, что у меня не создаётся новый материал "Галерея". Создано было как и надо и "Image" и "Gallery". Выдаёт при нажатии на тип материала "Gallery" : "To create a new Галерея, a referenced piece of content must be specified in the link you followed."
Что это значит?
По логике вещей надо ведь создать в начале галерею, а потом уже внутри неё добавлять изображения?
Приступать ко второй части настроек нет смысла пока не создаётся галерея как тип материалов.
Помогите разобраться, а? Очень уж нужна вменяемая галерея.
Такое сообщение должно возникать только при создании изображения вне галереи.
Уверен, что вы неправильно создали галереи. Попробуйте импортировать типы материалов и списки.
Я уже отвечал на подобные вопросы, поищите во второй части.
Спасибо за подробный рассказ уже в двух частях. Я сперва посмотрел скринкаст, потом нашёл Views gallery, выполненный по его мотивам, а затем увидел, что вы всё тот же скринкаст так замечательно разобрали и растолковали. Лично для меня данное решение удобно тем, что все необходимые модули уже и так установлены и используются на моём сайте.
Единственное, что лично меня пока удерживает от использования модуля, так это сложности с полноценной привязкой Thickbox/Lightbox, которые бы были весьма полезны при работе с данным модулем. В комментариях к самому скринкасту один из пользователей сказал о том, что ему удалось разобраться в этом вопросе и у него всё заработало, но пока не растолковал, как именно он это сделал. Об этом его спросили и на орге.
Судя по всему, имеется ещё аналогичный по сути модуль Node Gallery, который почему-то у нас почти не упоминается. Модуль в альфе, но перспективы у него хороши, как мне кажется. Тем более, что в нём уже есть полноценная поддержка Lightbox2.
Я вообще не вижу проблемы в LightBox - два щелчка мыши во views. А, ну ещё imagecache настроить, но это тожене проблема.
Ну, у меня тоже проблем почти не возникло в случае с Lightbox. Единственное — я не могу выловить Лайтбоксом все изображения, находящиеся в галерее за раз — показываются только те, которые находятся на данной странице.
Ну да, таков принцип LightBox'а. Если нужно вывести все фотографии, то необходимо сделать скрытый список ссылок, который будут вести на остальные фотографии галереи. Решения навскидку не вижу.
Хотя...
Может попробовать прикрепить к списку дополнительный список со всеми изображениями галереи? Там будут дублироваться часть изображений, надо посмотреть как LB на это отреагирует - будет выводить их дважды или правильно объединять.
Dan не могли бы Вы (или кто угодно другой) чуть более подробно обьяснить прикручивание LightBox2, совсем запутался в настройках
В настройке списка, в полях, там где указываете какую использовать настройку (preset) imagecache использовать, найдите строчки начинающиеся с Lightbox. Дальше понятно думаю будет.
М-м-м... Да, возможно стоит это попробовать. Спасибо.
После прохождения первой части получил вот такое
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 отображается, но в выпадающем списке галерей пусто, хотя я парочку заводил.
заранее спасибо!
Этот вопрос задан примерно раз пять. Добавлять изображения нужно из галереи.
можно их перенаправить на галерку автоматом, если они заходят напрямую на add, типа защиты от дураков.
На какую? Если у вас 10 галерей, то на какую надо перенаправлять?
Разумнее просто скрыть пункт меню node/add/image.
Ну хотя бы на "главную/первую/личную", или можно просто выдать сообщение что node/add/image недоступен.
Спасибо за статью!
Ну так и происходит. Просто сообщение перевести на рус. язык.
Итак варианты:
1. Редирект куда-нибудь.
2. Перевод сообщения.
3. Скрытие пункта меню.
Выбирайте нужный.
Доброго времени суток. Пытаюсь сделать галерею по описанию. У меня такая проблема: после добавления аргумента views, исчезает отображение галереи внизу, ну и в итоге ничего не получается. Подскажите, пожалуйста, в чем может быть дело?
Прошу прощения, получилось. Все-таки имела место ошибка. Вот только image cache перестал нормально работать: изображения не сжимаются, а обрезаются, так что у меня куча безголовых моделей получилась. Хотя в настройках scale and crop.
Именно из-за "..crop" и обрезаются. Без обрезки - это просто scale.
Если у тебя все фотографии - "сверху - голова, ниже - остальное", то ставь обрезку по высоте не центр, а верх (top).
Ну и посмотри модулёк [module=imagecrop] - возможно лучше через него сделать обрезку.
Спасибо!
У меня все получилось, но не могу понять зачем нужны модули views_attach и token, ведь вывод всех фото (Gallery teaser images) и отдельного фото (Gallery full node images) можно сделать через views+Viewfield.
Может я чего-то не понимаю и views_attach+token делают что-то другое?
Можно. Сделайте, если Вам так удобнее. Я например считаю, что использование Viewfield [в данном случае] менее удобно, нежели views_attach.
Dan, спасибо за ответ.
Я конечно понимаю, что в этом варианте можно так и так сделать, но мне интересно узнать о том какие преимущества дают эти модули (views_attach+token). Просто может с этими модулями в альбомах можно сделать что-то что нельзя сделать с Viewfield?
Дело не в преимуществе, а в удобстве использования для конечного пользователя. С viewfield пользователю при редактированиии материала необходимо что-то где-то выбирать, указывать, возможно даже думать
С views_attach закулисы от пользователя скрыты - он просто создаёт контент. От токена, кстати, он уже не зависит, просто рекомендует. Ну и несколько кирпичей в огород viewfield:
- стастика использования для 6.х в два раза ниже чем у views_attach
- отсутствие релиза для 6.х
- открытых багов - 19 (против 2-х у views_attach).
Всё это не критично, но при прочих равных условиях я предпочитаю views_attach.
Dan, спасибо.
Подумываю теперь о замене viewfield.
А шестерки есть версия - viewfield 6.x-1.x-dev.
Версия есть, релиза нет
Return path: The page the link was clicked on - у меня есть только пункты the new node, the previous page, the referenced node.
Что выбрать-то???
Мда, скорость ответа на мой пост впечатляет. В общем, я поставил модуль CCK Gallery. Вроде работает, ничего настраивать особо не пришось. А по вашей статье не получилось сделать ничего из-за выше описанной проблемы, как я полагаю.
Ох простите, Ваше Сиятельство, не заметил что пост был от Вашей Милости! Иначе всенепременно ответил бы в тот же миг! Прошу - не будьте ко мне слишком строги, постараюсь непременно загладить вину свою!
У других получилось.
Не серчайте, если что. Я не со зла.
За статью всё равно спасибо! Пусть не мне, но другим она точно поможет. Зато я научился немножко работать со вьюсами, когда настройки делал по вашей статье. Так что вы не напрасно трудились. Низкий вам поклон.
А вы вторую статью смотрели? Основное - там. Плюс там есть экспорт типом материалов и списков -- сделал специально для случая "быстро сделать, потом разбираться".
Собственно это и было задачей статьи. Сами галереи в друпале можно и модулями сделать, а вот понять как работают вместе CCK и views лучше решая конкретную задачу.
Да, разумеется я смотрел вторую статью. Когда у меня ничего не получилось, стал искать в чем ошибка, но так и не удалось исправить...
А вы не подскажете случайно, как поступить в этом случае? А то сейчас назрела уже другая проблема, которую нужно решить, и понимаю, что в одиночку у меня не получиться это сделать, т.к. не хватает знаний и опыта... С PHP я знаком немножко, но несколько не понимаю, что конкретно там нужно сделать.
Все супер, рецепт использую давно и с удовольствием.
Кстати, прикрутил таб "комментарии" - показывает комменнатарии к конкретной галереи (что-то вроде как вконтакте) - если надо кому, напишу.
Вот только вопрос: кто-нибудь пытался настроить права доступа к ссылке "добавить фото"? Ведь в текущей реализации ссылка доступна всем. А хотелось бы, чтобы в галерею мог добавить фото только автор (ну или роль). Почему field-permision на это поле не срабатывает.
[module=nodeaccess_nodereference]
Dan, простите, а вы сами этот модуль настраивали на такую задачу? Не могу врубиться в логику работы. Как галки не выставляю - ссылка "добавить фото" видна как автору галереи, так и не_автору.
Нет, я с ним не работал.
Насколько я помню (могу ошибаться), модуль nodereference_url формирует ссылки "добавить фото" как стандартные node-ссылки. Если это так, то их можно переопределить через hook_link_alter
Прочитал практически все, что написано тут про галереи. Но так и не смог разобраться. Буду очень благодарен, если поможете. Задача у меня такая: Нужно создать галерею таким образом, чтобы альбомы выводились в разных пунктах меню. Сейчас получилось только вывести в меню каждый альбом отдельно. Но альбомов много, поэтому это неудобно. Нужна подобная структура: Пункт меню 1, по клику на него выводятся как-бы миниатюры альбомов - альбом1, альбом2, альбом3; Пункт меню 2, по клику - альбом4, альбом5, альбом6. Ну и т.д. А уже по клику на миниатюру альбома, выводится сам альбом. И чтобы можно было листать фотографии во всплывающем окне.
Можно ли как-то реализовать такую структуру, не используя модуль Views? Или тут никак без него? Заранее спасибо всем, кто откликнется.
Без views - можно, своим модулем.
Мне до своих модулей еще как до Китая пешком)
Уже более-менее разобрался) Получилось норм вроде) Правда вывод миниатюр нескольких альбомов на одной странице не получилось сделать, но это можно решить созданием страницы с картинками в тексте, где картинки будут ссылками)
скачала более старые модули, которые в статье есть, пропатченные, теперь Arguments активные, добавила в них [nid], но все равно не помогло
упорно выводятся только ссылки на изображения, а не картинки :((( 150 раз все перепроверила, не понимаю, что не так! Подскажите, пожалуйста, в чем может быть проблема? куда смотреть?