abushyk

{if floatval($data.price.value) != 0} так будет железобетоннее, так как покроет и пустое значение, и нулевое, и даже "около двухсот тысяч руб."

Можно и так. Русская\украинская версии стерпят. А если не юзать языки, то точно прокатит. Но, если вы вдруг добавите англ язык, тогда все равно придется параметризировать словарной меткой.

Разместите заголовок после строки {if is_array($data.documents.value) && count($data.documents.value) > 0} именно она определяет есть ли что для вывода в список доков. так что если она сработает, тогда можно и заголовок выводить.

Открываем файл /template/frontend/realia/user_menu.tpl В нем в строке <li><a href="{$estate_folder}/account/balance/" >{$L_MY_BALANCE} ({$ballance} {$L_RUR_SHORT})</a></li> $L_RUR_SHORT меняем на $LT_SITE_CUR После этого открываем /template/frontend/realia/language/ru/dictionary.ini и в нем добавляем строку LT_SITE_CUR="грн." То же самое повторяем для остальных файлов типа /template/frontend/realia/language/NN/dictionary.ini при их наличии.

У вас в папке шаблона есть папка language ?

в админке или в ЛК? где именно? можете сделать скрин?

{if is_array($data.documents.value) && count($data.documents.value) > 0} {foreach name=j from=$data.documents.value item=document_item} <a target="_blank" href="{$estate_folder}/img/mediadocs/{$document_item.normal}">{if $document_item.title != ''}{$document_item.title}{else}{$document_item.normal}{/if}</a><br/> {/foreach} {/if}

Возможно так задумано, но вы используете переменную $complex для вывода, а судя по дальнейшей разметке я подозреваю, что это карточка объекта и данные объекта находятся в $data и $data_shared. Так же нужно знать точно ли ваше поле с доками в модели объекта имеет системное имя documents а не иное.

Это не перевод в рубли. Там показана сумма в "дефолтной валюте" (той, которая, как заметил Игорь Иванович, отмечена "по-умолчанию" в менеджере валют), по этому числу происходит фильтровка-сортировка результатов. А рубли там выведены как остаточное явление от шаблона агенси, который был прототипом. Никакого другого практичного смысла она не несет. Вы можете убрать этот вывод в шаблоне realty_grid_account.tpl в папке вашего шаблона убрав кусок строки {if $grid_items[i].currency != 'RUR'}({$grid_items[i].price_ue} {$L_RUR_SHORT}){/if}

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

Речь о шаблоне agency и том, что показывает в ЛК?

теоретическая часть. мы подаем заявку. заявка имеет отличительный признак-метку client/order/zayavka. На данный момент это имя модели. приложение ищет нужную модель. получает по ее структуре данные из запроса. по этой модели проверяет обязательные поля. это первый этап. далее, если существует физическая таблица такой модели, то заявка на основании модели сохраняется в нее. если нет, то не сохраняется. на соновании полученных из запроса данных (именно их. так как заявка только подана, то даже если таблица есть, то ид в запросе этой заявки нет. поэтому и не фиксировались первичные ключи заявки в резюме заявки в приложении Клиенты) формируется табличный вид данных заявки - резюме - то, что вы виите в Клиенты, если нажать Подробнее. Но, так как присоединенные элементы (картинки, доки) связываются с объектом после его сохранения, а резюме заявки для Клиенты формируется на основании данных запроса (а не данных заявки из ее таблицы), пусть даже после сохранения заявки, то доков и картинок в резюме нет. форма гостевого добавления, работает почти так же, но, перед формированием письма админу, она "поднимает" заявку из БД, уже с связанными картинками и доками. так же следует помнить, что резюме заявки и сама заявка в своей таблицы не связаны. и то, что формировщик табличного вида модельки для заявки может обрабатывать не все относительно новые поля. для того, что бы в Подробнее в Клиенты отображались все элементы заявки, включая картинки и доки я готовлю обновление.

Не устанавливать параметр min_img_count вообще. Думаю да. Если будет точно можно, то сделаю. Совсем пропустил это сообщение. Верно, есть такой фокус. В новом обновлении будет исправлено.

Верхние контакты в /template/frontend/realia/header_contact_add.tpl там же и надпись CMS SiteBill шаблон селект выбора языка в /template/frontend/realia/main.tpl заключен в блок <div class="language-switcher">...</div><!-- /.language-switcher --> можно его пачкой убрать

ПМ+ссылка на сайт+фтп доступ к папке сайта

