abushyk

в данный момент поиск работает по принципу И. Т.е. выбрав город, район и улицу в результате вы получите те объявления которые имеют совпадающие все три этих значения. при этом абсолютно не учитывается наследование. Т.е. вы можете отправить в поиск Москва и Кронштадский район(СПБ) и, если объявления с такими кривыми геоданными есть, оно будет найдено, даже не смотря на то, что искомый район будет привязан в справочнике к СПБ, а не Москве.

1. после установки по умолчанию города родительствуют к районам. просто проверить наличиие поля district_id в модели city, проставить к районам соотв. города и проверить включенность галочки Настройки - Дополнительно - Ajax обновление района 2. зависит от шаблона. для этого нужно будет сделать некоторые изменения в шаблоне формы поиска. Так сделать нельзя. улица всегда привязана либо к городу, либо к району.

Наш. Но есть трактовки. Когда верстался шаблон трактовалось так, что "рабочая" (реальная) цена в price а в price_discount "замануха", которая может указывать какие профиты будут, если ее покупать при некоторых условиях или вообще цена до скидки. Т.е. что именно зачеркивать, а что выводить в незачеркнутом виде не является непререкаемой истиной и должно решаться именно из логики этих двух цен. И price, и price_discount с точки зрения шаблона всего лишь метки для некоторых цифр не имеющих объективного смысла.

Проблема на обычном списке в админке или на настраиваемом, где можно выбирать отображаемые колонки?

Лучше там где вы указали, но после последнего {/if}. Не стоит вносить вывод описания внутрь условия, которое не связано с описанием, так как последний if проверяет наличии объектов в выдаче, а текст, в принципе, стоит выводить, даже если объектов не нашлось.

Это был вынужденный шаг. Решение Дмитрий описал правильное и единственно верное.

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

Вшитый поиск по цене (по тем значениям которые приходят из формы поиска с именами price, price_min) выполняется по полю price из модели data. Добавление, переименование или изменение полей для разных цены в форме поиска не изменит сам способ поиска в коде, так как они не связаны между собой. {if $grid_items.price_discount > 0} {*старая цена у нас описана*} <div class="price"> {$grid_items.price|number_format:0:",":" "} {if $grid_items.currency_name != ''}{$grid_items.currency_name}{/if} {*выводим текущую цену!!!*} <div class="price_discount">{$grid_items.price_discount|number_format:0:",":" "} {if $grid_items.currency_name != ''}{$grid_items.currency_name}{/if}</div>{*выводим старую зачеркнутую цену!!!*} </div> {else}{*старая цена не описана*} <div class="price">{$grid_items.price|number_format:0:",":" "} {if $grid_items.currency_name != ''}{$grid_items.currency_name}{/if}</div>{*выводим текущую цену!!!*} {/if} тут просто в первом условии "вверх ногами" были использованы переменные с ценами

Я правильно понял, что путем манипуляций с формой поиска производится попытка заставить выборщик данных искать ценовые границы по полю price_discount вместо стандартного price?

то, что позволено Юпитеру.... в списке и в карточке способ доступа к данным немного отличен. если в списке вы обращаетесь по прямому имени переменной $data.topic_id и получаете чисельное значение идешки раздела, то в карточке доступ идет через $data.topic_id.value для идешки и $data.topic_id.value_string для текстового представления - напр. имя раздела. так что в карточке (выводе данных объекта) наверное будет $data.type.value использоваться в сравнениях. И что самое поразительное, в похожих, о которых насколько я понял идет речь, будет использоваться так же как и в карточке, хотя это список)))

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

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

/apps/system/lib/sitebill.php SiteBill::get_page_links_list()] если опишете подробнее, может смогу что подсказать.

Совершенно верно. В самом общем случае, практически любой файл из шаблонов приложений, если он конечно поддерживает локализацию, может быть переопределен таким способом, а при переопределении используется простое правило замены /apps/application_name/site/template/template.tpl - исходный файл на /template/frontend/имя_вашего_шаблона/apps/application_name/site/template/template.tpl - локализированный

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

Указывается в днях - целые числа. Говорит на сколько 24-х часовых промежутков в глубину от "сейчас" следует делать выборку объектов. Если не указана или указан 0, тогда выбирает все доступные к выборке.

Значения в настройках приложения под именем "Признак продажи\аренды" обозначают именно признак продажи или аренды. Например поле Тип операции (optype) обозначет тип контракта в виде селекта выбора 1-аренда, 2-продажа. Тогда в афи-настройках следует указать optype:1 для признака аренды и optype:2 для признака продажи. Это не цена продажи, а именно признак того, как определить объект, который продается, а не сдается и наоборот. Указателя откуда брать цену в афи нет. подобное было реализовано только в афито-выгрузчике кажется и парочке узкоспециальных приложений. Большинство приложений ожидает цену (при чем без разницы аренды или продажи) в поле price.

Нет адресата. Данная опция отправляет сообщение юзеру, который есть в списке Пользователи. Если, например, объява обезличенная, не привязанная к какому-то конкретному пользователю или привязана, но у юзера не указано значение email в профиле - то будет получен такой отказ.

А если записать полностью с материком, тогда ошибка остается?

да.

таймзона должна быть меткой. одной из указанных тут http://php.net/manual/ru/timezones.php

а еще лучше скопировать шаблон вывода новости в папку /template/frontend/ваш_шаблон/apps/news/site/template/ и там менять, иначе все изменения в файле в папке приложения будут затираться обновлениями.

нет лучшего варианта, есть наиболее приемлемый. Связанные элементы не позволяют искать по части названия - это все тот же обычный селектбокс, только с дополнительной фильтрацией элементов в зависимости от "вышестоящего" поля. Но если у вас в городе 1000 улиц, то он и будет выдавать эту тысячу. Пример с выбором улицы по произвольной части названия некорректен. Вы приводите скрин с шаблона реалия и вариант выбора с формы поиска улицы. Но не следует забывать, что там приведен элемент обернутый плагином, который имитирует "автокомплит" на обычном селекте и применяется на фронте на любой селектбокс. Но это не системный плагин, а только имитация, которая позволяет сузить список выбора. То, что есть натуральным полем с автокомплитом (autocomplete=1 в параметрах) ищет не от начала улицы, а именно по его произвольной части.

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

устанавливать настроечно поле, которое будет считаться таким, что содержит в себе цену продажи?