Leaderboard

в начале шаблона 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').

Только этот отчет жалуется: <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 Яндекс.Недвижимость: супертип "Нежилая" упразднен; земельные участки "садовые" и "ИЖС" вообще не должны иметь супертип (официальный ответ Яндекса); земельным прочим земельным участкам (из коммерческих земель) должен быть присвоен супертип "Коммерческая". Я из участков убрал супертип, что Яндекс прекрасно принимает, а вот ваш проверяльщик в обиде

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

наличие селекта, даже с многовыбором, подразумевает одно имя переменно. если у вас есть поле 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 и тогда уже добавить условие. все то же самое, только чуть другим путем. ПС. я возможно не понял вопроса, поэтому ответил на то, что как мне кажется я понял)

Забыл добавить, относительно скорости загрузки сайта не стоит ориентироваться только на Гугл, который читает ваш сайт непонятно какими путями и непонятно откуда. Фактически, скорость загрузки в разной местности может серьезно отличаться, это зависит от местоположения сервера, количества и качества каналов связи и прочих факторов. Можно например воспользоваться этим тестом и посмотреть, в какой стране/регионе и с какой скоростью ваш сайт загружается по факту. На графике будет всё наглядно показано. Например серверы под тариф VIP-1, VIP-2 в reg.ru судя по всему расположены в Голландии, т.к. там мой сайт грузится за 0,8 сек., в России за 1,2 сек., в Англии за 0,9 - 1 сек., в США, в зависимости от штата - 2 - 4,2 сек. и вероятнее всего, ближе к этому и будут тесты Гугла, поскольку их сервера находятся там-же.

На мой взгляд, с этим есть смысл заморачиваться, если ваш сайт грузится дольше 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-адресе, а затем рассуждайте о скорости загрузки сайта, его оптимизации, да и надобности этого вообще в вашей конкретной ситуации ... Хороший сайт начинается с хорошего сервера/хостинга.

Сделали обновление для yandexrealty. Теперь создается отчет о выгрузке, где можно посмотреть что выгрузилось, а что нет и по какой причине. http://адрес_вашего_сайта/cache/yandexrealty.last.log.xml

Вот вам сервис с кучей генераторов - хоть для организации, хоть для статей, хоть для Твиттера и Фейсбука... Генерируйте и пихайте код на сайт