abushyk

Если комнатность уже присутствует в разделах, то чекбоксы количества комнат уже избыточны. Другое дело, что внесение такого разделения в структуру в самом общем случае - сознательное ограничение. Но это не критично и, если логика работы сайта требует именно этого и не требует другого, то допустимо. Да. Ничего не сломается в логике поиска, если убрать с нее какие-то параметры-поля ввода. Поля на форме предназначены только для формирования запроса. Нет полей, нет переменной в запросе, обработчик просто ничего не сделает по этому параметру. Это наши реалии. За границей (США уж точно), в принципе, поиск домов по bedrooms\bathrooms-количествам является чаще используемым. Видимо это связанол с тем, что среднестатистический американец покупает дом, что бы вселиться, заказать уборку и жить, а у нас переезд в новый дом часто подразумевает начало глобальной перестройки его под свою планировку)))

Да. Сечас работает например как. Мы имеем город и район. Сам район привязан к какому-то городу. Но в объявке мы указываем и район и город. Потому для поиска по городу мы можем передать идешку города и фильтрануть по ней объекты. Но если бы у нас город фигурировал в объявке не отдельным полем, а опосредовано через принадлежность района и в объвке был бы указан только район, то для поиска по городу мы бы передавали поиск по идешкам ВСЕХ входящих в город районов. Просто этот способ более накладный и менее наглядный и потому мы держим и город в объявке. но "по уму" должно было бы быть именно так, как вы описали.

бессмысленно, так как в этом случае каждый следующий вариант УЖЕ включает каждый предыдущий. тут множественный выбор не нужен.

да. он их должен нормально воспринимать. если у вас элемент выбора прописан вручную в шаблоне формы, то у него есть аттрибут name <select name="bla"> так вот он должен быть <select name="bla[]">

material=1 - в запросе будет matrial=1 material=1&material=2 - в запросе будет material=2 так как у всех переменных одно имя и последняя перезапишет все предыдущие с таким же именем material[]=1&material[]=2 - в запросе будет material в виде массива, содержащего значения 1 и 2 material[]=1&material[]=2&material=3 - в запросе будет material=3 так как последняя переданная переменная успешно перезатрет весь предыдущий массив с 1 и 2

Потому что вы передаете один параметр два раза вместо того, что бы передать массив значений под одним именем. sait.ru/index.php?&material[]=1&&material[]=2 Красным отмечено лишнее, зеленым - недостающие квадратные скобки.

не делайте так. такое можно сделать в качестве эксперимента или один раз. но делать аткое систематически не стоит. завтра вы переименуете шаблон карточки или сделаете его вариативным от какого-то условия, когда в одном случае будет realty_view.tpl а в другом realty_view_special.tpl и вся эта логика рухнет. Заголовок не должен формироваться в шаблоне. Он же может использоваться еще и в других модулях - в каких-то выгрузках, в рсс, в экспортах. Загнав его в шаблон вы не дадите ему этого сделать. Для нормального формирования заголовков я советую исключительно локализацию модуля карточки. При всей моей либеральности в отношении добавления своегу функционала - тут я скорее настаиваю.

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

В запросе вы передаете переменную, которая является только лишь неким признаком, что она есть и имеет некое значение. Как понимать эту переменную, с чем в БД сравнивать ее значение - все это уже другая история, которая не связана с самим запросом. Это как номер вашего паспорта. Вроде ссылается на вас, но если завтра его у вас забрать и дать этот номер в паспорт другому человеку - то номер будет ссылаться уже не на вас.

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

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

