abushyk

<form method="GET" action="../search.php">можно просто {$estate_folder}/ вместо ../search.php И так, и так обращение идет на сам сайт. Так что промежуточный файл-редирект не нужен. И в <input type="text" id="input-search" name="q" placeholder="Поиск среди объявлений">name сменить с q на phone

А обновления все применены? Эти две настройки добавляются приложением Config. Оно точно должно быть обновлено.

/apps/system/lib/system/form/form_generator.php function get_single_select_box_by_query ( $item_array, $model=null ) находим в ней строку if(isset($parameters['autocomplete']) && $parameters['autocomplete']==1){через пару строк после нее идет return '<div class="geoautocomplete_block"><input type="text" class="geoautocomplete" ...Вот к этому input type="text" добавьте атрибут placeholder="xxxx"

Настройки - Общее - Степень сжатия для PNG: от 0 (нет сжатия) до 9 = поставить 0 - Коэффициент качества для JPEG/JPG (от 0 до 100) = поставить 80 и выше "Плохие" картинки нужно будет перезалить.

Почти любой географический встроенный элемент поддерживает поиск по множеству значений. Например, если у вас города лежат в элементе city_id, то передача в запросе браузера city_id=N провоцирует отбор по городу с ИД=N. Если же спровоцировать запрос вида city_id[]=N1&city_id[]=N2&city_id[]=N3 то отбор произойдет по ИД=N1 + ИД=N2 + ИД=N3. Внутренняя механика выборки есть. Правда тут есть ограничение. Если города являются подчиненными к полю region_id и вы передадите и его в запросе, но при этом передадите набор ид городов, которые привязаны к разным регионам, то в результате получите скорее всего пустой результат, так как фильтрация пойдет по обеим параметрам одновременно. Суть проблемы сводится теперь только к прорисовке вместо стандартного списка выбора городов, блока со списком всех городов с добавленными к ним чекбоксами.

Вы включили в модалку только карту. А там смысл такой, что рисуется на карте. Но кроме карты на странице в шаблоне есть еще форма поиска с выбором девиации нарисованного контура, и доппараметрами. Так вот поиск происходит таким образом: 1. вы рисуете на карте 2. нажимаете искать 3. после этого координаты собираются с карты и превращаются в строку, эта строка заносится в скрытое поле на упомянутой форме и уже эта форма запускается на отправку. Так как формы на модалке нет, то естественно submit-событие срабатывает в холостую. Другими словами вам нужно как минимум подставить в шаблон в модалке пусть даже скрытую форму с идешкой searchform и textarea в ней с name=crds. Экшен формы должен направлять на {$estate_folder}/mapviewer/search/ Можете увидеть эту форму в /apps/mapviewer/site/template/drawregion.tpl

Если вставить только один баннер, то да. Но если завтра будет нужно добавить туда еще два-три баннера, то легче изменить один включенный всюду файл, чем каждый.

Обвновление приложения GeoData свежее применили?

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

Лечение. Открываем /main.tpl В самом начале перед всем, что в нем есть, добавляем {if $is_underconstruction_mode==1}{include file='main_closed.tpl'}{else}а в конце, после всего, что есть {/if}После этого из папки шаблона агенси копируем в папку шаблона реалия файл main_closed.tplкоторый и есть фронтальным файлом в закрытом режиме. И правим скопированный файл по вкусу.

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

Единого шаблона у этой колонки нет. Он повторяющийся, но разбросан по файлам layout_....tpl /template/frontend/estetico/layout_basic.tpl /template/frontend/estetico/layout_grid.tpl /template/frontend/estetico/layout_view.tpl У всех них есть повторяющаяся часть между <aside> </aside>. Просто она не на 100% идентичная. Можно сделать дополнительный шаблончик mysidebar.tpl куда вложить свою рекламу и расставить его по этим файлам внутри этих тегов. Либо выдрать оттуда общею часть и заключить ее в отдельный файл у уже включить вместо повторяющихся строк.

Пишет, что файл не найден. Проверьте физическое наличие файла /apps/excel/lib/phpexcel/PHPExcel/Writer/Excel2007/Rels.php Может при обновлении криво скопировалось и он не зашел целым.

Ничего странного))) getTemplateMenu - это фукция конкретных шаблонов, не самого ядра. В случае шаблона брик ее аналог можно найти в /main/menu/purecssmenu.phpв функции get_menu ()

