abushyk

Если не ошибаюсь, Редактор шаблонов - правим шаблон main.tpl, в нем этот код:
<div class="bottom-wrapper"> <div class="bottom container"> <div class="bottom-inner row"> <div class="item span4"> <div class="address decoration"></div> <h2><a><editable id="add_title_main" data-file="main.tpl">{$LT_ADD_YOUR_OWN}</editable></a></h2> <p><editable id="add_desc_main" data-file="main.tpl">{$LT_ADD_YOUR_OWN_DESC}</editable></p> <a href="{$estate_folder}/add/" class="btn btn-primary">{$LT_VIEW_DETAILS}</a> </div><!-- /.item --> <div class="item span4"> <div class="gps decoration"></div> <h2><a><editable id="rent_title_main" data-file="main.tpl">{$LT_RENT_FLAT}</editable></a></h2> <p><editable id="rent_desc_main" data-file="main.tpl">{$LT_RENT_FLAT_DESC}</editable></p> <a href="{$estate_folder}/getrent/" class="btn btn-primary">{$LT_VIEW_DETAILS}</a> </div><!-- /.item --> <div class="item span4"> <div class="key decoration"></div> <h2><a><editable id="mort_title_main" data-file="main.tpl">{$LT_MORTGAGES}</editable></a></h2> <p><editable id="mort_desc_main" data-file="main.tpl">{$LT_MORTGAGES_DESC}</editable></p> <a href="{$estate_folder}/ipotekaorder/" class="btn btn-primary">{$LT_VIEW_DETAILS}</a> </div><!-- /.item --> </div><!-- /.bottom-inner --> </div><!-- /.bottom --> </div><!-- /.bottom-wrapper -->  

да да, в /template/frontend/realia/apps/articles/site/template/articles_block.tpl

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

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

Я делал локальный обработчик карточки - https://www.sitebill.ru/s/topic/3635-howto-локальный-обработчик-карточки/
Тянул в него функцию protected function makeUserOperatios($form_data_shared) в которую приходит полная модель данных просматриваемого объекта.
<?php class Local_Kvartira_View extends Kvartira_View { protected function makeUserOperatios($form_data_shared){ } } Внутри нее ставил код создания.
И в header.tpl внутри head-тега размещал вставку результата
{if $ldjson!=''} <script type="application/ld+json">{$ldjson}</script> {/if}  

Где-то на втором часу попыток расписать разметку схемы в шаблоне, что бы и вложенность обеспечить и свои данные согласно макета разместить, я плюнул и реализовал сборку json-кода разметки в локальном модуле карточки и заброску его в шаблон.)))) Разборщики схемы понимают ее не только в виде тегов, но и в виде json-объектов. В разметке осталась только разметка крошек и блок о компании. А весь продукт внутри генератора карточки. Вот сам код сборки объекта (в данном случае в функции makeUserOperatios, там же собираются и всякие og-параметры и прочая дребедень для соцсеток, телеграмма и шары):
$JSONLDL=array(); $JSONLDL['@context']='http://schema.org/'; $JSONLDL['@type']='Product'; $JSONLDL['name']=$form_data_shared['meta_h1']['value']; $JSONLDL['url']=$this->getServerFullUrl().'/'.Sitebill::getClearRequestURI(); $JSONLDL['description']=mb_substr(strip_tags($form_data_shared['text']['value']), 0, 200, 'utf-8'); $JSONLDL['image']=$this->getServerFullUrl().'/img/data/'.$form_data_shared['image']['image_array'][0]['normal']; $JSONLDL['offers']=array(); $JSONLDL['offers']['@type']='Offer'; if($form_data_shared['optype']['value']==2){ $JSONLDL['offers']['businessFunction']='Sell'; }elseif($form_data_shared['optype']['value']==1){ $JSONLDL['offers']['businessFunction']='LeaseOut'; } $JSONLDL['offers']['price']=$form_data_shared['price']['value']; $JSONLDL['offers']['priceCurrency']=$form_data_shared['currency_id']['value_string']; $JSONLDL['offers']['availableAtOrFrom']['@type']='Place'; $JSONLDL['offers']['availableAtOrFrom']['address']['@type']='PostalAddress'; $JSONLDL['offers']['availableAtOrFrom']['address']['addressCountry']=$form_data_shared['country_id']['value_string']; $JSONLDL['offers']['availableAtOrFrom']['address']['addressRegion']=$form_data_shared['region_id']['value_string']; $JSONLDL['offers']['availableAtOrFrom']['address']['addressLocality']=$form_data_shared['city_id']['value_string']; $this->template->assign('ldjson', json_encode($JSONLDL)); и вот так он внутри head-тега вставляется
{if $ldjson!=''} <script type="application/ld+json">{$ldjson}</script> {/if}  

