abushyk

Необходимо получить ключ браузера от гуглкарт и в header.tpl подключение карты <script src="https://maps.googleapis.com/maps/api/js?v=3.exp&libraries=drawing,places,geometry"></script> изменить на <script src="https://maps.googleapis.com/maps/api/js?v=3.exp&libraries=drawing,places,geometry&key=тут_ключ"></script> Ключ получить можно тут https://developers.google.com/maps/documentation/javascript/get-api-key?hl=ru Если вы не используете приложение mapviewer, то из строки подключения можно убрать часть &libraries=drawing,places,geometry

$ret='<room-space><value>'.implode('</value><unit>кв.м</unit></room-space><room ====> $rs.='<room-space><value>'.implode('</value><unit>кв.м</unit></room-space><room ............................. А от мы неведомой переменной $ret сообщаем нашу строку с хмл и потому в вывод она не приходит))

Насколько я понял, вывод контактов у вас в карточке объекта. Значит туда и нужно вставлять, в realty_view.tpl

updated

Не совсем никогда. Только тогда, когда в запросе не будет города. Поэтому на форме поиска срабатывает на ура, а в карточке нет. Значит city_id=-1 не вариант, я не предусмотрел всего.

$data.vip_status_end используйте $data_shared.vip_status_end.value $data_shared потому, что биллинг-поля обычно доступны только админу и в $data их просто не будет. А .value потому, что в карточке мы имеем модель обекта в отличии от сетки, где у нас выборка из БД без модели.

{if $smarty.session.user_id>0 $smarty.session.user_id==$user_data.user_id.value} {/if} или {if $smarty.session.user_id>0 $smarty.session.user_id==$data_shared.user_id.value} {/if} второе более надежно, поскольку в $user_data поле user_id может быть недоступно для текущего пользователя (могут существовать и такие условия), что сведет проверку к невозможности выполниться, а в $data_shared поле user_id будет гарантированно доступно. Условие $smarty.session.user_id>0 так же поможет отсечь неавторизированных и случайное попадание в ситуацию, когда гость неавторизирован и смотрит объявление, у которого не указан владелец из-за чего второе условие может выполниться.

Тут нужно сделать следующее. Для менюшек вставленных вручную 1. нужны файлы языков в зоне шаблона. не скажу, что 100%, но в реалии они уже могут быть. это папка /template/frontend/realia/language. Если ее нет, то просто создайте ее и внутри нее создайте подпапки по вашим рабочим языкам - /template/frontend/realia/language/en /template/frontend/realia/language/ru. 2. В каждой из этих папок должен лежать файл с именем dictionary.ini для хранения языковых меток. 3. внутри этот файл выглядит как-то так: LT_NEWS="News" LT_FOR_USER="For users" LT_USEFUL="Usefull" LT_SPECIAL="Special" метка="текстовое_значение_на_соотв_языке" 4. Берете все ваши пункты меню из примера и проставляете метки LT_MN_HOME="Главная" LT_MN_ABCOMP="О компании" LT_MN_OUTCITYEST="Иногородняя недвижимость" напр для русского. названия меток не принципиальны, но я бы рекомендовал ставить префикс LT_ что бы потом знать где метка описана. таким префиксом я обозначаю метки из папки шаблона в отличии от меток из приложений или системных. 5. Сами текстовые слова в getTemplateMenu текстовые надписи меняем на Multilanguage::_('LT_MN_HOME', '_template'); c указанием подходящих меток. ... array('id'=>0,'title'=>Multilanguage::_('LT_MN_HOME', '_template'),'position'=>'behind'), ... Для менюшек вставленных из заготовленных меню и Контент - Меню Я внес некоторые изменения в файл сборщика меню для реалии http://pastebin.com/XAr8uPvR для функции getTemplateMenu (правки на лету, код сырой. может сразу не завестись. я тут, если кто-то будет пробовать, пишите сюда) От вас требуется задать для пунктов меню соотвествующие языковые поля-клоны. Кеширование убрано из индивидуальных сессий в общий файл-хранилище.

суть проблемы в том, что для авторизированных групп у вас указана видимость полей контактов, при которой гости не видят контакты, а авторизированные ( в том числе и риелторы) видят? Универсальным условием для шаблона может быть такое {if $smarty.session.user_id!=0 && $smarty.session.user_id==$data_shared.user_id.value} <!-- тут выводим то, что должен видеть только владелец-хозяин данного объявления --> {else} <!-- тут выводим то, что должены видеть все, кто не владелец, в том числе и гости --> {/if}

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

При включенном биллинге в админке, в верхней панельке, варианты Активные, Неактивные дополняются сетом вариантов ВИП\ПРЕмиум\Выделено http://www.awesomescreenshot.com/image/1634417/9eb238d7b2596fe78d7a8fe1a068e17f это быстрая фильтровка. У вас такого нет?