{$data.text.value} или {$data_shared.text.value} (второй вариант для случаев, если поле с нужным содержимым по каким-то соображениям доступно не всем группам пользователей) - где text - это системное имя поля, в котором вы храните описание (может и отличаться от стандартного text). Но при попытках впихнуть ее в декрипшен нужно: 1) провести проверку что она доступна, так как в самом общем случае на разных страницах может быть разный контекст у этой переменной, а так как вывод дескрипшена идет вне шаблона карточки, то для точного определения, смотрим ли мы сечас карточку или нет, потребуются дополнительные проверки. 2) не забыть очистить ее от мусора - тегов и разметки, который в дескрипшене просто нагонит длину. ПС. Вот если мне не изменяет память, то переменную $data_shared вбрасывает как раз только карточка объекта. Больше я не припомню случаев ее использования. Так что, думаю, можно проверять по наличию этой переменной.

Формально нужно упихать параметры по которым ищется в сессию. Дмитрий это как-то делал на фронте, ставил аналогичные элементы с автокомплитом, может даже простым копированием из realty_grid_wgt.tpl из шаблонов админки, но я, если честно, не особо вникал в конструкцию, так что внятно не смогу объяснить. Это нужно автора тормошить))) Уже сама их накладка на данные сессии, которая сбивает доступ к Избранным пока достаточная причина, что бы не экспериментировать с ними на паблике. Так что я их пока рассматриваю исключительно штучкой для админки без всяких поползновений по внедрению на фронт. Сама идея хорошая и интересная, но слишком похожа на "черный ящик".

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

Первым делом копать в Настройки - Общее - Разрешить поиск по тэгам во фронтенде . Эта настройка должна быть 0.

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

Это поле нужно добавить самостоятельно http://www.etown.ru/s/topic/2235-выбор-валюты-на-сайте/?p=23150 Тогда оно появится в списке в Редакторе форм и его можно будет по єтому списку совать в нужное положение

По умолчанию данные связанных пользователей в сетку не подхватываются. Но можно их заставить подхватится передав специальный параметр _collect_user_info со значением 1. Сделать это можно так. В контроллере шаблона /main/main.php нужно сделать локальную функцию сборщика данных для списка function grid_adv ($params=array()) { $in_params=$params; $in_params['_collect_user_info ']=1; return parent::grid_adv($in_params);}После этого в объектах списка будет присутствовать подмассив _user_info в котором будут лежать значения его phone, login, fio. Получить к ним доступ можно будет {$grid_items[i]._user_info.phone}Что бы расширить список доступных полей, нужно локализовать Grid_Constructor и обусловить изменения в локальной функции его с именем transformGridData()

Скорее всего это будут конструкции вида (re_data.some_phone_field LIKE \'%'.$phone.'%\')или (re_data.some_phone_field=\''.$phone.'\')Но тут все зависит очень сильно от того, что будет подаваться на вход поиска и как хранятся телефоны в том месте, где планируется искать. Если в полях телефоны хранятся в форматированном виде, то сам запрос поиска начнет приобретать монуструозный вид. А если кроме телефона в поле может быть еще, что-то, как например в поле "заметки (zametky, тип - safestring)" где, как я подозреваю, вполне могут содержаться и некие другие слова-данные, то решение по поиску может быть вообще пирровой победой. Какого-то универсального варианта решение скорее всего нет, поскольку поиск по тексту сам по себе является очень интересной задачей даже без учета необходимости оптимизации. А если еще хочется, что бы кроме поиска движек мог выполнять параллельно еще хоть что-то, то каждый случай лучше рассматривать индивидуально. Вплоть до вынесения операций вычленения номеров из содержащих полей в некие индексные поля или таблицы отдельной задачей, а сам поиск организовывать уже по препарированным данным.

насколько возле? внутрь самого поля ввода, или сразу после поля ввода цифр?

исправление уже сделано. скоро будет доступно в обновлении. вам я уже внес правку.

Для яндекс выгрузки достаточно иметь в модели объявления поле с системным именем period, которое будет иметь значением «день» или «day». Другими словами можно завести: либо поле типа safe_string и проинициализовать его одним из этих значений, либо завести поле select_box с набором выбора {~~--}{месяц~~месяц}{день~~день}, только после создания последнего проверить, что бы в БД в таблице re_data создавшаяся колонка period была типа VARCHAR а не INT и так же проставить на записях нужные значения.