abushyk

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

{$grid_items[i].date_added|date_format:"%d-%m-%Y"} только вместо $grid_items[i] использовать то имя переменной, которое у вас в этом шаблоне содержит данные объекта.

Комплектов скобочек может быть несколько. Каждый комплект обозначает одну пачку условий которая будет применена на одном шаге. Например вид {A}{B}{C} обозначает, что похожие будут подбираться путем подбора максимум в три шага. На первом шаге применятся условия А. Если указанное в настройках количество похожих подобрано не будет, то запустится добор по условиям во втором шаге B, и аналогично в третьем. И так, пока не кончатся условия или не наберется необходимое количество. Как верно заметили, условия по величинам типа цены\площади не имеют смісла без диапазонных модификаторов. Т.е. смысл имею, но пользы от них мало, так как подбираться будут объекты точно с такой же ценой. Если расшифровать {topic_id}{price} то получится "найди мне еще объектов в том же разделе, что и просматриваемой, а если их не хватит, добери еще объектов с такой же ценой", что скорее всего не то, что хотелось бы.

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

Касательно этого списка полей в настройке. В этом поле вы можете указать системные имена полей из модели ЖК на базе которых приложение сформирует массив элементов формы, которые могут быть размещены в рамках какой-то формы. Эти поля используются приложением для поиска ЖК, не объектов в ЖК. Основная масса полей задается как есть - city_id, metro_id - сформирует список выбора по городам и метро на основании элемента, который есть с таким же именем в модели ЖК. Если такого элемента, как вы зададите в настройке, не будет в модели ЖК, то он проигнорируется. Поля типа room_count_1...room_count_6 подразумевают наличие таких же полей в модели ЖК в виде чекбокса, которые обозначают наличие в ЖК объектов соотв. комнатности. Группа полей типа price_min - price_max и square_min - square_max могут использоваться только если имеют такие же поля в модели ЖК. Они не будут искать по одному полю содержащему какую-то цену для ЖК и не будут искать ЖК у которых есть связанные объекты с ценой входящей в диапазон. Все это справедливо и для площади. Поиск по этим полям производится среди ЖК по данным ЖК. Поэтому наличие объектов в data связанных с ЖК и обладающих значением комнатности, не учитывается при поиске по этим полям. Хитрое имя readydate подразумевает наличие в данных ЖК двух полей с именами built_year и ready_quarter - в первом должен храниться год сдачи в виде ХХХХ, а во втором - квартал сдачи в виде числа от 1 до 4. Тогда код на основании данных в этих полях создаст мифический элемент выбора с вариантами "квартал-год". Весь набор этих элементов потом собирается и генерируется в форму поиска в переменную {$complex_search_form} которую вы можете разместить в одном из своих шаблонов. Повлиять на внешний вид формы можно путем локализации шаблона apps/complex/site/template/complex_search_form.tpl в папку шаблона и обдизайнивания ее на свой вкус. Сам поиск может проходить и без видимой формы. Т.е. если параметры элементов формы прописаны в настройке, то передавая их в строке запроса браузера можно уже влиять на список показываемых ЖК, так как эти параметры начинают учитываться

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

1.Вставить кнопку в шаблон. 2.Написать событие по клику на кнопке, запускающее на сервере процедуру установки статуса 3.Написать код в системе, который перехватит это событие и выполнит присвоение статуса Иного пути, кроме выполнения этих трех пунктов, по сути нет.

зато ID оборачивающего блока разное. Поэтому эти кнопку нужно тыкать не по имени их класса, а через родителя $('#order_form1 .btn-primary'); Тогда скрипт их не смешает в одну.

Если рассматривать "цвет ветки" как исключительно свойство декорирования - то да. Но если рассматривать его как признак группировки станций - а мы ведь по нему можем не только красить иконки, но и давать отдачу поиска "вдоль красной линии" - то все норм - "цвет линии" вполне адекватное свойство именно объекта Станция))

