abushyk

/template/frontend/realia/realty_grid.tpl
Весь этот файл, если грубо, состоит из разметки
<div class="row"> <div class="span9"> {if $grid_items|count==0} <h1 class="page-header">Ничего не удалось найти</h1> {else} <h1 class="page-header">{$title}</h1> ..... {/if} </div> <div class="sidebar span3"> {include file='search_form.tpl'} <br/> {include file='right_special.tpl'} </div> </div> так вот нужно блок
<div class="sidebar span3"> {include file='search_form.tpl'} <br/> {include file='right_special.tpl'} </div> вырезать и поставить сразу после <div class="row">
 
Это внесет изменения в списки. Но есть еще шаблон /template/frontend/realia/layout_home.tpl который описывает "главную страницу". В нем так же есть несколько блоков
<div class="sidebar span3"> {include file='search_form.tpl'} .... </div> для разных вариантов главной. Их, аналогично, нужно взять, вырезать и переставить перед предшествующим вырезанному элементу блок <div class="span9">.....</div>

Добавил фикс для этого случая.
 
Добавил языковые переменные для формы ввода кода подтверждения восстановления пароля

В принципе относительные ссылки в движке везде. Это сделано как раз для того, что бы абстрагироваться от имени домена, и не менять его везде, как только сайт сменить доменное имя или реплицируется на другой домен. насчет различия относительных и абсолютных вы все правильно поняли. первые пишутся от слеша и браузер направляет переход по ним относительно текущего домена, а абсолютные указывают "точный" адрес страницы.
Использование абсолютных ссылок в некоторых случаях действительно сохраняет работоспособность ссылки. Но не в случае перемещения ее где-то в пределах сайта - в этом случае путь по ссылке рассчитывается относительно домена, а домен, при "перемещения ее где-то в пределах сайта" как можно понять не меняется. Самый реальный пример абсолютных ссылок когда-то использовался для ссылок под логотипами в шапке и подвале сайта, как ссылка на главную. Делалось это для того, что бы при сохранении страницы на пк (когда правой кнопкой мыши и "Сохранить страницу...") хотя бы эти главные ссылки были цельными и юзер, прочитав сохраненную оффлайн копию, мог перейти уже на сайт в интернет на реальный сайт. Делает ли так кто-то еще до сих пор - мне не ведомо. Других случаев, когда нужен абсолютный урл мне не известно.
Влияния использования абсолютного урла против относительного в сео я так же не замечал. По крайней мере, ни один десятка из сеошников, с которыми я занимался анализом последние 2 года, никогда не говорил о какой-то важности этого.
ПС. Есть еще особый вид относительных ссылок. Те, что я описал - ведут отсчет от корня сайта (которые начинаются со слеша). А есть такие, которые ведут отсчет от текущего документа. Вы их видели, у них в составе есть две или одна точка (../img или ../../../settings/). Вот эти да, при перемещении вызываемого файла в другое место, ломают нафиг всю цепочку иерархии. Но таких ссылок на весь движок используется две или три для специфичных системных включений и никогда для ссылок на разделы сайта или какие-то публичные ссылки.

Я тут потыкал у себя на таком шаблоне. Попробуйте в файле header.tpl где стоит запуск этого слайдера, найти блок
$( document ).ready(function( $ ) { $( '#example3' ).sliderPro({ width: 960, height: 500, fade: true, arrows: true, buttons: false, fullScreen: true, shuffle: true, smallSize: 500, mediumSize: 1000, largeSize: 3000, thumbnailArrows: true, autoplay: false }); }); в нем, после autoplay:false поставьте запятую и строку
imageScaleMode: 'contain' Эта настройка указывает не путаться заполнить фоткой все место в слайдере, а наоборот, будет пробовать вписать его полностью в выделенное место.

Что бы оно любые фотки и меньшие этого размера, и больше вписывала точно в этот размер?

Это вы в карточке пытаетесь их растянуть на http://dom.promtex.net.ua ?
 