в этой строке я не указывал откуда именно брать исходные данные, а написал абстрактно $field. Но нужно указать именно переменную. Если в модели разбивка комнат лежит в поле с системным именем room_space, тогда условие пишем следующим образом: if(isset($data_item['room_space']) && trim($data_item['room_space'])!=''){ $field=trim($data_item['room_space']); $parts=explode('/', $field); if(!empty($parts)){ $ret='<room-space><value>'.implode('</value><unit>кв.м</unit></room-space><room-space><value>', $parts).'</value><unit>кв.м</unit></room-space>'; } }

В реалии этот плагин на селектбоксах отключается так: 1. в /template/frontend/realia/js/realia.js вверху есть вызов InitChosen(); Комментируем эту строку двумя слешами //InitChosen(); этим мы отключим накладку плагина 2. в header.tpl есть строки описывающие функцию, которая накладывает такой же плагин на селекты, которые обновились при выборе зависимых селектов function refresher_global_callback(el){ el.chosen({disable_search_threshold: 10}); } так же комментируем эти три строки или убираем их. лучше закомментировать, если вдруг потом захочется вернуть.

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

если такой параметр есть, то решением может быть разбивка его по разделителю и вывод результата разбивки отдельными блоками. не вдаваясь в детали, примерно вот так: $parts=explode('/', $field); if(!empty($parts)){ $ret='<room-space><value>'.implode('</value><unit>кв.м</unit></room-space><room-space><value>', $parts).'</value><unit>кв.м</unit></room-space>'; }

А почему не Коммерческая - земли коммерческого назначения ? Я на протяжении обсуждения почему-то совсем пропустил наличие такого типа в вариантах выбора для коммерческой. Видимо путаницу вносит два поля выбора ЖИлая\Коммерческая и категории, которые не связаны между собой механический, но влияют друг на друга логически.

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

просто растеряли скрипты обновления элемента на форме в карточке. вернул и включил "красивое" рисование селектов на форме поиска.

Если же стоит задача не выводить улицы вообще, если не выбран город на стандартной связке географических элементов, то тут немного другой принцип. Суть в том, что запрос указываемый в поле запроса в параметрах элемента улицы является первичным. Он используется ТОЛЬКО в том случае, если в запросе не был указан город. Если с формы поиска приходит идешка города, этот запрос игнорируется полностью и используется другой запрос на выборку. В таком случае, что бы занулить улицы при "первой" загрузке формы, когда мы еще не выбрали город, мы может сформировать его в виде select * from re_street where name !='' AND city_id=-1 order by name т.е. запрашиваем заведомо неправильный запрос, который 100% вернет нам ничего. При выборе города на форме, аякс запросит улицы по своему запросу с учетом города и в обновленном рефреше вернет нам список по искомому городу. При выборе города на форме и сабмите формы, идешка города пройдет у нас по запросу и опять будет сформирован запрос на выборку улиц по городу, который вернет нужный список. Но при первом доступе к форме, когда город еще никак не выбран, будет использован этот "кривой" первичный запрос с пустым результатом. Не следует забывать, что если вы используете какую-то форму где нет выбора города, но есть выбор улицы, то в таком случае вы получите облом, так как на ней, из-за отсуствия города, ВСЕГДА будет применяться первичный запров, который, как мы помним, заведомо возращает пустой список улиц.

В общем ограничивающий запрос на улицы может иметь вид select * from re_street where name !='' AND city_id>0 order by name сравнение на "больше нуля" автоматом выкинет все значения с пустым И нулевым значением связки с таблицей городов - т.е. безхозные улицы.

1. tlocation умер, как автономный элемент, из-за ужасающей сложности работы с ним везде, кроме формы. 2. сравнение с NULL не имеет никакого смысла. все поля, кроме геодата, создаются с признаком NOT NULL. Т.е. все они не будут равны NULL. Они будут равны "какой-то строке", "пустой строке", "нулю", "числу", иному дефолтному значению, но никогда не будут равны NULL. Условие "IS NOT NULL" всегда будет промахиваться на пустой строке, так как NULL(отсутствие значения) не эквивалентно пустой строке и уже тем более не равно нулю. Если такое условие присутствует, то нужно либо делать колонку, по которой производится такая прроверка с поддержкой NULL, либо приводить колонку к ожидаемому значению и сравнивать с его пустым эквивалентом. Для поле выбора по списку как улицы, города и прочее оптимальным типом колонки является INT cо значением по-умолчанию 0. Тогда условие "IS NOT NULL" превратится в более адекватное "!=0".

если речь не о краснодар-инвест (а видимо да, так как типы разделов другие), то в ПП с фтп. будем смотреть лог.

Судя по тому, что все участки описаны у них в секции Жилая, скорее всего они ответят, что проперти-тайп так же будет Жилая.

В случае когда в разделах на сайте заведен только один глобальный тип "Коммерческая", без уточняющих подтипов, есть только два выхода: либо не выгружать коммерческую, либо присвоить всей ей один тип из вариантов в третьей колонке.

Да. нормально у него под кириллицу шрифты verdana и arial. Хотелось бы больше, но шрифты имеют колоссальный объем, поэтому число их ограничено.