pwnz22

Все, я понял в чем неувязка. Языкизация полей происходит в момент их выгрузки из БД. Так как поле add_by добавлено на лету в ручном режиме, то оно минует эту процедуру.
Я вам в local_kvartira_search.php (строки 95-98) накодил вариант обхода. Вы его можете применять к аналогичным рукотворным полям.

В файле realy_grid_list.tpl нужно добавить в ссылку объекта a с классом title_link,  target="_blank". Получиться что-то типа <a class="title_link" href="{$grid_items.href}" target="_blank">

http://amateurblogger.ru/mozhno-li-polzovatsya-target_blank-vopros-ot-chitatelya/- подробно разъясняется.
А если в двух словах то Атрибут target="_blank" является невалидным атрибутом и его использование допускается только в переходных Transitional документах и в спецификации XHTML Strict его уже нет.

В сайтбилле используют шаблонизатор Smarty. Поэтому скрипты и ксс  нужно засовывать в тэг {literal} скрипт {/literal}
<style type="text/css">{literal}.ya-page_js_yes .ya-site-form_inited_no { display: none; }{/literal}</style><script type="text/javascript">{literal}(function(w,d,c){var s=d.createElement('script'),h=d.getElementsByTagName('script')[0],e=d.documentElement;if((' '+e.className+' ').indexOf(' ya-page_js_yes ')===-1){e.className+=' ya-page_js_yes';}s.type='text/javascript';s.async=true;s.charset='utf-8';s.src=(d.location.protocol==='https:'?'https:':'http:')+'//site.yandex.net/v2.0/js/all.js ';h.parentNode.insertBefore(s,h);(w[c]||(w[c]=[])).push(function(){Ya.Site.Form.init()})})(window,document,'yandex_site_callbacks');{/literal}</script> вот так будет работать

Спасибо За Помощь!!! Отдельное спасибо Константину (Аbushyk) Любая просьба касаемая редактирования сайта, доработки страниц, выполнялась без проблем! Отношение человеческое, это редкость! Спасибо!!!!!  Побольше бы таких людей!!!

Можно как нибудь вставить валюту возле цифр цены на форме поиска? 

http://www.etown.ru/s/topic/2276-убираем-page1/?p=24792 сабж

Можно попробывать в main.php вашего шаблона добавить условие
 
if(!isset($_REQUEST['page'])){
    $_SESSION['rem_page']=1;
}
 
Должно сработать

Сделали все правильно,но это для словие нужно использовать как раз в классе т.е. <div class="{if .... } background {/if}">

Незнаю хорошее решение ли это. Можно условием сделать так : 
{if $REQUEST_URI=='/'} тут свойства на бэкграунд прописать{/if}

Незнаю хорошее решение ли это. Можно условием сделать так : 
{if $REQUEST_URI=='/'} тут свойства на бэкграунд прописать{/if}

Для форм скоро будет обновление, чтобы их переводить.

Этот код генерирует плагин преттиФото. У него есть чудесный параметр
counter_separator_label: '/', /* The separator for the gallery counter 1 "of" 2 */ В хидер.тпл или в другом месте, где у вас на галлерею подключается плагин, нужно в инициализатор добавить свое значение
 
$("a[rel^=prettyPhoto]").prettyPhoto({ social_tools: false, theme: 'light_square', counter_separator_label: ' из ' });

1. во вторй части уже не нужно проверять на ноль. вы сделали это в первой части. если ноль, то просто не будет параметра этого.
2. вторая часть должна выглядеть так:
if(isset($params['added_in_days'])){ $date_limit=date('Y-m-d H:i:s', (time()-($params['added_in_days'])*24*3600)); $where_array[]='('.DB_PREFIX.'_data.date_added>=\''.$date_limit.'\')';} темплейт_сеарч не поддерживает плейсхолдеров в запросе. поэтому нужно в запрос включать и параметр сравнеия, а не знак вопроса
3. Для первой части я бы расширил условие
if(0<(int)$this->getRequestValue('date_added') && (int)$this->getRequestValue('date_added')<20){$params['added_in_days'] = (int)$this->getRequestValue('date_added');} что бы не было желающих поискать объявления от начала времен.

