abushyk

))) Эта простыня навевает ужас, но, для сайтов, которые прошли этап утряски набора данных, такой вывод куда более удобен и разумен. Будут вопросы, спрашивайте.

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

Запросто. Это и есть "умный" вариант. Выглядит это примерно так http://pastebin.com/SSRc7w9P {$data_shared...} используется вместо {$data...} для того, что бы обойти ограничения по видимости для групп.

realty_grid.tpl - это шаблон именно страницы списка. Он может, и часто так бывает, включать в себя код определяющий вывод карты. Это как бы шаблон верхнего уровня, который мы явно видим при вызове. А еще есть некоторые мелкие шаблоны, которые генерируют кусочки разметки не вызываемые напрямую - например какая-то форма или блок всплывающего окошка над маркером на карте. Их не вызывают прямо, а внутри каких-то внутренних методов, которые поставляют данные для того же списка. Вывод большого или малого количества в принципе не особо влияет. Больше влияет именно наличие нужных данных в конкретный момент. Но если учесть, что поисковики данные на картах не особо читают, то такие вызовы можно делать асинхронно по мере потребности. В принципе их можно даже кешировать, так как у них отпадет два параметра (страница, сортировка) и вариативность их значительно снизится.

1. /template/frontend/realia/layout_home.tpl ~~125 строка и /template/frontend/realia/featured_properties.tpl ~~24 строка и /template/frontend/realia/right_special.tpl ~~31 строка <div class="price">{$special_items2[i].price|number_format:0:",":" "} {if $special_items2[i].currency_name != ''}{$special_items2[i].currency_name}{/if}</div>на <div class="price">{if 0!==(int)$special_items2[i].price}{$special_items2[i].price|number_format:0:",":" "}{elseif 0!==(int)$special_items2[i].cost_per_day}{$special_items2[i].cost_per_day|number_format:0:",":" "}{else}Цена по запросу{/if} {if $special_items2[i].currency_name != ''}{$special_items2[i].currency_name}{/if}</div>2. /template/frontend/realia/layout_home.tpl ~~184 строка <div class="price"><h2>{$special_items2[i].price|number_format:0:",":" "} {if $special_items2[i].currency_name != ''}{$special_items2[i].currency_name}{/if}</h2> <a href="{$special_items2[i].href}">{$L_MORE}</a> </div>на <div class="price"><h2>{if 0!==(int)$special_items2[i].price}{$special_items2[i].price|number_format:0:",":" "}{elseif 0!==(int)$special_items2[i].cost_per_day}{$special_items2[i].cost_per_day|number_format:0:",":" "}{else}Цена по запросу{/if} {if $special_items2[i].currency_name != ''}{$special_items2[i].currency_name}{/if}</h2> <a href="{$special_items2[i].href}">{$L_MORE}</a> </div>3. /template/frontend/realia/realty_view.tpl ~~277 строка <div class="price">{$similar_data[x].price.value|number_format:0:",":" "} {if $similar_data[x].currency_id.value_string != ''}{$similar_data[x].currency_id.value_string}{/if}</div>на <div class="price">{if 0!==(int)$similar_data[x].price.value}{$similar_data[x].price.value|number_format:0:",":" "}{elseif 0!==(int)$similar_data[x].cost_per_day.value}{$similar_data[x].cost_per_day.value|number_format:0:",":" "}{else}Цена по запросу{/if} {if $similar_data[x].currency_id.value_string != ''}{$similar_data[x].currency_id.value_string}{/if}</div>Вроде бы все.

Тут еще возникает вопрос, как будут использоваться эти параметры дополнительные. Если они нужны для каки-то манипуляций в всплывающем окошке, тогда логичнее работать с файлом realty_on_map, который генерирует это окошко. Или вам нужны они, что бы что-то в скрипте делать?

В сетке возвращается не совсем хтмл сетки. Там есть массив grid_items который содержит данные в виде массива. Можно в самом шаблоне, прокрутив этот массив, собрать нужные данные и сформировать строку, например в виде js-массива и тут же в шаблоне активировать код, который по этой строке раскидает метки. Но тут будет ограничение, что будут доступны данные для позиций только с этой страницы. Если нужно например собрать набор без учета страницы, то без доп. запроса не обойдется.

/template/frontend/realia/realty_grid_list.tpl исходная строка <div class="price">{$grid_items[i].price|number_format:0:",":" "} {if $grid_items[i].currency_name != ''}{$grid_items[i].currency_name}{/if}</div>меняем на <div class="price">{if 0!==(int)$grid_items[i].price}{$grid_items[i].price|number_format:0:",":" "}{elseif 0!==(int)$grid_items[i].cost_per_day}{$grid_items[i].cost_per_day|number_format:0:",":" "}{else}Цена по запросу{/if} {if $grid_items[i].currency_name != ''}{$grid_items[i].currency_name}{/if}</div>Аналогично и в /template/frontend/realia/realty_grid_thumbs.tpl Начните с этого, а дальше, если будет нужно, надо будет разнести похожий код еще по шаблонам списка на главной, спецпредложениям и Похожие.

