Leaderboard

Можно, массу глюков убрали.

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

Комплектов скобочек может быть несколько. Каждый комплект обозначает одну пачку условий которая будет применена на одном шаге. Например вид {A}{B}{C} обозначает, что похожие будут подбираться путем подбора максимум в три шага. На первом шаге применятся условия А. Если указанное в настройках количество похожих подобрано не будет, то запустится добор по условиям во втором шаге B, и аналогично в третьем. И так, пока не кончатся условия или не наберется необходимое количество. Как верно заметили, условия по величинам типа цены\площади не имеют смісла без диапазонных модификаторов. Т.е. смысл имею, но пользы от них мало, так как подбираться будут объекты точно с такой же ценой. Если расшифровать {topic_id}{price} то получится "найди мне еще объектов в том же разделе, что и просматриваемой, а если их не хватит, добери еще объектов с такой же ценой", что скорее всего не то, что хотелось бы.

Касательно этого списка полей в настройке. В этом поле вы можете указать системные имена полей из модели ЖК на базе которых приложение сформирует массив элементов формы, которые могут быть размещены в рамках какой-то формы. Эти поля используются приложением для поиска ЖК, не объектов в ЖК. Основная масса полей задается как есть - city_id, metro_id - сформирует список выбора по городам и метро на основании элемента, который есть с таким же именем в модели ЖК. Если такого элемента, как вы зададите в настройке, не будет в модели ЖК, то он проигнорируется. Поля типа room_count_1...room_count_6 подразумевают наличие таких же полей в модели ЖК в виде чекбокса, которые обозначают наличие в ЖК объектов соотв. комнатности. Группа полей типа price_min - price_max и square_min - square_max могут использоваться только если имеют такие же поля в модели ЖК. Они не будут искать по одному полю содержащему какую-то цену для ЖК и не будут искать ЖК у которых есть связанные объекты с ценой входящей в диапазон. Все это справедливо и для площади. Поиск по этим полям производится среди ЖК по данным ЖК. Поэтому наличие объектов в data связанных с ЖК и обладающих значением комнатности, не учитывается при поиске по этим полям. Хитрое имя readydate подразумевает наличие в данных ЖК двух полей с именами built_year и ready_quarter - в первом должен храниться год сдачи в виде ХХХХ, а во втором - квартал сдачи в виде числа от 1 до 4. Тогда код на основании данных в этих полях создаст мифический элемент выбора с вариантами "квартал-год". Весь набор этих элементов потом собирается и генерируется в форму поиска в переменную {$complex_search_form} которую вы можете разместить в одном из своих шаблонов. Повлиять на внешний вид формы можно путем локализации шаблона apps/complex/site/template/complex_search_form.tpl в папку шаблона и обдизайнивания ее на свой вкус. Сам поиск может проходить и без видимой формы. Т.е. если параметры элементов формы прописаны в настройке, то передавая их в строке запроса браузера можно уже влиять на список показываемых ЖК, так как эти параметры начинают учитываться