Это просто метка показывающая что тут уже идет другая информация чем выше. Она не означает никакой принадлежности к группе. С равным успехом там могло быть написано "марафонец". Исправить так же как и в агенси в /template/frontend/realia/realty_view.tpl изменить написание подзаголовка <h2>Агент</h2>

/apps/client/admin/client_order.php 1. После строки case 'new_done' : { добавить $pk=0; 2. через пару строк ниже строку $customentity->add_data($form_data_entity); заменить на $pk=$customentity->add_data($form_data_entity); 3. еще ниже в блоке foreach($form_data as $k=>$v){ if($v['type']=='hidden'){ $form_data[$k]['type']='safe_string'; } } сделать вида foreach($form_data as $k=>$v){ if($v['type']=='hidden'){ $form_data[$k]['type']='safe_string'; } if($v['type']=='primary_key' && $pk!=0){ $form_data[$k]['value']=$pk; } }

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

Проверьте через phpMyAdmin тип поля type_id в таблице re_client. Оно должно быть VARCHAR(100), но ранее оно изначально было типа INT(11) что нехорошо.

Не совсем так. У формирования карты есть два этапа. Точнее три. 1. сбор данных для карты на сервере - это пинание БД, получение результатов выбори, досборка значений по ключам, формирование отдачи (xml, json, html) - довольно жирная операция, которая в идеале должна быть уникальной для каждого сайта. Штатный сборщк не знает что и где вам понадобится, потому выбирает данные не самым оптимальным способом, зато в максимально широкой комплектации. Но большая часть этих данных может вам не понадобиться вообще. 2. передача полученного клиенту в браузер. если запрос к карте аяксом, то этот этап ярко выражен. если данные "монтируются" в шаблон, то этот процесс сливается с 1-м этапом и включается в "ответ сервера" 3. формирование карты и меток на ней, с кластерами или без, в браузере клиента средствами апи провайдера карты. На этом этапе уже в основном работает ПК вашего клиента. т.е. ваш сервер вполне может отдать 100 миллионов маркеров на карту, но девайсу клиента может просто не хватить оперативки, что бы выдать браузеру мощности на рисование такого числа объектов. Если на первый этап и, косвенно, на второй вы еще можете влиять финансово или технически, то на третий ваша власть никак не распространяется, кроме выдачи в браузер сообщения "ув. клиент, мы хотим показать карту и море объектов на ней, приобрети себе крутую рабочую станцию, что бы ты смог увидеть ее."

Если страница верстается вручную, то и разбивка ее идет вручную. А если уже есть "нечто, что автоматически разбивает какие-то данные на страницы по 20", то это уже совершенно не вручную. Почти уверен, что да. Хотя, вариант поиска по тексту в некотором сформированном вручную статическом файле, я тоже не откидываю полностью. (Это шутка, не пытаться воспроизвести это в домашних условиях)))) ). NB. Вручную имеет смысл формировать только то, что НИКОГДА или ПРАКТИЧЕСКИ НИКОГДА не будет изменяться ни в плане отображения, ни в плане состава. Все остальное вручную не делается.

запросто. берется любой модуль с основной задачей "оперирования каким-то объектами - вывод в список, показ объекта". например застройщики, ЖК (хотя он избыточен), статьи, да даже те же новости. потом тут Дима давал видео как сделать свое приложение. делать особо уже конечно нечего, так как есть готовая заготовка и нужно в основном переподключить другую модель, поменять манифестный файл, переименовать ключевые переменные связывающие приложение с БД, нафасовать своих конфигурационных переменных по аналогии, и подправить под свои нужды фронт-часть. если полноценная фронт-часть в виде приложения не нужна, то заводится просто модель объекта в Редакторе форм и навешивается на него стандартная админка через кнопочку со звездочкой. а вывод на сам сайт уже можно решить в main.php шаблона самым простым перехватом нужных адресов и невычурными запросами сразу в БД за данными.

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

Вам вообще не нужно такое поле как метро? По телефон-интернет. Админка - Редактор форм - блок data, под ним свернут список полей. Выбрать строку с Телефон и открыв форму редактировать изменить на интернет. Но лучше конечно создать отдельное поле Интернет.

"Геокодирование адреса из фида" следует понимать как получение из фида названия региона и города и их размещение в БД? Вот тут я еще мануал по географии расписал http://wiki.sitebill.ru/index.php?title=Приложение_"Yandex.Realty_Parser" раздел "Парсинг географии", возможно тоже будет чем-то полезно.