abushyk

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

Она вполне могла потеряться при переверстывании шаблона. Спишитесь со мной в скайп или личку, я посмотрю.

http://webmap-blog.ru/examples/ymap-api-v2/polyline/ymap_api2_pr6.html

Поле с аналогичным системным именем description поддерживается следующими объектами: - пункты структуры - страны - регионы - города - ссылки из Линк-менеджера иными словами прописав в модели это поле и указав его текстами для нужых вышеперечисленных объектов вы уже получите в шаблоне в переменной {$description} нужные значения, если обратитесь по адресам этих сущностей. Т.е. переход по адресу /krasnoyarsk даст вам описание по городу Красноярску, но поиск с формы по ?city_id=3 (Красноярск) не даст этого описания. Вот только районы городов в данный момент не охвачены этим способом. Вашей же проблемой станет вцбор способа разместить переменную {$description} в футере, так как целевым шаблоном для обращения к указанным адресам является шаблон списка объявлений, куда автоматом выводится эта переменная, а футер немного в другой плоскости.

Нет. Делается так: 1. находится строка в realty_view.tpl {elseif $data_item.type eq "select_by_query"}2. перед ней ставится {elseif $data_item.type eq "price"} {if intval($data_item.value)!=0} <li><label>{$data_item.title} : </label> <span>{$data_item.value|number_format:0:",":" "} </span></li> {/if}

1. Определяемся КАК именно мы будем делит разделы - на каждый раздел свой текст; на каждый корневой раздел, включая подразделы, свой текст. После этого мы сможем определиться по признаку для шаблона. Например в первом случае можно опираться на запрашиваемый адрес, по второму ориентироваться прийдется на какое-то иное значение, которое нужно будет еще получить в контроллере. 2. Дальше делаем все, как вы пытались длелать. Только: а) REQUEST_URI стоит писать большими буквами $smarty.server.REQUEST_URI б) при использовании значения $smarty.server.REQUEST_URI следует учитывать, что в нем присутствуют слеши - начальный обязательно, конечный как в адресной строке браузера. Если у вас нет редиректа с адресов со слешем на без слеши или наоборот, нужно проверять сразу два адреса для одного раздела, либо проверять регулярным выраением учитывающим возможность наличия конечного слеша. 3. И вот оборачивая в такие условия весь футер в файле footer.tpl, или часть его, которая будет изменяться, вы сможете сделать его вариантным. Возможно вам понадобятся какие-то дополнительные действия, так как я не знаю откуда будут браться тексты-описания для разных разделов.

Можно ли сделать - да. Есть ли такое же - нет.

http://www.etown.ru/s/topic/609-параметры-поиска-от-и-до/?p=22099 по этому примеру не удалось разобраться?

Скорее байт. А так как используется утф-8, то это число спокойно можно делить на 2, так как кодировака многобайтная. Все, что сверх этого лимита, отсекается базой данных. Шаблон выводит фактически без ограничений. Лечится все это сменой типа поля body таблицы re_page на MEDIUMTEXT или LONGTEXT. На моей памяти было только два случая, когда стало не хватать длины исходного TEXT.

Тут http://www.etown.ru/s/topic/782-песочница-пользовательские-сущности-и-связан/?p=7035 описано как создать. А выключить - это в Редакторе форм для модели объявления (data) есть кнопочка Выключить у поля metro_id.

/apps/language/language/ru/backend.ini найти строку L_ADMIN_MENU_METRO="Метро"и заменить "Метро". ПС. От этого переименования, в некоторых специфичных операциях, движек не станет считать данные расположенные в этом поле чем-либо, кроме названия станции метро.

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

http://barcelona-comfort.com/add поле Тип операции кодирует ТОЛЬКО тип операции поле Тип должно было кодировать исключительно тип недвиги (как будто в этом селекте выкинуть корневые пункты Продажа, Аренда, а оставшиеся дочерние оставить только разные). Но тут владелец оставил - ему так удобнее было с навигашкой. А вот второй пример http://an-pdm.ru/ тут тип операциии никоим образом не фигурирует в списке типов. и это отображено прямо на форме поиска.

Да. Для этого тип контракта выводится из структуры, в которой остаются только значения типизации недвижимости - квартира, дом, офис, etc А под тип контракта заводится отдельное поле, обычно это select_box с системным именем optype со значениями 1 - Аренда, 2 - Продажа. Это поле поддерживается механизмом поиска. Тут нужно смотреть конкретно каждые "меню и прочие связанные функции". Поле с системным именем optype умеет учитываться в поиске. Т.е. его остается просто добавить на форму поиска. В меню, если речь он навигационном списке под апкой, который строится на основании значений структуры, то оттуда оно пропадет. Что такое "остальные связанные функции" я пока не знаю.

/template/frontend/realia/realty_view.tpl ~~300-я строка <h2>Агент</h2>

Тут http://torpaq.az/template/frontend/realia/css/realia-blue.css будет лучше. В captcha.php совсем нет разметки.

1. fixed. файл /template/frontend/brick/apps/complex/site/template/grid.tpl, строка 231, zoom: 12, число менять на подходяшее. Будет срабатывать только при одной метка на карте. При нескольких будет разворачивать все метки в область видимости. 2. Нет. Никак. Только написав свой код создающий яндекс карту.

Да. Это я недавно сделал и оно еще пока не дошло до конечных пользователей. Это настроечаная строка для описания формата заголовка объекта в карточке. Можно написать, например: {!topic_path} = {country_id}, {region_id}, {city_id}, {optype}, {price} {currency_id} USD / {room_count} и тогда значения взятые в фигурные скобки при выводе будут преврашаьбся в соотв. значения из модели. Например {city_id} трансформируется в значение названия города, {room_count} в значение из поля модели room_count и т.д. Специальная метка {!topic_path} - выведет цепочку вложенных категорий в которой объявления (Жилая/Дома и дачи/Дома), тогда как просто {topic_id} выдаст Дома, т.е. конечную категорию. Если получится что-то вменяемое, то подобное сделается и для выводов в сетку.

Вроде бы туда. Напишите завтра в скайп или аську.

Если вы используете под картинки элемент типа uploadify_image, то, как описали выше, Настройка - Дополнительно - указать размерчики для превьюх и установить галочку\поставить единичку в поле Использовать умную подгонку превьюшек. Если вы используете uploads поле, тогда данные настройки лучше задать в параметрах самого элемента

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

Общий принцип переноса (локализации) шаблонов: из /apps/имя_приложения/site/template/файл_шаблона.tplв /template/frontend/имя_шаблона/apps/имя_приложения/site/template/файл_шаблона.tplЭтот метод должен работать для подавляющего большинства шаблонов.

В той же ссылке, что вы дали, есть и первое указнание - проредить плагины браузеров. А дальше стандартно - AVZ, антивирус, малвареклинер. Тут как раз случай, когда чем больше, тем лучше. ПС. А в самой БД тексты со ссылками, они так же записаны со ссылками, или ссылки рисуются только в просмотре браузером?

настройки - Общее - Тип списка объявлений thumbs