Суть в том, что КАЖДАЯ станция метро будет иметь свой класс. Но вы прописываете тили под эти классы группируя - для классов станций красной ветки - один общий набор стилей, для зеленой - другой. Минус - нужно прописать все э классы для всех станций метро, пусть даже группами и следить за наличием классов в таблицах стилей для новодобавляемых станций. Второй вариант - это который вы забраковали - с признаком. В модель метро обавляется принак Цвет линии. Например для себя вы можете положить, что 1 - это красная, 2 - зеленая и просто в текстовое поле вбивать эти циры для каждой станции. Либо сделать там селектбокс с вариантами {1~~красная}{2~~зеленая} и выбирать варианты. Потом в локальном грид_конструкторе добавить в transformGridData функцию пробежку в цикле по выбранным объектам и сбор ид метро для них, запрос в таблицу метро с этими ид, что бы получить для каждой ид станции соотв. значение цвета ветки в виду числа и заложить эти значения цвета в возвращаемые данные в переменную напр. line_color. Потом при выводе выводить блок иконки станции как <div class="metro_mark metro_mark_{$data.line_color}"></div> {$data.metro} И дальше останется только прописать стили для классов вида .metro_mark_N где N - будут все варианты чисел соотвествующих разными цветам линий.

Это, кстати, оптимальный вариант. Его сложнее реализовать, но в плане логики - лучший. Могу предложить еще вариант для усидчивых. Суть в том, что бы там, где выводится значек станции метро и название метро, выводить не картинку, а блок вида <div class="metro_mark metro_mark_{$data.metro_id}"></div> {$data.metro} В результате мы получим блоки с классами вида metro_mark_1, metro_mark_31, metro_mark_7,.... После этого останется только написать стили виде /*общий стиль для всех иконок*/ .metro_mark { width: 20px; height: 20px; background-image: url(картинка-спрайт с цветными иконками веток) } /*тут пойдут стили для иконки каждой конкретной станции*/ .metro_mark_1 { background-position: 0px 0px; } .metro_mark_1 { background-position: 20px 0px; } .metro_mark_2 { background-position: 0px 0px; } ..... Т.е. признак принадлежности к ветку мы переносим в стили, а у каждой станции получится свой отдельный стиль. И для этих станционных классов мы указываем какую картинку вывести в иконку - для станций с ид=1,5,88 - иконку с красным знаком, 2,3,4,6 - зеленым и т.д.

Мое это)) Там такие же два блока как и у вас, просто расположены один на другом и по клику на кнопке один сворачивается, а второй разворачивается) Но вообще можно попробовать даже на таком http://bootstrap-ru.com/javascript.php#collapse тем более, что оно в реалии включено.

Я что-то уже запутался где они должны выводиться, а где нет)) Вы можете не убирать подключение из бейсик лейаута, а скопировать его в карточку. Просто в бейсик тогда изменить условие. Сейчас там стоит "если карточка, то вывести" а получится наоборот "если не карточка" {if !isset($this_is_realty_view) || $this_is_realty_view!=1} {include file="top_special.tpl"} {/if} такое в бейсик, а в карточку просто include без всяких условий.

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

Это логично, так как он вставлен в layout_basic.tpl который оборачивает макет карточки вокруг и не может что-то вставить в нее. Если вы хотите, что бы этот блок был как бы встроенным в карточку и при этом только там и выводился, то вам нужно переместить его включение из layout_basic.tpl в realty_view.tpl. Тогда он станет уже частью именно карточки и будет стоять в ее span9. Но в этом случае уже не нужно то условие, что мы добавляли, так как блоку будет уже включаться только в самой карточке.

Обычно я делаю это по принципу закладок. У меня есть некий блок формы поиска. Внутри него я делаю несколько подблоков внутри которы размещаю отдельные формы с наьборами элементов. Например в блоке 1 у меня форма с полями под поиск по данных присущим квартирам. В блоке 2 - тоже форма, но с набором полей под поиск дома и т.д. Все эти блоки скрыты. Выбор раздела Квартира\Дом я выношу отдельно выше всех этих блоков и, по выбору одного из них, показываю соотвествующий ей блок с формой, а блоки с формами для других типов скрываю - функционально точно как работают закладки в форме добавления объекта в админке. Минус в том, что так можно адекватно сделать только один уровень - Дом или Квартира или Участок и соотв. форма. Развивать далее потом, например внутри квартир еще варьировать подразделы Апатраметны, Простые квартиры, Элитное жилье со своими формами, таким макаром становится накладно. Элементы можно подключать из существующих моделей. Что бы не вписывать в шаблон жестко разметку какого-нибудь селектбокса с набором варианто и потом следить, если в админке поменялось и не править утрясая в шаблоне, а сразу получать синхронизированный элемент, как сейчас доступны те же city_list со списком городов. Я найду пример такого варианта, что бы не был совсем мозговыносящим.