оффтоп. чисто по человечески, как пользователь, я бы посоветовал не тянуть фотки, а вывести их заведомо меньшими блоками, например как в базовом агенси, без слайдера. Или сделать область слайдера заведомо меньшей, что бы фотки если и тянулись, то минимально. просто когда картинка в 400 пикселей растянута стилем или программно до 800 - это создает жутко гнетущее ощущение, что, когда камера на 2Мп есть почти у каждого школьника, владельцу сайта пофигу на клиентов, которые в 90% случаев хотят посмотреть именно фотки. клиенту нет разницы, что ваши поставщики данных не имеют больших фоток, но когда ему вываливать обезображенную раздутую картинку - он скорее всего свалит. лучше имхо показать "мол да, мы не доработали и фотки адекватной пока нет, но вот посмотрите то, что есть, пусть и небольшое", чем показать огромную, но размазанную картинку, отбив у него всю охоту смотреть дальше.

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

В карточке объекта заголовок фото доступны в элементе title. Например в цикле, где выводятся фотки {section name=j loop=$photo} можно запросить {$photo[j].title} и выведутся заголовки прописанные в админке.
В списках почти аналогично. Внутри цикла, который выводит объекты {section name=i loop=$grid_items} мы вызываем {$grid_items.img[0].title} и получаем описание от первой картинки, которая выводится в список.
В самом общем смысле, везде где у нас есть вывод фоток из стандартных элементов модели, там, у каждой фотки кроме параметров .normal и .preview (содержащих мини-картинку и большую фотку), есть параметр .title который содержит и описание.

В Редакторе форм для модели дата вібрать єлемент карты-координат и прописать ему два параметра - map_width и map_height для которіх указать размер окна карті в пикселях без дописывания после цифр размерности
 

1. Определиться с областью покрытия переводами. Например у вас может быть поле выбора супермаркета с вариантами Tesco, Metro, Auchan... - такие названия может не иметь смысла держать в двух языках. А вот варианты выбора материала дома - кирпич, монолит, .... скорее всего будет иметь.
2. Свести к минимуму текстовые строковые поля. Например, если вы указываете планировку в виде ввода слова "студия", "свободная", ... то такие поля следует превратить в поля выбора, где вариант выпадает в виде селекта выбора. По максимуму свести все поля у которых в целом варианты ограничены - полем выбора одного из вариантов. Возможно даже пожертвовав некоторой свободой при вводе.
3. Избавиться от текста в полях. Например если вы допускали, что площадь участка могла указываться с размерностью "3 сот", "2га", то такие поля лучше свести к одной размерности в га или в сот и хранить только числовое значение.
4. Для оставшихся требующих перевода полей строкового типа завести их зеркала в модели. напр. для поля "планировка" с системным именем "planning" где хранится текстовое название планировки, добавить поле "planning_en" куда будет записываться такое же название на en-языке. Для полей выбора из списка вариантов типа select_by_query такое же добавление нужно сделать в модели, которая работает по их таблице. Напр. у вас выбор ЖК в объявлении. Но сами ЖК складируются в таблице complex и описываются моделью complex. Значит в объекте у вас останется поле выбора ЖК как и было complex_id, но в модели complex вам нужно будет завести поле name_en куда вы будете записывать en-имя ЖК.
5. Для полей типа select_box для иноязычных вариантов у вас появится поле в настройках самого элемента в Редакторе форм - там вы сможете набить варианты выбора аналогично как вы набивали их для одного языка.
6. Перевод интерфейса - самого сайта. Тут нужно будет пройтись по всем файлам шаблона и все тексты на русском языке заменить языковыми метками вида {$LT_MMMMMM} а сами метки вынести в файлы-словари в папке шаблона и там прописать их значения $LT_MMMMMM=текст1
 
В общем работа муторная и кропотливая, но если она нужна, то ее придется сделать. Тут главное четко разобраться с пунктами 1-3, что бы в холостую не переводить лишние значения.