Примерно вот так бы это выглядело в плане вложенности в разметке.
<div itemscope itemtype="http://schema.org/Product"> <div itemprop="name">Аренда квартир / 1-комн., Россия, Белгородская область, Белгород, Молодежная, 7 000 руб.</div> <div itemscope itemtype="http://schema.org/Offer"> <div itemprop="price" content="7000"> <div itemprop="priceCurrency" content="UAH"> </div> </div>  

Да. Вместе с рассылкой юзер получает и ссылку на отписку в переменной $results[r].decline_url Как она используется можно посмотреть в файле "\apps\mysearch\site\template\realty_grid.tpl"
Точнее именно незарегистрированный ее получит, а зарегистрированный нет. Ему предлагается пойти в ЛК и там выключить.

realty_grid.tpl
Но в зависимости от шаблона у него могут быть подшаблоны с списочным выводом или блочками - realty_grid_list.tpl и realty_grid_thumbs.tpl

Копировать файл в принципе не обязательно. В шаблоне realty_view.tp у вас есть подключение панельки с этими кнопками
{if $smarty.session.user_id!=$user_data.user_id.value && $mailbox_on==1}
    {include file=$apps_mailbox_block title_data=[$data.topic_id.value_string,$data.city_id.value_string,$data.street_id.value_string] to=$user_data.user_id.value message_to_author_title='Написать владельцу'}
{/if}
Красненьким я показа, что в нее добавить, что бы изменить название кнопки.
Аналогично можно изменить и надпись на кнопку Поделиться. Просто добавить там же message_to_friend_title='Мой текст для Поделиться'

тут можно сделать костыликом. в карточке доступна переменная {$realty_breadcrumbs} в которой лежит массив пунктов крошек. Для показанного на скрине {$realty_breadcrumbs[0]} будет содержать ссылку и якорь Аренда. Если ее взять вот так {$realty_breadcrumbs[0]|strip_tags} то получите искомое "Аренда" в виде слова. Т.е. если очень нужно, то можно дернуть так.

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

Если там заведомо будет набор цифр определенной длины, или максимум двух-трех вариантов длин, то можно делать регуляркой в шаблоне. Да в принципе в люом случае можно регуляркой, только нужно определиться для какой длины подобной строки какой шаблон будет.
Например
{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), а остальное выведет как есть

Универсальное типовое решение для шаблона:
{*Создаем пустой массив*} {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}  

Убираем накладку учета прав доступа для админки:
Файл /apps/customentity/site/site.php
строку 15
$query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?'; меняем на
$query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?';  
строки 18-20
$ar=$DBC->fetch($stmt); $ent=self::getEntityList(); $cent=$ent[$ar['entity_name']]; меняем на
$cent=$DBC->fetch($stmt);  
строку 47
$query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?'; меняем на 
$query='SELECT * FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=? LIMIT 1';  
строки 50-52
$ar=$DBC->fetch($stmt); $ent=self::getEntityList(); $cent=$ent[$ar['entity_name']]; меняем на
$cent=$DBC->fetch($stmt);  
Эти же изменения будут проведены в новой версии приложения, так что ни что не затрется.

Ошибки в исполняемых файлах шаблона - мейн, меню - я исправил.

Вы просто взяли поле метро и сменили ему тип с select_by_query на select_by_query_multi ?
Так как поле мультивыбора не должно храниться в таблице - вы скинули галочку Хранить в таблице. Но сама физколонка в таблице re_data осталась. Для "оптимизации" построитель список работает не через модель, а напрямую с таблицей. Он получает данные на список, собирает мультиполя из внешней таблицы и пытается положить соотв. массив метро из мультиполя в поле metro_id в данных объекта. И тут спотыкается, так как в таблице объекта есть поле metro_id строкового типа. И попытка впихнуть в строковую переменную массив заканчивается фаталом.

Касательно этого списка полей в настройке.
В этом поле вы можете указать системные имена полей из модели ЖК на базе которых приложение сформирует массив элементов формы, которые могут быть размещены в рамках какой-то формы. Эти поля используются приложением для поиска ЖК, не объектов в ЖК.
Основная масса полей задается как есть - 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 в папку шаблона и обдизайнивания ее на свой вкус.
Сам поиск может проходить и без видимой формы. Т.е. если параметры элементов формы прописаны в настройке, то передавая их в строке запроса браузера можно уже влиять на список показываемых ЖК, так как эти параметры начинают учитываться

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

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

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

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

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

не делайте так. такое можно сделать в качестве эксперимента или один раз. но делать аткое систематически не стоит. завтра вы переименуете шаблон карточки или сделаете его вариативным от какого-то условия, когда в одном случае будет realty_view.tpl а в другом realty_view_special.tpl и вся эта логика рухнет.
Заголовок не должен формироваться в шаблоне. Он же может использоваться еще и в других модулях - в каких-то выгрузках, в рсс, в экспортах. Загнав его в шаблон вы не дадите ему этого сделать.
Для нормального формирования заголовков я советую исключительно локализацию модуля карточки. При всей моей либеральности в отношении добавления своегу функционала - тут я скорее настаиваю.

а теперь выключьте ее и заюзайте Избранное )))