Leaderboard

Логика такая. все, что подается гостем (незарегистрированным пользователем) без всяких настроек ставится в неактив. Тут простая логика целесообразности. если подается с ЛК, то тут возможность активированния можно регулировать. Если доверять авторизированным пользователям, то можно выключить деактивацию до премодерации и вывести чекбокс Публиковать на сайте в доступ всем пользователям, что бы они могли самостоятельно управлять активностью. Если пользователей много и не все они знакомы, то лучше перебдеть и ограничить их управление активностью. Разница между подачей через кнопку и ЛК есть, но она не сильная. Если пользователь авторизирован и нажал на кнопку Подать объявление, то он перенесется в ЛК на функцию подачи объявления из ЛК (в старых версиях шаблонов). В новых лучше предусмотреть в шаблоне спрятывание кнопки Подать объявление для авторизированного. Разделить по группам срабатывание премодерации без колдовства сейчас не получится. А вот отключить подачу неавторизированными можно. Для этого нужно убрать кнопку Подать объявление, а в /template/frontend/agency/main/main.php убрать обработчик подачи объявление, который выглядит как if ( !$has_result && preg_match('/^add(\/?)$/', $REQUESTURIPATH) ) {...}Авторегистрация - это такая опция в Общих настройках (Включить авторегистрацию), которая, при подаче объявления гостем, из данных в объявлении (Ваше ФИО, телефон, мейл) создает аккаунт на который привязывает поданное объявление. И подавший может потом воспользоваться входом в него для корректировки или удаления объявления, а так же для подачи нового. REоффтоп. С футболом сложно. Чем ближе расположен стадион, на котором проходит матч, к дому, тем сложнее на него выбраться. Так что на новую арену-львов, которая расположена в пару остановках от дома, я так до сих пор и не выбрался)))

Итак, мы имеем набор полей: is_wifi Наличие интернета - поле типа checkbox. На форме присутствует в сиде чекбокса. floor_type Тип покрытия пола - select_box с вариантами {0~~не указано}{1~~плитка}{2~~дерево}{3~~ламинат} - отображается в виде выпадающего списка sea_distance Расстояние до моря. Тип safe_string, но отмеченный как is_ranged=1, что бы в форме поиска выводилось в виде двух полей - макс. и мин. значения. Мы добавили эти поля в модель, каким-то образом разместили их на формах поиска. Теперь главная задача - заставить движек обработать их. Для этого существует файл шаблонного поиска, который размещается в /template/frontend/имя_шаблона/main/ и носит имя template_search.php и не иначе. При наличии этого файла движек автоматически обратится к нему и запросит данные для осуществления выборки. В минимальной комплектации этот файл состоит из класса и двух функций: http://pastebin.com/TmBSS9q8 Задача функции getParams забрать данные из запроса и подумать, стоит ли их передавать дальше. А функции run, к которой обращается движек за данными, решить каким образом следует сравнить\обработать полученные параметры для формирования нужной выборки данных. Итак, поехали. 1 Начнем с самого простого - чекбокса is_wifi. Чекбоксы отличаются тем, что в запросе они либо приходят, либо нет. Из запроса берем его функцией $this->getRequestValue('is_wifi'), которая возвращает значение NULL, если такого параметра не существует. if(NULL!==$this->getRequestValue('is_wifi')){ $params['is_wifi'] = 1; } Проверили, не пусто ли, если нет, значит чекбокс отметили и мы записываем его в $params в виде утвердительной единицы. Единицы потому, что в принципе больше нам инфы не нужно, достаточно знать, что параметр запрошен. Дальше floor_type. Этот тип передается в запрос в виде ключа своих значений. Т.е. выбрав "дерево" в запрос у нас приедет "2". Значит мы знаем, что будет целая цифра. if(0!==(int)$this->getRequestValue('floor_type')){ $params['floor_type'] = (int)$this->getRequestValue('floor_type'); } Мы гарантированно делаем из значения параметра целое число с помощью (int) и сравниваем его с 0 - нашим значением никакого значения. Если оно не равно нулю, значит пользователь запросил конкретный тип покрытия и мы сохраняем его значение в $params['floor_type']. Но сохраняем уже конкретным начением, таккак, в отличии от чекбокса, тут нам важно само значение, а не его наличие. sea_distance. При использовании пользовательских форм, которые енерирует движек на основе ваших выборок это поле представится в виде двух полей с именами созданными по принципу sea_distance_min и sea_distance_max. Соотв. и дву переменные прийдут в запросе. Каждую ловим отдельно. Для простоты допустим, что мы готовы обработать целые расстояния до моря: 1, 5, 100. if(0!==(int)$this->getRequestValue('sea_distance_min')){ $params['sea_distance_min'] = (int)$this->getRequestValue('sea_distance_min'); } if(0!==(int)$this->getRequestValue('sea_distance_max')){ $params['sea_distance_max'] = (int)$this->getRequestValue('sea_distance_max'); } Принцип прост. Мы приводим значение к целому. Если пользователь вписал в поле не число, а "аврцуоац" строку, она приведется к нулю. И сравниваем все это с нулем. Искать по нулевому значению смысла нет, поэтому мы сохраняем только те значения, которые от него отличны. Разницы между мин и макс значением в момент их забора из запроса мы не делаем. Она не важна сейчас, но будет важна в следующей функции. 2 Переходим к функции run() Методика ее работы такая 1. взять параметр 2. создать кусочек запроса. Для чекбокса if(isset($params['is_wifi']) && isset($data_model_array['is_wifi'])){$where_array[]=DB_PREFIX.'_data.is_wifi=1';}Расшифровка. Проверяем, есть ли в параметрах запроса переменная is_wifi и есть ли в нашей модели поле с таким именем (так как условие может быть, а поле мы давно погасили за ненадобностью). Если все эти условия выполнены, мы указываем, что хотим дополнить условия нашего запроса сравнением, которое выберет записи, где is_wifi равно1, т.е. при сохранении записи был отмечен чекбокс. Для floor_typeif(isset($params['floor_type']) && isset($data_model_array['floor_type'])){$where_array[]=DB_PREFIX.'_data.floor_type='.$params['floor_type'];}Все аналогично предыдущему за исключением того, что тут мы просим сравнить поле floor_type записи, которое хранит ключ указанного типа покрытия, с переданным в запросе. Для ранжированного sea_distance if(isset($params['sea_distance_min']) && isset($data_model_array['sea_distance'])){$where_array[]=DB_PREFIX.'_data.sea_distance*1>='.$params['sea_distance_min'];}if(isset($params['sea_distance_max']) && isset($data_model_array['sea_distance'])){$where_array[]=DB_PREFIX.'_data.sea_distance*1<='.$params['sea_distance_max'];}И тут почти без изменений. Главное отличие - мы устанавливаем условия в зависимости от того _max или _min параметр мы хотим сравнить. Обратите внимание на DB_PREFIX.'_data.sea_distance*1. В неоптимизированных БД сайтбилля поля под safe_string имеют строковой тип. Поэтому, что бы не было строкового сравнения, где строковое "2" больше строкового "100", мы принудительно делаем значение поля числом перед сравнением. И тогда уже будет натуральное сравнение, где 2<100. и вот примерно вот так http://pastebin.com/8jX7WEEH все єто будет выглядеть в конце.