В принципе подобие статуса Продано\Архивировано есть. Это чекбокс с именем archived установка которого переводит объявку в некоторое "полудохлое" состояние, когда она не светится в поиске с формы поиска, но открывается по прямой ссылке. Но эта опция получилась заумной и требующей включения еще пары галочек (привет галочкам "Использовать предудаление" и "Архивированные объявления полностью не доступны") и сильно слилась с понятием "удаления в архив" и вообще процессом удаления. Так что использовать ее пока сложно, тем более, что такие объявки еще и из списка в админке вылетают из общего и для ЛК перевод в это состояние завязан на кнопке удаления. Поэтому использовать ее сейчас по требуемому назначению я бы не рекомендовал. Скорее мы запилим некую лайт-версию такой же галочки с предустановленным поведением.
ПС. Наделать статусов дело не хитрое. Все упирается в а) обилие желаемых статусов (опросить пять форумчан и насобирается с два десятка разных "критически нужных" статусов))) )  б) трактовки смысла одного и того же статуса и его влияния на окружающую среду кода.

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

Для этого в условие по значению panorama нужно обернуть в шаблоне место, в котором написан скрипт. Напр {if $data.panorama.value==1}тут выводим текст скрипта{else}тут ничего не выводим{/if}. Тогда при компиляции шаблон просто не выдаст код скрипта и он не запустится. Но в таком случае возможно нужно будет играться со стилями, так как сам блок (хтмл) куда панка должна была бы вставиться не будет убран. Т.е. либо его тоже вывод обрамить таким же условием, либо применить к нему стили такие, что бы он схлопывался при незаполненности.

Для гугля
1. Блок под панку
<div id="panoview" style="width:100%;height:300px;"></div> 2. Коры для точки панорамы
{if $data.geo.value.lat!='' && $data.geo.value.lng!=''} <script> var pobj_lat={$data.geo.value.lat}; var pobj_lng={$data.geo.value.lng}; </script> {else} <script> var pobj_lat=''; var pobj_lng=''; </script> {/if} 3. Скрипт запуска панорамки
{literal} <script> /*объект-обработчик*/ var PanoRunner={}; PanoRunner.panorama=null; PanoRunner.initialize=function(pobj_lat, pobj_lng) { var panoposition = {lat: pobj_lat, lng: pobj_lng}; var sv = new google.maps.StreetViewService(); PanoRunner.panorama = new google.maps.StreetViewPanorama(document.getElementById('panoview')); sv.getPanorama({location: panoposition, radius: 50}, PanoRunner.processSVData); }; PanoRunner.processSVData=function(data, status){ if(status === google.maps.StreetViewStatus.OK){ PanoRunner.panorama.setPano(data.location.pano); PanoRunner.panorama.setPov({ heading: 270, pitch: 0 }); PanoRunner.panorama.setVisible(true); }else{ /*стирание блока под панорамку, если облом*/ $('#panoview').remove(); } } $(document).ready(function(){ if(pobj_lat!='' && pobj_lng!=''){ /*запуск подключателя панорамы*/ PanoRunner.initialize(pobj_lat, pobj_lng); }else{ /*стирание блока под панорамку, если координат нет*/ $('#panoview').remove(); } }); </script> {/literal}  

Исходный шаблон выводит только некоторый набор полей. Такого товывода, как в карточке, у него нет. Дмитрий просто при заходе на приложение отзывов добавил в шаблон дополнительную переменную с именем review_item_shared которая содержит в себе ВСЕ данные модели отзыва, даже если смотрящему этот отзыв по группе не положено видеть какие-то из этих полей. И вы можете использовать этот масив для вывода в шаблоне нужных вам данных в виде {$review_item_shared.имя_поля.value}

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

поставьте условие если price=0  писать текст договорная

Поле lot_type, тип select_box, ключи вариантов ЧИСЛОВЫЕ!!!!
Не {садоводство~~садоводство}, а {1~~садоводство}

исправил. это было в обновлениях, так как косяк от старой версии. возможно просто не вышли еще обновки или я еще не слил их в общие файлы.

Только этот отчет жалуется:
<log> <date>2017-03-05 10:53:47</date> <items> <item>129 DECLINED: Supertype unknown</item> ... <item>73 DECLINED: Supertype unknown</item> </items> </log> А жалуется он конкретно на отсутствие супертипа "Нежилая" для земельных участков ИЖС и садовых. Согласно действующих требований к выгрузке XML Яндекс.Недвижимость:
супертип "Нежилая" упразднен; земельные участки "садовые" и "ИЖС" вообще не должны иметь супертип (официальный ответ Яндекса); земельным прочим земельным участкам (из коммерческих земель) должен быть присвоен супертип "Коммерческая". Я из участков убрал супертип, что Яндекс прекрасно принимает, а вот ваш проверяльщик в обиде  