Есть два пути открытия полей данных объявления в карточке объекта: 1. Для ленивых. Вы выставляете права видимости для полей в модели (которые учитываются и в форме и в просмотре) и ничего более не делая смиряетесь с тем, что показывает карточка в режиме автомат. 2. Для умных. Вы верстаете шаблон карточки объекта с учетом вывода именно тех параметров объявления, которые вы хотите показать, вне зависимости от того, какие права видимости вы выставили на поля модели для формы. В вашем случае скорее всего будет в основном "для ленивых" (только видимость всех полей будет открыта для всех), но понадобится некоторая правка шаблона карточки, что бы скрыть ненужные поля (контакты и тд.), так как устанавливать права видимости на них нет смысла в данной концепции.

Если пользователи не регистрируются на сайте, то как они могут различаться для сайта на арендодателей и арендаторов?

Определяемся с логикой. В каких случаях мы должны выводить cost_per_day, а в каких price. Например, от чего будет зависеть - от какого-то признака объявления (например типа операции и категории), или от значений этих полей (например если price пуст или нулевой, тогда выводим cost_per_day) ?

Права на группу лучше вернуть - иначе это поле может стать доступным для установки другим пользователям. Используйте для полей, скрытых правами видимости на группы, переменную {$data_shared.date_added.value} вместо {$data.date_added.value}. Во второй содержатся доступные для данной группы поля, а в первой все поля, без учета прав по группам.

Это экспорт поля с картинками типа uploads. Толку с него при выгрузке нет, как и от любого другого поля картинок, поэтому можно исключать эту колонку из перечня выгружаемых. Обратная загрузка по полям обычно производится на основе выгруженного файла. Т.е. выгрузии, по примеру дополнили или справили и загрузили назад. Единственное отличие касается только картинок, они обрабатываются иначе чем остальные поля. Краткое описание как сформатировать поле с картинками есть тут

Все верно. Но можно вывести его в просмотре даже если оно правами для админа - использовать {$data_shared.date_added.value}

Кусочек шаблона, в котором вы настраивали вывод из поля cost_per_day в списке объявлений. Или вы просто завели поле, но ничего не меняли в шаблоне сетки с расчетом на то, что оно само выведется?

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

ORDER BY hot DESC, но не автономно, а там нужно будет учесть порядок остальных сортировок вместе с этой.

Тут все логично Что бы сделать поле обязательным в форме - нужно поставить в его параметрах галочку Обязательно поле. Тогда оно станет обязательным. Индекс u_mobile мне не знаком, но наверное это индекс либо по самому полю мобилки, либо по нему+еще одно поле. В любом случае, егу нужно удалить, как неиспользуемое. Удалить вручную через phpMyAdmin либо другой вебинтерфейс БД. Редактор форм, во избежание "ойчтожеясделакаквернуть" делает очень мало структурных операций связанных с удалением на таблицах. Добавить да, но удалить - значительно реже. Останутся вопросы или не сможете чего-то сделать, постучитесь мне в мессенджер какой-нить.

Не хочу вас сразу расстраивать, но, по прошествии уже наверное четырех лет, у меня сложилось впечатление, что не существует такого правильного варианта. При экспорте в другие форматы, вы столкнетесь с таким географическими извращениями от производителей форматов, что мало не покажется. А для карт вполне достаточно Страна, Город, улица и дом. Это если не брать в учет мегаполисы или не возиться с деревушками-одноименцами на два дома. Оптимальным будет ориентирование на тот формат или способ работы с географией, который будет чаще всего использоваться. Планируете много работать с яшей, лучше сразу под него и подстроиться. Имхо это и есть единственный правильный путь, а все остальное суть "поиск смысла жизни")))

{$L_XXXXXXX} {$LT_XXXXXXX} Это языковые переменные. Первые, которые L_ - это от системы и приложений. Вторые LT_ - это шаблона. В некоторых шаблонах есть свой файл переводов в папках /template/frontend/realia/language/ Там и лежат такие переменные. Открываем файл соотв. языка, находим нужную метку и меняем ее текст.

Да, это плохо. Вам бы их через роботс запретить и почистить через вебмастер. А что это за адреса такие? Для сайтбилля переменные в урле не характерные.

По скрину все норм. А если вместо price использовать safe_string? На сайте - это имеется в виду в карточке или в бронировании?

Да. Сортировка по полю улицы поддерживается встроенная, а по метро нет.

Вы по сути меняете только заголовок в таблице. Что бы в ту колонку рисовалось метро, нужно еще в <span class="user-info">{if $grid_items[i].street_id!=0} <a href="{$estate_folder}/admin/?action=data&street_id={$grid_items[i].street_id}" data-rel="tooltip" title="Показать все объявления для {$grid_items[i].street}"><i class="icon-white icon-filter"></i></a>{/if}{$grid_items[i].street}</span>все буквосочетания street заменить на metro. Но сразу предупреждаю, что сортировка работать по этому полю не будет. и замена 14 на 13 что даст?Одну колонку вы выкидываете. поэтому что бы самая нижняя нормально растягивалась нужно уменьшить ее область растяжки

{$data.zagolovok1.value} value_string только для полей с внешними данными типа селекбоксов. А в остальном Дмитрий правильно написал, лучше использовать поддерживаемое поле.