abushyk

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

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

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

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

я по метро выше дописал.

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

Для Украины ВК и ЯДиск теперь не совсем удобны для использования)

Внутри кода использование id и таблицы таблиц и колонок практически не используется. С ними работают только приложение table и column. В остальных местах обращения к таблицам-объектам и к колонкам-полям идет только по именам. В контексте выборки списка у нас на руках именно имя таблицы строковое и имя колонки строковое. И что бы не делать при выборке еще и перевод строковых имен в айдишки мы используем сразу их. Согласен, на айдишках было бы надежнее, логичнее и нормальнее. Но смена имени таблицы и колонки - довольно редкая операция. Читабельность таблицы multi-свойств (при отсутствии других способов просмотреть ее) выше. Лишних трансформирующих операций имя->ид не используется.

Я мену просто почему то не отображается картинка.

Вы имеете в виду, что для создания сборного индекса используются значения, которые не являются ключевыми в своих таблицах ('data' вместо соотв. id таблицы)?

Можно считать, что временное. Так как все админ-модули работают по единому принципу с записями через их primary_key, то ключ для каждой записи был добавлен в дополнение к комплексному ключу. Но, поскольку, реальной необходимости и смысла работы с одним конкретным вариантом выбора нет, то он неиспользуемый. Все операции идут только по сборному ключу table_name+field_name+primary_id+field_value

В header.tpl или main.tpl найдите включение библиотеки <script type="text/javascript" src="{$estate_folder}/js/infobox.js"></script> и уберите его. И потом F5. Эта библиотека - дочерняя от библиотеки гугло-карт, а они у вас не подключены в шаблоне, что вызывает падение работы infobox-библиотеки и, вполне возможно, части остальных скриптов, один из которых и создает кнопку добавления фото.

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

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

1970 - начало unix-летоисчисления. Обычно такое означает, что вы пытаетесь форматировать невалидную или отсутствующую дату. В .date_added как я написал - всегда будет или строковая полная дата или ее таймштамп. А в .data которое пытаетесь трансформироваты вы, лежит только число.месяц которые не могут быть трансформированы в число.месяц.год, так как данных о годе в ней нет.

Как вариант можно использовать

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

Еще не плохо бы знать какой шаблон и насколько давно он у вас, так как некоторые переменные, например та же $REQUESTURIPATH может не присутствовать в нем. А 404 ошибка говорит скорее всего о том, что шаблон не поймал искомый адрес, что косвенно указывает на описанное выше.

Попробуйте {if $user_data.group_id.value>0} Группа: {$user_data.group_id.value_string} {/if} возможно это то что нужно.

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

Высота не 600% а 600px Я тыкаю в маркеры - они распадаются. Конечной точки не существует. Суть такая, что кластеры собираются из мркеров по их расположению. Кликая в кластер вы "рассыпаете" его - карта берет маркеры собранные в кластере и выводит их в зону карты с максимальным разрешением. Но еще учитывается, что рядом с рассыпаемым кластером могут быть еще одиночные маркеры и маркеры, которые в других кластерах. Когда показано 100 маркеров, они соберутся в кластеры по одному, но если вывести эти же маркеры не все, а 50 из них, то их сборка в кластеры может произойти по другому. Поэтому при клике на кластер открытие маркеров может произойти не только в более детальном масштабе, чем был показан кластер так как масштаб карты с кластерами обусловлен не только тем что маркеры "дальше" чем кластеры, но и тем, что нужно показать еще и близлежащие кластеры. Но в целом никакого неадеквата на карте я пока не вижу.

1. Админка - Настройки - meta_title_main - прописать тут жестко 2. В main.php шаблона прописать запрос на выборку количества и сформировать значение вставляемое в meta_title_main там где оно вставляется.

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

template\frontend\realia\main.tpl <body> заменить на <body{if $REQUESTURIPATH==''} class="mainpage_class"{/if}> и в стили добавить .mainpage_class { background-image: url(/img/fon.jpg); } и путь к картинке прописать как писалось выше.

Вывести группу владельца объекта на страничку на который выводится объект/квартира (фотка, характеристики, контакты) в блоке где выведены имя владельца, его телефон и почта?