abushyk

А идею с кешем списка юзеров в сессии ($users=$_SESSION['users'];) сами придумали или где-то стырили?

Описание возможно добавить ТОЛЬКО к уже реально загруженной картинке, которая привязалась к объекту. В моменте первичной загрузки никак. Если вы владелец хостинга, я пойму такой вариант. В любом другом случае, при таком алгоритме, шансы быть выпинаным хостером начинают стремительно приближаться к мерзким 100%. +будут сразу сложности с постраничкой, так как если не наладить разбивку числовых рядов мускулом (гарантированные тормоза), эту разбивку придется делать в php. Но для этого придется сначала выбрать абсолютно ВСЕ записи объектов и потом ими оперировать. Т.е. если у вас и выводится на страницу 10 записей, то что бы определить эти 10-ть нужно будет вычитать все N-надцать и из них уже в оперативке отобрать 10 подходящих.

Если мы начинаем рассматривать каждую сдаваемую площадь как отдельный объект, тогда достаточно просто вести ее как отдельную запись в data где у нее будут свое поле площадь и картинка. +указатель на бизнесцентр. Тем более, что площади будут разные, свойств у "площади" будет минимум. Да и учитывать их будет понятнее.

Все норм, только функцию я бы чуть переписал private function userlist(){ $users=array(); //массив юзеров if(isset($_SESSION['users']) && is_array($_SESSION['users'])){ $users=$_SESSION['users']; } if(count($users)<1){ $DBC=DBC::getInstance(); $query='SELECT COUNT( d.id ) AS _cnt, u.user_id, u.fio, u.phone, u.imgfile FROM `re_data` d LEFT JOIN re_user u USING ( user_id ) WHERE u.group_id IN ( 2, 3 ) GROUP BY d.user_id ORDER BY _cnt DESC'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $users[]=$ar; } } $_SESSION['users']=$users; } $this->template->assert('users', $users); $this->template->assert('main_file_tpl', 'userlist.tpl'); } т.е. не возвращаю из нее ничего, а сразу задаю файл шаблона и там же в шаблон кладу юзеров. Тогда и userlist.tpl должен отработать на ура.

/template/frontend/realia/realty_view.tpl После $('.carousel.property .content li img').on({ ...});добавляем $('.carousel.property .content li a').on({ click: function(e) { e.preventDefault(); }});и ниже, в {section name=j loop=$photo}<li><a rel="prettyPhoto[gallery1]" href="{$estate_folder}/img/data/{$photo[j].normal}"><img src="{$estate_folder}/img/data/{$photo[j].normal}" /></a></li>{/section}удаляем аттрибут rel="prettyPhoto[gallery1]" у <a>.

Нет, если подсказать, то бесплатно) Например, на примере шаблона realia. В main.php необходимо поймать адрес на котором будут выводиться ваши агенты\пользователи. Пусть это будет agents. Ставим в упомянутом файле внутри функции main() условие if ( !$has_result && preg_match('/^agents[\/]?$/', $REQUESTURIPATH) ) {$this->userlist();$has_result=true;}Т.е. поймали урл который начинается с agents и заканчивается ничем либо слешем, внутри запустили функцию userlist и сообщили движку, что ситуацию мы обработали и можно выводить страницу ($has_result=true;). Далее остается написать функцию userlist, которая должна 1. Выбрать из таблицы юзеров нужных для вывода, например всех, кроме админа и еще какие-то условия. 2. Каким-то образом проинициализировать данные для этих пользователей (если модель юзеров содержит ссылочные поля и они нужны при выводе, то с помощью инициализаторов модели Data_Model::init_from_db(), если нужны примитивные данные, то даже просто запросом в БД, который одним махом выхватит все нужные данные). 3. Отправить это все в шаблон вывода $this->template->assert('users', $users);$this->template->assert('main_file_tpl', 'userlist.tpl');4. Заверстать шаблон userlist.tpl который красиво оформит вывод данных из переданных в {$users} После этого движек вставит в место вывода контента файл userlist.tpl и отрисует его.

Вот только не надо из пушек по воробьям))

Если вы хотите создать статичную страницу, то следует учитывать, что как следует из ее названия, контент в ней статичен. Т.е. вы один раз наполняете контент и он не меняется со временем. Другими словами записали список агентов в тело страничи и, даже если в БД агентов станет больше, то это не отразится на вашей статичной странице. Если же вы хотите, что бы данные для списка брались напрямую из БД, т.е. динамично, то вариант со статичными страницами не подходит. В таком случае просто следует зарезервировать роут под эту страницу в файле main.php и под него вызывать функцию, которая создаст нужный вам список+подключит его вывод. Такие решения есть, например тут http://an-pdm.ru/workers , но они, в данный момент, не являются коробочными (их нет в базовой установке шаблонов).

А вот не гарантирую)

что бы на верняка, то Кол-во фото : {if isset($grid_items[i].img) && is_array($grid_items[i].img)}{$grid_items[i].img|count}{else}0{/if}

Районы привязаны к городам. Т.е. меняя в выборе города пункт, вы инициируете смену списка районов на список подчиненных к этому городу. Из реации на вашем сайте следует - либо у вас районы не привязаны к городу (выберите любой район в справочнике на редактирование и посмотрите, что указано у него в поле Город), либо у районов отсутствует признак (city_id) определяющий принадлежность.