A. Распаралеливаем. Суть распаралеливания состоит в том, что бы сообщить модулю, что мы хотим выгрузить. В штатном режиме он просто получает пинок по соотв. адресу и на основании настроек (чекбоксы отбора, органичения по времени...) делает выборку и выгружает полученное. С версии 1.5.12 в модуль добавился функционал, позволяющий принудительно сообщить приложению набор идешек, которые следует выгрузить. Делается это следующим образом. В main.php шаблона внутри функции main() мы создаем некий адрес нашей выгрузки - например /export/yandex.common/ if(!$has_result && $REQUESTURIPATH=='export/yandex.common'){ } По обращению на этот адрес мойсайт/export/yandex.common будет происходить нечто в результате чего на выходе будет xml-фид. Далее мы должны собрать коллекцию выгружаемых ID объектов. Каким образом мы это сделаем - не важно (хоть впишем руками, хоть выберем из БД по какому-то запросу). Скорее всего мы будем выбирать их запросами по критерию. if(!$has_result && $REQUESTURIPATH=='export/yandex.common'){ $ids_collection=array(); /*Собираем коллекцию*/ $DBC=DBC::getInstance(); $query='SELECT id FROM '.DB_PREFIX.'_data WHERE country_id=2 AND active=1'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $ids_collection[]=$ar['id']; } } } В данном примере мы определили к выдаче все объекты со страной с ИД=2 и являющиеся активными (active=1) (Это условие добавлено специально, так как если вы управляете набором выгружаемых, то выгрузчик доверяет вам и уже не налагает проверок поверх выбранного вами не по активности, ни по дате, ни по признаку-чекбоксу, как он это делает в штатном режиме. Это требует от вас чуть больше внимательности при сборке коллекции, но зато оставляет большую гибкость в плане возможности подбора). Условия могут быть более произвольными. Запросов может быть несколько или один с использованием UNION. Главное что бы в конце мы наполнили коллекцию $ids_collection набором выгружаемых ID объектов. Формально мы можем хоть в ручную регулировать результат, вплоть до if(!$has_result && $REQUESTURIPATH=='export/yandex.common'){ $ids_collection=array(1,3,54); } Это маргинально, но допустимо. Когда идешки собраны, мы можем сообщать их в приложение. Иными словами мы должны вызвать модуль выгрузки и дать ему список ID. Для этого предназначена функция yandexrealty_admin::setExportedIds() Осталось определить в какую часть модуля передать эти данные. Яндекс-выгрузка имеет два подмодуля admin и site. Они работают почти одинаково. Самый просто вариант определить какой модуль работает в вашем случае: 1. открываем адрес вашей обычной выгрузки 2. по фтп открываем файл /apps/yandexrealty/admin/admin.php 3. находим в нем строку public function export(){ 4. сразу после этой строки добавляем строку echo 1; 5. сохраняем и перегружаем страницу с выгрузкой. 6. сли вместо привычного фида мы получим страницу с ошибкой, значит у нас работает подмодуль admin 7. откатываем пункт 4 если ошибку мы не получили, то работает модуль siteТеперь в нашем перехватчике выгрузки добавим нужные включения if(!$has_result && $REQUESTURIPATH=='export/yandex.common'){ $ids_collection=array(); /*Собираем коллекцию*/ $DBC=DBC::getInstance(); $query='SELECT id FROM '.DB_PREFIX.'_data WHERE country_id=2 AND active=1'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $ids_collection[]=$ar['id']; } } /*ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ SITE-ПОДМОДУЛЬ*/ require_once SITEBILL_DOCUMENT_ROOT.'/apps/yandexrealty/admin/admin.php'; require_once SITEBILL_DOCUMENT_ROOT.'/apps/yandexrealty/site/site.php'; $YRE=new yandexrealty_site(); /*---КОНЕЦ---ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ SITE-ПОДМОДУЛЬ*/ /*ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ ADMIN-ПОДМОДУЛЬ*/ require_once SITEBILL_DOCUMENT_ROOT.'/apps/yandexrealty/admin/admin.php'; $YRE=new yandexrealty_admin(); /*---КОНЕЦ---ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ ADMIN-ПОДМОДУЛЬ*/ /*ПЕРЕДАЕМ ID В ВЫГРУЗЧИК*/ $YRE->setExportedIds($ids_collection); /*ЗАПУСКАЕМ ВЫГРУЗКУ*/ header("Content-Type: text/xml"); echo $YRE->run_export(); exit(); } Получив нужные ID выгрузчик просто прогонит их через валидацию и создаст фид. Кеширование выгрузки следует отключить, если вы создаете такие отдельные точки доступа. Б. Для тех, кто активно перепиливал свои модули в папке apps Вам понадобится стянуть свежую версию приложения и взять из ее файла admin.php недостающие функции setExportedIds($ids) и измененную collectData(). Если ві меняете путем - запомнил свои правки, обновил, добавил опять свои правки, то будет чуть проще - основные изменения были именно в функциисбора данных - collectData, а ее обычно не меняют. В. Для тех, у кого есть локализация приложения в папке шаблона В папке шаблона обычно локализуется site-подмодуль приложения. Поэтому для распараллеливания вам скорее всего придется подключать именно блок /*ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ SITE-ПОДМОДУЛЬ*/ require_once SITEBILL_DOCUMENT_ROOT.'/apps/yandexrealty/admin/admin.php'; require_once SITEBILL_DOCUMENT_ROOT.'/apps/yandexrealty/site/site.php'; require_once SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/apps/yandexrealty/site/local_site.php'; $YRE=new local_yandexrealty_site(); /*---КОНЕЦ---ЕСЛИ МЫ ПОНЯЛИ ЧТО РАБОТАЕТ SITE-ПОДМОДУЛЬ*/ Все отличие, что мы дополнительно подключаем локализированную часть из папки шаблона и работает с локальным local_yandexrealty_site вместо стандартного yandexrealty_site ПС. Я скорее всего не охватил всего, так что кто будет делать эксперименты с этим пишите сюда и в ПП свои вопросы.

