Нужно сделать CONTEXTUAL FILTERS
Indexed Node: Author
Путь примерно такой: /user/%/myannouncements
Также установить RELATIONSHIPS
Indexed Node: Author

Материал должен быть проиндексирован. Теперь по ссылке, где % - это uid пользователя будут доступны только те ноды, которые принадлежат данному пользователю из контекстного фильтра. А фильтры будут работать при любом раскладе.

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

Дело в том, что если вы используете Entity Reference, связывая пользователя с нодой и при этом вам нужно еще иметь связь по таксономии, то вы не можете использовать два словаря таксономии и для пользователя и для ноды!!! У вас просто не будет пересечения по таксономии, так как пользователь и ноды используют свои независимые словари таксономии, которые ничего не знают друг о друге (ну во всяком случае без танцев с бубном).

Например, есть user 1, к которому нужно привязать все ноды с термином NEC (у пользователя словарь терминов). И есть ноды, которые относятся к NEC, допустим их пять (а тут словаря нет). Так вот, к этому пользователю нужно прикрепить связь на все пять этих нод. Или наоборот. Использовать ноды, как основные и там же словарь. А уже к нодам прикреплять пользователей. Тогда у вас сохраняется логическая связь.

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

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

На самом деле решений поставленной задачи много. И первое, что нужно сделать, это продумать, как это сделать красиво. А уже потом писать код.

П.С. Кстати, можно вообще не использовать Entity Reference. Если у вас свой словарь таксономии и в нодах и в пользователях, то можно делать связь через термины таксономии. А еще можно вообще не использовать фасетные фильтры, а пользоваться меню таксономии. Сделать вьюху для таксономии и выводить ее через модуль taxonomy display.

Смысл ясен. Чего-либо сложного или нестандартного я не услышал. Все можно решить (большинство во всяком случае) просто через вьюсы. Момент номер один. В вашей конкретной задаче Entity reference нужно удалить и забыть вообще о его существовании. Поясню на примере. К примеру у вас есть нода - некая недвижимость. С сайта некий пользователь хочет сделать пред заказ на просмотр этой недвижимости на какое-то число. Сам заказ - это тоже нода. Которая содержит только дату просмотра и краткий комментарий. Единственный вариант связать этот заказ с этой нодой - это Entity reference. Так как нет никаких терминов таксономии, да вообще ничего нет! Это единственный случай когда можно связать несвязуемое! В вашем случае все вертится вокруг одного словаря таксономии. Этого вполне достаточно (смотрите базовый курс о реляционных базах данных). Это ваша первая ошибка.

Следующая ошибка. Это попытка применения фасетных фильтров. Этот тип поиска - это вообще отдельная тема для разговора. Это не просто поиск - это целое АПИ, которое работает в связке с Search API. Эти модули должны по уму работать с сервером Apache Solr, для которого нужно на сервере устанавливать Java. А сделано это все для того, чтобы можно было проиндексировать некоторые поля в нодах, для которых нужно организовать быстрый поиск по критерию. Настроенные поля индексируются и данные заносятся в базу данных поискового сервера. Это в свою очередь дает возможность производить очень быстрый поиск из поискового сервера по индексам, снижая тем самым нагрузку на память и процессор. А фасетные фильтры используются именно для удобства организации поиска по индексам! А вы же пытаетесь их приплести к логике работы ваших скриптов! Но они этого не умеют, и не должны уметь. У них совершенно другая задача.

Следующий момент. Это рейтинг о котором вы пишите. Тут уже нужно самому думать, как организовать рейтинг. Значение это может быть не линейным и каждый сам должен придумать логику. Пример. Есть два разработчика на сайте со своими профилями. У одного выполнено 30 работ. Установка модулей, правка шаблона и другие мелочи. А у второго разработчика выполнена только одна работы - разработка системы онлайн обучения на 800 часов. У кого рейтинг на сайте должен быть выше по вашему? Грубо говоря, ламер с кучей халтурок и профи с огромнейшим и сложнейшим проектом. Люди будут искать того, у кого рейтинг больше (вроде сделал много работ и люди были им довольны) и будут находить не профессионала, а этого ламера. Хотя цена работы у них может быть одинакова. Надеюсь, смысл проблемы вы поняли.
Если организовать рейтинг через голосования, то можно просто поставить модуль Vote API и установить на него, к примеру - Five stars. И не морочить себе голову. Но такие "рейтинги" годятся к фильмам. Людей и их возможности оценить алгоритмом не реально. И кто судить-то будет? Заказчики, которые во всем этом полные нубы?

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

Опять вышло много букв

Заходите в настройки вашего словаря таксономии и отмечаете пункт Hide empty terms. Что означает скрывать пустые термины. И вуаля. Те термины, которые не назначены не одной ноде больше не будут отображаться. Выводить в блок можно термины модулем Taxonomy menu. Хотите использовать индексацию и фасетные фильтры, значит архитектуру нужно продумать таким образом, чтобы не было головняка с кучей взаимосвязей. Или выводить ноды только одного типа во вьюсы. Так как индексированные поля ничего не знают о других полях. Такова логика работы. Иначе, либо кода тонны писать, либо потеряться и зачахнуть. Если не используете отдельный сервер индексации, а все пишется в ту же друпаловскую базу, то это прямой путь не к облегчению поиска, а к великому геморрою. Вот почти завершенный проект с фасетными фильтрами на друпале http://best-house.org/en/daily_rent
На него уже потрачено более 500 часов самописного кода. Допустим, когда вы выделяете фильтр в фасетах, то отменить действие можно только сняв чекбокс с того же фильтра. Очень не удобно. Пришлось самому написать функцию, которая в блоке выводит выбранные фильтры с возможностью их отмены. Звучит, как мелочь. А кода написано ого-го. И такого добра от мелочи до огромного функционала вагон и маленькая тележка.

"alex_t" wrote:

но и вокруг связей словарей и нод и юзеров.. и в сцепках как раз проблема)

Надо писать код. Нельзя решить задачу без кода. По моей аналогии это бы выглядело так. Слева поиск недвижимости по критерию. Справа ноды. А еще у хозяина этой недвижимости есть пять квартир, которые он тоже сдает. И есть в профиле у него, допустим разные специализации с которыми он работает. Как все вывести сразу в нодах? Делаем вьюху из индексов. Создаем табличный шаблон. Шаблон создаем в теме и кидаем в папку вьюс. Теперь в шаблон будет попадать массив с данными каждой ноды. Из массива могу поличить уид автора, а значит я могу с помощью lode_user($uid) подтянуть весь его профиль. Также я могу подтянуть все ноды нужного типа, которые принадлежат этому пользователю прямо из базы. Грубо говоря, я подтянул в одномерном массиве пять нидов его недвижимости. И могу сразу посчитать количество: $amount = count(массив с нидами);.

Далее прямо в шаблоне делаю: print "<див>У пользователя $переменная с именем юзверя есть еще $amount-1 квартир<закрыли див>";

Это очень грубо! Всего пару строчек кода!