Если речь о том, что бы зафиксировать набор связок в виде - значение площади+ее картинка, есть, в какой-то мере, обходной вариант. Суть его состоят в следующем. Специально поле типа uploads позволяет хранить набор картинок. Кроме этого, оно позволяет хранить описание к картинкам. Если в это поле загрузить набор картинок и снабдить их, в качестве описания, значениями площадей, тогда в шаблоне можно реализовать вывод этого элемента в виде {foreach from=$data_shared.element.value item=element}<img src="{$estate_folder}/img/data/{$element.preview}">{$element.title} м2{/foreach}

Вариант решения (не факт, что универсальный). 1. С формы у нас уходит параметр с именем search. Это кнопка поиска. В отличии от других элементов она обычно есть всегда. 2. В файле /template/frontend/agency/realty_grid.tpl ставим меточку перед сеткой в виде якоря <a name="grid"></a>3. Там же ловим переменную запроса и если переменная search есть, значит предполагаем, что это запрос на поиск и нам нужно прокрутить страничку доя якоря {if isset($smarty.get.search)}{literal}<script>$(document).ready(function(){$('html, body').animate({ scrollTop: $('a[name=grid]').offset().top }, 2000);});</script>{/literal}{/if}

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

К сожалению, в данный момент никак. Это особенность этого элемента формы и эти точечки вшиты в него.

Видно нужно менять словосочетание "Ошибка при выполнении SQL:" на что-то более нейтральное и ласковое, типа "Произошло излишнее действие - данная часть обновления была выполнена ранее" )))

Ошибаетесь. Либо верните поле Логин в состояние "обязательно к заполнению", либо уберите регистрацию из вплывающего окна (там жестко прописана проверка Логина). Всплывающая форма выводит только "обязательные" поля из модели для экономии места. Ну и делать логин необязательным - ерх нелогичности. Как потом входить? Аналогично не логично делать доступной выбор группы в форме регистрации. Это поле должно быть доступно ТОЛЬКО админу.

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

Могут быть первый и третий. Первый более автономен как мне думается. Второй может быть, но зависит от совместимости версий PHP. Если есть как взглянуть на варианты кода, то можно подсказать как вставить.

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

2. Дальше еще необходимо будет ослабить проверку в самом экспорте. if(isset($form_data_shared['ceiling_height']) && isset($data_item['ceiling_height']) && (int)$data_item['ceiling_height']!=0){$rs.='<ceiling-height>'.(int)$data_item['ceiling_height'].'</ceiling-height>'."\n";}во второй строке убрать (int). Иначе получится, что условие значение на форме проходит, на выгрузке, в принципе, тоже проходит, но в сам xml вставляется не верным значением. 3. Приложения разрабатывались отдельно поэтому было нереально поймать дубли. Иначе бы их точно не было. тут нужно смотреть по конкретным полям. абстрактно не скажу. 4. ок.

По порядку. Хотел ответить сразу в письме, но оторвали и оно улеглось в черновиках))) Отвечаю тут. 1. Не установилось по do=install потому, что мы добавили обработчик установки позже, чем вышел последний апдейт. Тут никакие права не помогли бы. 2. По поводу rules=type:int,Min=0, Max=100; то их расставили по приниципу максимальной жесткости. Они не являются абсолютом и их можно изменять. Если конкретно по высоте потолков, то яндекс не регламентирует тип значения (т.е. по версии яндекса там может быть даже "семь метров" словами) и мы использовали максимально безопасный - целый. 3. По похожим полям и их дублированию. На данный момент это имеет место быть. Рассчитывать на наличие нужных полей, которые поставятся с яндекс-выгрузкой не приходится, так как не все ее ставят. Заставлять заводить все поля или все нужные поля, тоже не вариант - лдалеко не всем ядекс-циан-афи-совместимый набор полей нужен даже на 10%. И в тоже время их поля не покрывают всей вариантности встреченных мною полей. Так что в данный момент некоторые дубли обрабатываются попарно, например ЯВыгрузка проверяет и room_count и rooms. Некоторые выгрузки работают только со "своими" полями. Это будет решаться. Мы сделали главную ошибку, решив выпустить универсальный быстро настраиваемый модуль с прицелом "на чайника". В результате получили слишком много универсальности. От этого будем уходить. Как минимум к тщательным ассоциациям каждого поля выгрузки относительно полей объявления. Как максимум к индивидуальному модулю, который будет учитывать структуру data на домене, где запускается. 4. Насчет ориентации на АФИ. Личное впечатление. Приемщик объявлений, который выпустил путанную спецификацию "на все случаи жизни", не может cделать публичный валидатор, вряд ли годится на некий эталон-образец. Полей у них много, но заточены они опять таки именно под АФИ. Нет смысла ориентироваться на него. Но необходимый минимум для афи реализован и, если есть какие-то ценные поля, которые стоит добавить, то это учтется. Всегда можно расширить выгрузку афи, реализовав локальный компоновщик, которые обработает и не обрабатываемые в базовом, поля.

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

Все не так просто, как может показаться)) Логин-форма: /apps/system/lib/system/user/login.php функция loginForm() Регистрационная форма: фактически здесь /apps/system/lib/system/user/register_using_model.php но сама форма берется из родительского класса /apps/system/lib/admin/object_manager.php в get_form() Правка в обеих этих афйлах напрямую чревата. Напишите вкратце, что вы хотите поменять и я, возможно, подскажу оптимальное решение.

если я вас правильно понял, то может сработать cледующее #lk_tree a {color: #000; font-weight: bold;} Вставьте это в сам конец /template/frontend/realia/css/realia-green.css