В вашем Template_Search надо указать для square_all, что вы ищете по промежутку.
План таков:
1) Отправка с формы. с формы у вас должно уходить два параметра - мин. и макс. по square_all (два текстовых инпута с именами square_all_min, square_all_max - эти имена не обязательно должны быть такими, но лучше использовать системное имя колонки и через подчеркивание постфикс min\max). Метод добавления этих инпутов в форму не важен. Можете вручную указать их в шаблоне, можете использовать параметр is_ranged=1 для square_all_min, еси используются локальные формы поиска.
2) Перехват параметров. эти параметры должны быть перехвачены. Часть параметров, такие как floor, floor_count обрабатываются самим движком изначально даже если они переданы в виде floor_min\floor_max, но большинство параметров надо перехватить. Для этого в Template_Search в getParams надо указать
if(''!==$this->getRequestValue('square_all_min')){    $params['square_all_min'] = $this->getRequestValue('square_all_min')}if(''!==$this->getRequestValue('square_all_max')){    $params['square_all_max'] = $this->getRequestValue('square_all_max')} т.е. именно square_all_min и square_all_max.
Если вы считаете, что ваши параметры должны быть целыми числами, тогда смените условие на 
if(0!==(int)$this->getRequestValue('square_all_min')){    $params['square_all_min'] = (int)$this->getRequestValue('square_all_min')} что бы не учитывать нулевых и пустых згачений.
 
3) Определение условий. В Template_Search в run() необходимо обработать отфильтрованные параметры
В вашем случае
if(isset($params['square_all_min']) && isset($data_model_array['square_all'])){    $where_array[]=DB_PREFIX.'_data.square_all>='.$params['square_all_min'];}if(isset($params['square_all_max']) && isset($data_model_array['square_all'])){    $where_array[]=DB_PREFIX.'_data.square_all<='.$params['square_all_max'];} Вы проверили, перехватился ли параметр, пс ли поле, на которое ссылается параметр в модели (вдруг вы давно его удалили, а условия поиска не почистили) и указали, как оно должно наложить условие на выборку из БД.
 
 
В конце этих манипуляций вы возвращаете в движек массив условий фильтрации, который будет применен к выборке и массив перехваченных параметров, что бы они были учтены во всяких пейджерах\ссылках сортировок.
 
NB. Если вы не используете пользовательские сетки и локальный local_grid_constructor.php то движек автоматически должен обработать в виде диапазонов следующие поля
 
price_min, price_pm_min - ишется по полю price цена большая от price_min, price_pm_min
price , price_pm - ишется по полю price цена меньшая от price , price_pm
floor_min\floor_max - ищется по полю floor  значения большие/меньшие от floor_min\floor_max
floor_count_min\floor_count_max - ищется по полю floor_count значения большие/меньшие от floor_count_min\floor_count_max
square_min\square_max - ищется по полю square_all значения большие/меньшие от square_min\square_max
not_first_floor - ищется по полю floor значения для которых floor не равен 1
not_last_floor - ищется по полю floor значения для которых floor не равен значению floor_count 
live_square_min\live_square_max - ищется по полю square_live значения большие/меньшие от live_square_min\live_square_max
kitchen_square_min\kitchen_square_max - ищется по полю square_kitchen значения большие/меньшие от kitchen_square_min\kitchen_square_max
 
Это поведение наличествует в данный момент, но не обязательно будет поддержано в дальнейшем.
 
Иными словами, условия для таких полей включать в Template_Search не нужно.

Дайте ему имя на форме not_last_floor и будет вам счастье.
Этот параметр обрабатывается автоматически. При нахождении такого параметра в запросе со значением равным 1, автоматически применится условие отфильтровывающее те записи у которых этаж и этажность совпадают.

В корне неправильный подход.
realty_grid_html.tpl - это шаблон блока ОДНОГО объявления в выборке. Весь ваш список результатов поиска на карте будет состоять по принципу из
realty_grid_html.tpl для первого найденогоrealty_grid_html.tpl для второго найденого...realty_grid_html.tpl для последнего найденого Вставлять туда количество найденых не имеет никакого логического смысла.
Тут разве что в самом search.js где вы формируете списко блоков вычислять длину json и доабвлять ее в качестве количества найденных.

Плохое условие
{if $item.optype == 'Продам'} лучше
{if $item._optype_ == N} где N - идешка соотв. контракта

Добавил чекбокс в форму поиска. (Не последний этаж) Подскажите условие поиска...

