abushyk
-
Публикации
4036 -
Зарегистрирован
-
Посещение
-
Days Won
269
Все публикации пользователя abushyk
-
Да. Если выбрать "Все заголовки", то текст с номером страницы добавится и в заголовок на странице и в мета-заголовок.
-
а должно быть именно reaty_name или realty_name? У вас как называется поле под название объекта в таблице data?
-
будет зависеть от типа поля в БД под это значение и внутренних соображений движка БД ПС. Возможно там предусмотрена какая-то досортировка на такие случаи, но не уверен, поэтому считайте, что все будет как написано выше. как угодно. сайтбиллю в принципе фиолетово как вы называете поля. для него важны только их тип, системное имя и понимание их смысла, которое делается через разные таблицы ассоциаций, настроек или методом допущения. что вы пишете в поле "Название для человека" - это ваше личное дело и никакой роли на дальнейшую жизнь данных из этого поля это не оказывает.
-
В этом приложении вы можете указать с сортировкой по значению какого поля должны отдаваться записи. Т.е. заводите себе поле сортировки или используете существуещее (при надобности приводите его к адекватному виду для адекватной сортировки) и все. Хоть по имени, хоть добавите числовое поле с "высотой стояния".
-
там так и есть. вам выдается переменная или массив переменных(если это список) и вы ею в шаблоне вертите как хотите.
-
"Пользовательские сущности" на которых Игорь Иванович и делает справочник. Создаете модель, фаршируете ее полями, создаете на ее основе справочник и наполняете как объявки через форму. Или грузите через эксель, кажется Дима для них даже такую штуку реализовывал. Остается только сваять шаблоны вывода. Но автоматических шаблонов точно не будет внедрено, так как показала жизнь они все равно переделываются под логику конкретного справочника и тащить какого-то "универсального" выродка, который реально никому не подходит, не имеет смысла.
-
без обработчика не выйдет, так как некому будет поймать нужный адрес, понять, что это за адрес, собрать данные и выдать их в шаблон. именно это сейчас Пользовательские сущности и делают, не требуя программиста. Либо это делает приложение, либо вы сами вставляете код перехвата адрес и выборок в тот же main.php. А в остальном, то, что показывает Игорь Иванович - это и есть простейший справочник используя штатные вещи из админки.
-
я подправил верстку и правила под мобильный. если будете что-то править, обязательно возьмите свежие файлы с сервера.
-
Добавьте себе поле select_box с именами группирующих сущностей - ЖК\районов\кондоминиумов\ЖЕКов да чего угодно и группируйте и ищите через это свойств. Организация через ОДНО (а не пару) свойство, которое не связано с другими свойствами напрямую - всегда проще в понимании, более удобно и менее связано с окружающей средой. Условия конечно могут быть сколь угодно вычурными, но чем проще вы их сделаете, даже путем некоторого надумывания или излишества, тем надежнее оно будет работать.
-
1.придумать некий параметр запроса, передача которого в запросе будет означать поиск по двум адресам, например my_grouped_address 2.прописать в обработчике списка этот параметр и условия, которые должны выполнится на БД для получения подходящих объектов 3. создать в линк-менеджере нужный линк и прописать ему в параметрах my_grouped_address=1 Само имя линка произвольное - хоть /топик+город+(улица+номердома1)+(улица+номердома2), хоть /abscd18236 так как ни на что не влияет. Вся суть в параметре и его обработке. Вместо "придуманного" параметра можно было бы использовать строку street_id=N&house_number[]=A&house_number[]=B которая кодирует улицу и два номера дома, но параметр house_number не может быть массивом, так что два номер дома вы не передадите. И два разных дома на двух разных улицах тоже не сможете передать. Для упрощения можно завести справочник неких группирующих районов и для объявок указывать их, параллельно обычным районам. И тогда прописать более разумный вариант использования параметра, так как поиск будет по этим допрайонам,, а уже присоединять к нему объект или нет - будет отдельно.
-
Если такой способ выбора улицы устраивает и связь меду выбранным городом и доступными улицами соблюдается - то можно оставить и такой вариант.
-
Да, такой финт допустим. Только кажется див должен быть именно внутри spanN. Т.е. сами спан-дивы формируют у вас блочно-сеточную структуру по своим размерам, а внутри вы вставляете уже декоративный див, который будет только оборачивать все внутри и держать рамку.
-
Это в принципе могло бы быть. А вот все остальное - в рамках "стандартного" приложения вряд ли будет иметь смысл, так как коробочная версия 90% не удовлетворит, а делать ее суперуниверсальной - потерять в простоте логики.
-
Никак не используется. Я ее добавил скорее на всякий случай, что-то подсказывает, что она может понадобиться.
-
Если там заведомо будет набор цифр определенной длины, или максимум двух-трех вариантов длин, то можно делать регуляркой в шаблоне. Да в принципе в люом случае можно регуляркой, только нужно определиться для какой длины подобной строки какой шаблон будет. Например {if $user_data.phone.value != '' && $user_data.phone.value|strlen==11} {$user_data.phone.value|regex_replace:'/(\d)(\d{3,3})(\d{3,3})(\d{2,2})(\d{2,2})$/':'${1} (${2}) ${3}-${4}-${5}'} {else} {$user_data.phone.value} {/if} что из любого 11-значного набора сделает нам форматный вывод ( 75297916129 => 7 (529) 791-61-29), а остальное выведет как есть
- 89 ответов
-
- 1
-
-
- справочники
- данные
- (и ещё %d)
-
Универсальное типовое решение для шаблона: {*Создаем пустой массив*} {assign var=x value=array()} {*Поочередно перебираем нужные элементы и, если по некоему условию они нам подходят для вывода, складываем их в этот массив*} {if $entity_item.PARAM_NAME_1.value_string!=''} {append var=x value=$entity_item.PARAM_NAME_1.value_string} {/if} {if $entity_item.PARAM_NAME_2.value_string!=''} {append var=x value=$entity_item.PARAM_NAME_2.value_string} {/if} {if $entity_item.PARAM_NAME_3.value_string!=''} {append var=x value=$entity_item.PARAM_NAME_3.value_string} {/if} {*Если массив не пуст по итогу, выводим его значения слепленные запятой*} {if $x|count>0} Адрес (или другое название): {$x|implode:', '} {/if}
- 89 ответов
-
- 1
-
-
- справочники
- данные
- (и ещё %d)
-
Исходно автокомплит - независим от других элементов. Но если вам нужно его связать с чем-то другим, то используйте параметры autocomplete_dep_el - c указанием имени элемента на этой же форме, в котором будет лежать "родительское" значение autocomplete_dep_el_key - имя колонки в модели к которой применяется автокомплит и которое соотвествует вариантам обозначающим "родителя". Например у нас есть поля в форме Город (city_id) и Улица (street_id). И еще у нас улицы лежат в своей таблице и для них есть поле city_id, которое обозначает город к которому принадлежит эта улица. Значит для автокомплит-поля street_id на нашей форме мы указываем параметры autocomplete_dep_el=city_id (найди на этой же форме элемент с таким именем и возьми его значение, которое мы передадим далее для поиска по родителю) и параметр autocomplete_dep_el_key=city_id (когда будешь искать подходящие улицы, то в этом поле у найденных должно быть такое же значение, как мы подхватили для предыдущего параметра).
-
Но может быть вариант, что у вас не "главная страница", а просто список объявлений на главной. Тут зависит какое значение указано в настройке шаблона template.realia.homepagetype
-
Ее даже не нужно переносить. Есть адрес САЙТ/client/order/contactus выводящий эту же форму. В принципе и САЙТ/contactus по умолчанию выдает эту же форму. Так что можно просто дать ссылку на одну из этих страниц и вообще стереть ее из футера.
-
Сами тени ни на что не влияют. С почти 100% вероятностью они уберутся без проблем для верстки. А вот рамки явно влияют на ширину раздувая размеры элемента. Если элемент проставлен процентной шириной и имитирует табличный вид, то добавление рамки, там где ее не было, почти без вариантов развалит верстку. Так как тень она как бы позиционируется вокруг элемента, но не затрагивая его ширину (как абсолютное позиционирование), а рамка - имеет реальную физику и сразу добавляет к ширине. Что тени, что рамки применяются исключительно по мнению дизайнера и принципу "я художник, я так вижу".
-
Верните все, как было в блоке $AA=new articles_site(); $params=array('per_page'=>4); $arts=$AA->getArticlesList($params); $this->template->assert('main_page_articles', $arts['articles']); без комментирования вызова. В файле "\apps\articles\admin\admin.php" найдите protected function getArticlesList и смените на public function getArticlesList Я когда-то закрыл эту функцию, потом понял, что был не прав. Но в обновление не успел вернуть.
-
Этот запрос не возвращает сортированный список квартир. Он возвращает список максимальных и минимальных параметров по комнатностям. Любая сортировка в нем не имеет особого практического смысла. Вам нужна сортировка объектов из ЖК или самих ЖК по параметру проданности?
-
Появляются, но не так. Там была опечатка. Исправил. Я прошелся по базе - там кажется три объявления коммерческого типа. Из них отметку "выгружать" имеет только один - отель. Который в таблице ассоциаций отмечен как "дом". Поэтому первых двух нет в выгрузке. А отель есть, но идет как проассоциировано - Жилая-Дом. Не выгражуются только участки ИЖС. Но тут видимо где-то я прописал условие на запрет выгрузки без property-type а участки там в яше остались без него. Тут мне самому нужно разобраться.
-
C районами действительно нет учета. Настройку я добавил, но обработчика не вижу. То ли удалил, то ли хотел сделать по аналогии с направлением, но забыл. Направления завтра проверю, но тут у вас указано источником в настройках поле direction хотя в модели под Шоссе отведено поле direction_id. Вы должны указывать не таблицу в которой у вас лежат шоссе, а именно поле в данных объекта, которое указывает на какое-то шоссе, так как только с данными объекта работает выгрузчик и этим полем создается связь между объектом и каким-то направлением из другой таблицы. По коммерческой. У вас условия для типов коммерческой записаны с учетом значения поля commercial_subtype но такого поля в модели объекта нет. Вы это просто откуда-то скопировали или такое поле было? По структуре у вас можно ассоциировать одним только значением topic_id. напр. Офисы - topic_id=9. Сейчас у вас для офисов стоит topic_id=6|commercial_subtype=9, но 9 - это как раз topic_id, просто вложенный в topic_id=6.
-
А в английской карте гугля она значится вообще латиницей. Но гугль прекрасно справляется с обеими ими, поскольку у него название улицы - это лишь малая часть информации об конкретной локации.