тут следует различать "параметр в запросе" (это то, что у вас ходит в строке запроса браузера и передается с формы - имя окошка для ввода на форме) и "поисковый параметр" - то, по чему в модели или таблице БД будет производиться поиск. Они могут быть одноименными, а могут и не быть. Например я передаю в запросе country_id переменную, но это означает только то, что я передаю такую переменную. По какому значению в данных объекта будет производиться поиск на основании этой переменной не декларировано и будет определяться уже кодом. Если я передал переменную country_id то могу сделать поикс и по региону и по материалу дома. Имя переменной в запросе - это просто имя переменной в запросе. Иногда мне нужно искать по двум параметрам. Например я передаю ready_date и значение "2018-4", что обозначает что я хочу найти жк, которіе сдаются до 4 квартала 2018 года. Но я не могу реализовать поиск в лоб, так как у меня в БД у же есть признаки ready_year (год сдачи) и ready_quarter (квартал сдачи) и они отдельные. Так что переданная ОДНА переменная запроса в формировании выборки распадется на поиск по ДВУМ полям с именами не совпадающими с той, что в запросе. Именно поэтому я передаю raz а ишу в country_id. Так как имена переменных - это условности.

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

Я бы вообще всю графику связанную с внешними клиентами, как почта, располагал бы в отдельной папке в корне сервера. Например в /mail_design. Это и более переносибельно, и по логике не будет путаницы в графике разного предназначения.

Вот сейчас проверил. Заказал в темплейт сеарч обработку параметра raz if(NULL!==$this->getRequestValue('raz')){ $v=$this->getRequestValue('raz'); if(!is_array($v)){ $v=(array)$v; } foreach($v as $k=>$_v){ if(0==intval($_v)){ unset($v[$k]); } } if(!empty($v)){ $params['raz'] = $v; } } Что бы он искал мне по странам if(isset($params['raz'])){ $where_array[]=DB_PREFIX.'_data.`country_id` IN ('.implode(',', $params['raz']).')'; } В результате запрос на выборку ( /?raz[]=1&raz[]=2 ) имеет вид SELECT re_currency.code AS currency_code, re_currency.name AS currency_name, ((re_data.price*re_currency.course)/0.015814) AS price_ue, re_data.* FROM re_data LEFT JOIN re_currency ON re_data.currency_id=re_currency.currency_id WHERE (re_data.`active`=1) AND re_data.`country_id` IN (1,2) ORDER BY re_data.`date_added` DESC, re_data.id DESC LIMIT 0, 12 Т.е. запрос корректен.