Валюта по умолчанию устанавливается в Настройках->Общие - Название валюты в личном кабинете (ue_name).
Там-же активируется менеджер валют (если работаете с несколькими валютами) - галочка на позиции Включить поддержку выбора валют в объявлении (currency_enable), в этом случае валюты дополнительно правятся в Приложениях->Менеджер валют
Отображение цены и валюты на сайте и в ЛК правится в соответствующих файлах .tpl в Приложения->Редактор шаблонов, например:
- главная на сайте и последующие - realty_grid.tpl и как вариант (если шаблон Realia), то в realty_grid_list.tpl и в realty_grid_thumbs.tpl (варианты отображения объявления строками или блоками);
- на странице просмотра объявлений - realty_view.tpl;
- в ЛК  (список объявлений) - realty_grid_account.tpl;
и т.д. (всё, что похоже на realty_grid_###.tpl, top_special.tpl - спецпредложения, realty_on_map.tpl - объекты на карте...)

Нужно включить в ./index.php русскую локаль
setlocale(LC_ALL, 'ru_RU.UTF-8'); Затем в шаблоне использовать функцию 
strftime('%S', strtotime($grid_items[i].date));

эти условия следует формировать так
if([если перехвачен параметр по которому происходит поиск] И [в текущей модели data есть активное поле по которому происходит поиск]){ тогда описываем условие поиска} если ищем по полю date_added, то 
if(isset($params['date_from']) && isset($data_model_array['date_added'])){     $where_array[]='('.DB_PREFIX.'_data.date_added>=\''.$params['date_from'].'\')';} $params['date_from'] стоит заключать в кавычки в выражении, так как оно скорее текстовое. А в перехвате из запроса нужно гарантирвано приводить date_from к нужному виду
if(preg_match('/^(\d\d\d\d-\d\d-\d\d)$/', $this->getRequestValue('date_from'))){    $params['date_from']=$this->getRequestValue('date_from');}

1) каждый функционал имеет два аспекта - внутренний (сбор данных для карты, который относится к высоконагруженным операциям) и внешний (рисование собранных данных в шаблоне). Часть настроек регулирует именно внутренний аспект. Т.е. его можно включить или выключить, но шаблон сам решает куда и когда выводить собранные данные если они есть. Поскольку "карта на главной" это опция, которая присуща далеко не каждому шаблону в силу особенностей дизайна, то ее вывод может потребовать некоторых трудозатрат.
 
2) дальше влияет само понятие "главная страница". Сам по себе этот признак абстрактный и может обозначать разные вещи в рамках разных концепций. Поэтому и все штучки связанные с "главной страницей" могут управляться именно логикой шаблона. В данный момент основным признаком главной является - пустой урл и отсутствие GET-переменных запроса. Для массы случаев это подходит, но ни в коем случае не является единственно правильным решением.
 
3) другой вариант отображения не всегда ок. Они весьма различны друг от друга и переключение между ними может слишком сильно изменить логику "главной" страницы. Другими словами эти режимы предназначены для первичного выбора вида отображения, а не для регулярных переключаний между ними. Для запущенного сайта вообше имеет смысл зачищать шаблон от неиспользуемых отображений и шаблонов, что бы сократить количество условий в шаблонах.
 
4) но если до этого момента шаблон был запущен в режиме "без главной", так называемый classic, то переключение в режим отображения одной из "главных" страниц типа slider или map изменит входную страницу до неузнаваемости. Грубо говоря имеет смісл переключаться между однотипными режимами, но не между принципиально разными.
 
 
 
Тут принципиально неверный подход. На текущем режиме отображения на вашем сайте нет смысла включать или выключать карту на главной, поскольку главная страница представляет собой просто одну из страниц листинга. Но так как там есть еще вторая настройка "Выводить карту со списком", которая включена, то карта выводилась у вас естественно на каждой страниц на который присутствовал хоть один элемент с указанными геокоординатами.
 
Я сделал следующее. Поскольку на этом режиме гпризнак главной страницы не устанавливается и для вывода используется стандартный шаблон листинга, то в /main/main.php в 582 строке при условной нахождении на главной (см. выше пункт 2) я указал шаблону метку
$this->template->assert('homepage', 1); после этого в шаблоне самого листинга /realty_grid.tpl все строки
{if $geodata_show_grid_map==1} ,которые управляют выводом карты со списком, я дополнил еще одним условием
{if $geodata_show_grid_map==1 && intval($homepage)!==1} и теперь оно проверяет не только нужность вывода карты, но и момент нахождения на главной, при попадании в которое карта не рисуется. это не совсем верное решение, но в данном случае действенное.
Для возврата к штатному поведению, достаточно в /main/main.php удалить 582 строку.

такс))) ваши желания опережают мои возможности)))
Тип photo используется и обрабатывает исключительно в контексте модели user. Прикреплять его куда либо, кроме нее не имеет смысла. Это очень древнее поле. Я сейчас разрабатываю отдельный элемент под подобные цели, который можно будет использовать в любых моделях.
 
Если есть необходимость хранить фотку владельца в данных объявления, лучше пока использовать поле типа uploads. они явно избыточны, но применимы в любом объекте.

Поиск по дате. Поля я добавил. Думаю сориентируетесь. Изменения в local_kvartira_search.php и двух файлах форм поиска - advanced и standart. Вам остается прописать в темплейт_сеарч условия поиска по ним и подправить стили на элементах формы.
ПС. В принципе движек умеет обрабатывать аналогичные поля, но вот только не умеет их перехватывать сам из запроса.
 
По типу добавившего там же добавил поле add_by