в начале шаблона realty_grid.tpl имеется кусок кода с настройками вывода карты:
{literal} $(document).ready(function(){ var RM=new RealtyMap(); RM.initJSON('map', loc_objects, map_type, {scrollZoom: false, minimap: false, yandexMapType: 'yandex#map', fullscreenControl: true}); }); {/literal} yandexMapType: 'yandex#map' замените на нужный вам вариант отображения.
Возможные варианты:
схема ('yandex#map'), спутник ('yandex#satellite'), гибрид ('yandex#hybrid'), народная карта ('yandex#publicMap'), народная карта в гибридном представлении ('yandex#publicMapHybrid').

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

На мой взгляд, с этим есть смысл заморачиваться, если ваш сайт грузится дольше 3-х секунд. Поскольку сервис проверки скорости загрузки сайта от Гугла вам будет жаловаться на любой бздик - лишний пробел в коде, лишний бит в картинке, отсюда он и выставляет рейтинги. Оптимизированные файлы для скачивания, которые предлагает Гугл отличаются лишь тем, что из программного кода убраны лишние пробелы и переносы строк, а картинки понижены в качестве. Но если проанализировать ситуацию, то выигрыш по загрузке получится 0,1 сек. или менее. Не думаю, что это серьезный выигрыш на фоне удобства правки кода, который свален в кучу или демонстрации фото на сайте, которое по качеству становится середнячковым. Тут больше толку будет от размещения сайта на хостинге, который работает на SSD-дисках и имеет более высокое быстродействие. Хотите шустрый сайт - не сажайте его на тарифы хостинга начального уровня, на котором сидит еще сотня таких-же и все на одном IP-адресе , которые делят единый ресурс между собой, тормозя друг-друга, не говоря уже о том, что если один будет взломан/заражен, то проблемы могут появиться и у остальных.
Вот например, у Димы на сервере под одним IP 5.9.72.112 сидит несколько сайтов: kharkovreal.com, kvartira61.ru, magazininfo.com, toss.ru, vashdomru.ru, www.allofficekb.ru, www.sitebill.ru, zdali.ru и еще пару нерабочих кириллических... Но они на шустром сервере и управляются под одной CMS  ... Но когда сайтов на одном IP и на одном дохлом хостинге сотня-две - линкопомойки, мусорные файлообменники и высоконагруженные да еще и на разных CMS, то о какой скорости сайта можно говорить?
Проверьте, сколько у вас соседей ва вашем IP-адресе, а затем рассуждайте о скорости загрузки сайта, его оптимизации, да и надобности этого вообще в вашей конкретной ситуации ... Хороший сайт начинается с хорошего сервера/хостинга.
 

наличие селекта, даже с многовыбором, подразумевает одно имя переменно. если у вас есть поле refrigerator и tvset, то таким селектом напрямую вы их с формы все-равно не отправите. Но вы можете отправить что-то типа
<select name="home_opts[]" multiple="multiple"> <option vale="refrigertor">Холодильник</option> <option vale="tvset">Телевизор</option> </select> т.е. в запросе у вас будут ходить не привычные refrigerator=1&tvset=1 а нечто более замудренное home_opts[refrigerator]=1&home_opts[tvset]=1
соотвественно там, где реализован перехват переменных из запроса и их обработка, нужно будет скорректировать условия, если ранее вы проверяли наличие refrigerator и его равенство 1 перед тем как добавить условие поиска по полю refrigerator, то теперь нужно перехватить из запроса переменную home_opts, проверить в ней наличие ключа refrigerator и тогда уже добавить условие. все то же самое, только чуть другим путем.
ПС. я возможно не понял вопроса, поэтому ответил на то, что как мне кажется я понял)

сам поправил везде в коде http://api-maps.yandex.ru
на
https://api-maps.yandex.ru