abushyk

{$apps.complex.view_count}

Ересь какая-то. По коду оно не могло бы значек евро определить как доллар. Даже если бы оно не могло корректно определить, что это евро, оно вернуло бы ошибку, но не USD, если только он не указан дефлолтным. Сможете сделать фтп?

Если я не ошибаюсь, то не меньше года наверное уже.

ёпта))) Не надо в корне попок создавать. Это не настоящие папки, это адрес в виде папок)))) Сносите и будет вам счастье. А то сейчас по адресу export/yandexru сервак видит эти папки и пытается в них найти ответ, а там пусто и получаете 403.

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

ваш_домен вы поменяли на домен вашего сайта? http сменили на https если у вас используется ssl ?

1. Какие имена указаны для валют - то, что значится в списке в элементе выбора валюты в форме объявления? 2. Указано ли что-то в настроках приложения в конфигине "Код валюты по умолчанию, например, RUR/EUR"?

http://ваш_домен/export/yandexru --> $query='SELECT `id` FROM '.DB_PREFIX.'_data WHERE `country_id`=1 AND `active`=1';

Согласен. Скорее всего такое поведение тут избыточно.

Смотрите, адрес find поддерживается последними версиями движка. Для того, что бы ваш поиск уходил на него, нужно в шаблонах форм поиска сделать замену <form method="get" action="{$estate_folder}/"> на <form method="get" action="{$estate_folder}/find/"> Для реалии еще нужно будет проверить, что бы в main.php шаблона не было блока .... } elseif(!$has_result && $REQUESTURIPATH=='find'){ $work_subcontroller='find'; $has_result=true; } else { ..... А если он есть, то завернуть его в комменты .... } /*elseif(!$has_result && $REQUESTURIPATH=='find'){ $work_subcontroller='find'; $has_result=true; } */else { ..... Сам адрес /find обрабатывает уже системный обработчик запросов на списки.

Нужно явно создать в модели data поле под выбор валюты. Я уже писал, что при включении менеджера валют для работы с объекатми data на форме это поле добавляется автоматически, но для работы с data другими приложениями - выгрузчики и тд - такого не происходит, поэтому они считают, что валюту вы не задали.

Disallow: *?* Вот так будет вернее. Так вы запретите все адреса с параметрами оптом, а если что-то понадобится разрешать, то вы сможете конкретно нужные включить.

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

можно попробовать уйти в адрес /find и на нем попробовать генерировать что-то удобоваримое под такие страниц поиска. Хотя там будет такой ад, если подойти обстоятельно, что мало не покажется.

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

...а по дате с ошибкой... ...По дате сортирует... Так сортирует или нет? И что за фильтр справа? Или вы не на агенси шаблоне, а на другом это делаете?

Шаблон "не уиноват"))) Он только рисует (не генерирует), что ему дают. Внутри шаблона наладить такой заголовок скорее всего не удастся, там не будет тривиальная логика.

В вашем случае отправка с форму поиска просиходит по старому варианту на страницу вида /index.php?room=2&price=10000.... или на страницу /find/?room=2&price=10000.... ?

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

Все что прописано в редакторе форм останется на месте. Внутренняя структура не меняется от смены шаблона - только внешний вид. Т.е. селектбоксы все останутся например, но внешний вид могут поменять. сам по себе бустрап не влияет. да, он накладывает некоторые ограничения, так как не все плагины имеют свои копии для всех версий бустрапа. но в целом особой проблемы нет. все что вы сделали по поиску, нужно будет просто портировать в новый шаблон и скорректировать стили и разметку в ту, которая для бут3 приемлема (те же span1-span12 не поддерживаются бутстрапами выше второго, там своя система разметки сетки). только подобрать подходящие файлы шаблонов, так как совпадения по именам и смыслу между ними где-то процентов на 50.

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

Шаблоны сами по себе не 100% идентичные в силу своей структуры. Некоторые блоки в одном шаблоне могут просто не иметь аналогов в другом. Но если в одном шаблоне у вас был вывод например списка пунктов меню из менюхи right_menu, и в другом такой же вывод есть, то вывод сохранится. По объектам обычно различия нет, они поддерживаются любым шаблоном. Разница может быть либо в оформлении выводимых данных, либо в наборе - например в списке в одном шаблоне показана локация+площадь+цена+этаж, а в другом только локация и цена.

Суть в том, что если у вас в модели нет поля, которое бы явно содержало название объекта, которое можно просто воткнуть в шаблоне, но хочется что-то сваять, то функция transformGridData в создателе списков - идеальное для этого место. Она вызывается уже после выборки из БД, но перед отдачей данных в шаблон. И именно там удобнее всего обычно создать какие-то свои переменные.

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

Это наследие тяжелой юности))) realty_data_account.tpl ищите строчку {if $grid_items[i].currency != 'RUR'}({$grid_items[i].price_ue} {$L_RUR_SHORT}){/if} и удаляйте