Так а что там придумывать ?

Берете готовое решение на JQuery, которое может подгружать несколько фоток.

У этого решения должно вызываться свое событие (event), когда очередная фотка загрузится.

В этом событии будет в том числе и имя загруженного файла.

Далее, на это событие вешаете свою AJAX-функцию, которая будет принимать параметром название файла и создавать ноду, у которой файл такой-то.

Это описание работы в общих чертах.

Ну, во первых, если нод около 30, то имеет ли смысл использовать views infinite scroll ?

А если это нужно принципиально (допустим, клиент захотел, чтобы плавно подгружалось, и не переубедить), то может быть, попробовать это сделать без views и views infinite scroll ?
Например, написать SQL-запрос и вытащить несколько первых нод.
А для плавности самому подключить jquery autopager и подгружать аяксом новые ноды.
Ну а по нажатию на меню запустить подгрузку несколько раз подряд до тех пор пока нужная нода не подгрузится. На неё потом и перейти.

А если, например, Вы с помощью меню хотите вызвать ту ноду, которая еще не подгрузилась с помощью Views Infinite Scroll, то как в этом случае Вы делаете ?
Принудительно запускаете подгрузку, пока эта нода не подгрузится ?

Кстати, да, можно явно задать два пункта меню, у которых ссылки будут типа node/1#a1 и node/1#a2

А как сделали ?
Явно в меню прописали адреса с якорями ?
Или по-другому ?

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

Думаю, в сумме проще и легче будет взять какое-нибудь JQuery-решение и интегрировать его на сайт. Документация там, как правило, есть.

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

А если темизировать элементы меню, чтобы они ссылались не на "node/NID", а на эту же страницу с якорем ?

whiesam wrote:

Я так понял тут стояла задача удобной загрузки большого кол-ва фоток. Ясен пень что лучше делать 1нода-1фотка, но вот загружать это дело...

Думаю, тут руками надо будет всё делать.

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

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

Думаю, можно также через Display Suite - задаешь новые поля, в которых прописываешь всё, что нужно, и ставишь их между полями с данными.

"Boozenok" wrote:

у Privatemsg вроде есть интеграция с realname

Да, в PrivateMsg есть модуль, который делает интеграцию с RealName.

Посмотрите, каким образом оно там реализовано, какие хуки задействованы и т.д.

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

Попробуйте Entity Translation.

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

Либо надо делать проверку на словарь.

На какой страничке ?
На странице ноды, в которой этот терм используется ?

Так а что это за ситуация, когда Вы знаете значение терма, но не знаете его tid ?

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

Если у бизнеса на это, ТИПА, денег нет, то можно или вообще не заморачиваться, или попробовать вариант с интернет-магазином в виде сервиса.

Например, вот - http://storeland.ru/about/pricing

Думаю, у бизнеса 99 руб в месяц должно найтись на абонплату.

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

Думаю, можно поступить таким образом. Хотя сам такое еще не делал.

Устанавливаете Drupal Commerce.
В ней заводите товар.
К примеру, "Пакет за 70 рублей".
Далее, при оплате этого товара делаете так, чтобы выполнялось правило (rules), которое бы данному пользователю начисляло столько-то юзерпоинтов.

Сама ситуация какая-то странная и откровенно несерьезная ...

Есть некий бизнес.
Бизнесу нужен сайт, который должен каким-то образом еще и синхронизироваться с 1С.
Причем, сайт необходимо сделать срочно.

Сделать постановку задачи и заказать сайт в фирме (что как раз позволило бы сделать срочно и качественно) - не вариант.

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

Можно в своей теме переопределить template_preprocess_taxonomy_term.

Если словарь - такой-то, то "weight" элемента с описанием задать больше, чем "weight" элемента со списками нод. (или, наоборот, меньше - сходу сказать не могу).

Так этот список у Вас по умолчанию и должен выводиться.

Так как в данном случае происходит вывод не ноды, а термина таксономии (см. сгенерированный html-код).

Остается или перетемизировать вывод страницы термина таксономии данного словаря, или попробовать переопределить вывод через panels.

Скриншот выложите, чтобы было понятно, что сейчас происходит и что нужно.