Делаем поиск. В принципе его можно реализовать на базе текущего кода, но лучше сделать изменения, что я предложу. 1. /apps/system/lib/frontend/grid/grid_constructor.php Находим строку $results = $Template_Search->run(); Их там несколько, но нас интересует та, что в районе 800-й строки внутри функции function get_sitebill_adv_core После нее добавляем следующие кусочки if (isset($results['where_prepared'])) { $where_array_prepared = array_merge($where_array_prepared, $results['where_prepared']); } if (isset($results['where_value_prepared'])) { $where_value_prepared = array_merge($where_value_prepared, $results['where_value_prepared']); } Это пойдет в обновлениях, так что можете смело поменять в системном файле, если он у вас сейчас актуальной версии. 2. Открываем наш template_search.php файл. Сейчас он имеет вид примерно такой <?php class Template_Search extends SiteBill { public function getParams(){ if(''!==$this->getRequestValue('internal_type_id')){ $params['internal_type_id'] = $this->getRequestValue('internal_type_id'); } /*ДОБАВЛЯЕМ ПЕРЕХВАТ ПАРАМЕТРА word С ТЕКСТОМ*/ if(''!==trim($this->getRequestValue('word'))){ $params['word'] = $this->getRequestValue('word'); } /*ЗАКОНЧИЛИ ДОБАВЛЕНИЕ*/ return $params; } public function run(){ $params=$this->getParams(); $where_array_prepared=array(); /*НОВЫЙ МАССИВ ДЛЯ ХРАНЕНИЯ ЧАСТЕЙ ЗАПРОСА*/ $where_value_prepared=array(); /*НОВЫЙ МАССИВ ДЛЯ ХРАНЕНИЯ ЗНАЧЕНИЙ ЗАПРОСА*/ require_once(SITEBILL_DOCUMENT_ROOT.'/apps/system/lib/model/model.php'); $data_model = new Data_Model(); $data_model_array = $data_model->get_kvartira_model(false); $data_model_array=$data_model_array['data']; if(isset($params['internal_type_id'])){ $where_array[]=DB_PREFIX.'_data.internal_type_id LIKE \'%'.$params['internal_type_id'].'%\''; } /*ТУТ ИДУТ КАКИЕ-ТО НАШИ ОБРАБОТКИ*/ /*ТУТ НАЧИНАЕМ ОБРАБАТЫВАТЬ НАШЕ ПОИСКОВОЕ СЛОВО*/ if(isset($params['word'])){ $where_array_prepared[]=DB_PREFIX.'_data.text LIKE ?'; /*ЭТО УСЛОВИЕ ИЩЕТ ВХОЖДЕНИЯ ИСКОМОГО КУСКА ТЕКСТА В ЛЮБОМ МЕСТЕ ТЕКСТА В КОТОРОМ ИЩЕМ*/ $where_value_prepared[]='%'.$params['word'].'%'; } /*ЗАКОНЧИЛИ ОБРАБОТКУ*/ return array( 'where'=>$where_array, 'params'=>$params , 'where_prepared'=>$where_array_prepared, /*НОВЫЕ ЭЛЕМЕНТЫ МАССИВА ОТВЕТА КОТОРЫЕ ДОБАВИЛИСЬ*/ 'where_value_prepared'=>$where_value_prepared /*НОВЫЕ ЭЛЕМЕНТЫ МАССИВА ОТВЕТА КОТОРЫЕ ДОБАВИЛИСЬ*/ ); } } Если мы хотим сделать поиск по нескольким полям в объявлении, то часть запроса $where_array_prepared[]=DB_PREFIX.'_data.text LIKE ?'; $where_value_prepared[]='%'.$params['word'].'%'; мы можем заменить на $where_array_prepared[]='( ('.DB_PREFIX.'_data.text LIKE ?) OR ('.DB_PREFIX.'_data.text1 LIKE ?) OR ('.DB_PREFIX.'_data.text2 LIKE ?) )'; $where_value_prepared[]='%'.$params['word'].'%'; $where_value_prepared[]='%'.$params['word'].'%'; $where_value_prepared[]='%'.$params['word'].'%'; В таком случае мы ищем по полям с именами text, tex1 и text2 и удовлетворяемся, если нашли хоть в одном из них. Количество кусочков $where_value_prepared[]='%'.$params['word'].'%'; будет равняться количеству вопросительных знаков в условии выборки.

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

Хотел написать быстро и просто, но тут смешалось немного. Поиск организовать можно. имеете в виду текстовое? верно?

лучше так, как написал я. формально да. код обрабатывающий параметры линк-менеджера должен захватывать и темплейт_сеарч. хотя вероятность не захвата тоже есть))) в общем тут проще попробовать - добавить одну ссылку и обратиться по ней и по запросу с параметрами явно переданными в строке браузера и сравнить результат.

сцылка на сайт может помочь понять суть проблемы.

а теперь выключьте ее и заюзайте Избранное )))

Значит он вроде мог сущестовать в standart_search. Точнее даже должен был существовать. Я же описал случай когда такого готового хтмля нет.

tip_stroy - это не реальное название, а просто условное имя параметра. В вашем случае оно естесвтенно будет своим.

Для Украины - это очень актуальный вопрос.))) В header.tpl скорее всего. В админке он должен вірубаться сам при переходе на гугль, если система не очень старая. Начните с хидера, а там будет видно. В теории могут быть еще подключения от модулей, но это маловероятно.

да. только в последней копипасте `имя_параметра` заменить на `kolvokrovatei` или как там колонка в таблице называется эта.