А вы не обращали внимания, сами эти картинки, они реально png или у них только расширение стоит png, а внутри, например, обычный jpg?

нет, ниже есть строка {include file="top_special.tpl"} которую нужно заменить условным блоком. Не получится. этот блок выводится только в лейаут_бейсик. В шаблоне карточки он не включается.

У вас есть блок в main() if(!$has_result && $this->isRealtyDetected($REQUESTURIPATH)){ $work_subcontroller='realtyview'; $has_result=true; } добавьте в него признак if(!$has_result && $this->isRealtyDetected($REQUESTURIPATH)){ $work_subcontroller='realtyview'; $has_result=true; $this->template->assert('this_is_realty_view', 1); } и потом в шаблоне layout_basic.tpl вместо просто вывода, сделайте усвлоный {if isset($this_is_realty_view) && $this_is_realty_view==1} {include file="top_special.tpl"} {/if}

Для реалии шаблон карточки - realty_view.tpl. А уже он включает в себя шаблон right_special.tpl - это и есть правый блок. top_special.tpl в реалии - это такая каруселька внизу тоже со спецпредлдожениями. Для того, что бы спец сбоку были только в карточке но не были со списками, нужно просто убрать {include file='right_special.tpl'} включение из файлов realty_grid.tpl и всех layout_....tpl а оставить только в realty_view.tpl

1. убрать вызов $this->template->assert('navmenu', $this->getTemplateMenu()); в main() в файле main.php шаблона 2. В main.tpl шаблона убрать {$navmenu}. Или его + разметку окружающего блока - это <div id="navigation">

Для логики в шаблоне, которую вы пишете осмысленно - т.е. всякий ручной контроль показа чего-то в зависимости от данные объекта, используйте переменную $data_shared вместо $data ( {$data_shared.user_id.value} ). Она содержит полную модель данных объекта, без учета видимостей по группе смотрящего. Никогда не выводите автоматически данные из нее, но для условий ее можно использовать. Т.е. если даже поле xxxx в модели объекта закрыто от доступа для группы смотрящего пользователя, то в data_shared оно будет доступно, в то же время как в $data его не будет.

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

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