abushyk

ок.

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

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

По коммерческой. В настройках ассоциаций нужно задавать не только супертип "коммерческая", но и конкретный тип объекта:

Центральным местом, которое в 90% случаев обрабатывает запросы на извлечение нескольких записей-объявлений (всякого рода сетки-списки, в том числе и спецпредложениях в боковых колонках и забор данных для нанесения на карту), является файл /apps/system/lib/frontend/grid/grid_constructor.php - или Конструктор списка (КС). В нем много разного функционала, но самый часто востребованный лежит в двух функциях transformGridData - подготовка данных к выводу и prepareRequestParams - обработка параметров поиска. prepareRequestParams выполняет все операции связанные с тем, что бы превратить фильровочные переменные запроса, переданные в Конструктор списка, в части запроса к БД. Она имеет встроенную обработку некоторого числа параметров, но для расширения функционала иногда необходимо добавить свои. prepareRequestParams НЕ обрабатывает параметры запроса прямо из строки браузера. Все параметры с веб-интерфейса перехватываются отдельной функцией, нормализуются и только тогда передаются в prepareRequestParams. transformGridData адаптирует результат выборки из БД к удобоваримому виду. Поскольку результатом выборки списка являются строки из БД, то именно эта функция трансформирует значения указанные ключем, например поля select_box и select_by_query в текстовые значения. Эта функция так же умеет обрабатывать сама некоторые "стандартные" поля, например географические - country_id, region_id,... street_id, currency_id и все поля типа select_box. "Превращение" в текст остальные ссылочных полей необходимо реализовывать самому Как создать для шаблона локальный Grid_manager 1. Переопределением метода в шаблоне (ручное) - устаревший В файле /template/frontend/имя_вашего_шаблона/main/main.php смотрим, есть ли функция __construct(). Если нет, то создаем ее внутри декларации class frontend_main extends SiteBill_Krascap {} в виде public function __construct(){ parent::__construct(); require SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/main/grid/local_grid_constructor.php'; $this->_setGridConstructor(new Local_Grid_Constructor()); } 2. Переопределением метода в шаблоне (автоматическое) - устаревший В файле /settings.php.ini добавляем секцию описания локального Конструктора списков [GridConstructor] path='/main/grid/local_grid_constructor.php' name='Local_Grid_Constructor' Первая строка - имя секции вторая - путь к файлу локального Конструктора списка от корня шаблона третья - задекларированное имя класса локального Конструктора списка 3. Настроечное переопределение - используйте, по возможности, именно этот вариант локализации Указываем в Настройки - Общее галочку Использовать локальный Конструктор списка (classic_local_grid) Отличие последнего метода от остальных в том, что в нем имя класса конструктора и имя файла в котором он расположен должны быть соответственно Local_Grid_Constructor и template/frontend/имя_шаблона/grid/local_grid_constructor.php и никакими иначе. ============================================================================================= Одним из этих способов мы указываем шаблону, что нужно использовать для построения списков наш измененный Конструктор списков. Но теперь нам необходимо создать его. Для этого нам нужно создать файл по адресу указанному в require_once для первого способа, в path для второго и в /template/frontend/имя_шаблона/grid/local_grid_constructor.php для третьего. Базовое наполнение этого файла будет иметь вид: class Local_Grid_Constructor extends Grid_Constructor { } Уже после этого локальный КС будет работать, но так как он пока пуст, то он просто, как транслятор, будет передавать заказы в стандартный КС. Для того, что бы добавить что-то свое, нам нужно внести в него изменения. 1. Добавляем подхват текстового значения для поля типа select_by_query Поскольку это операция трансформации из ключевого значения в текстовое, то нам понадобится функция transformGridData . Так как остальные параметры нам нужны и мы просто хотим добавить своего, то мы делаем свою функцию с вызовом родительской public function transformGridData($ra, $_collect_user_info=false){ $data=parent::transformGridData($ra, $_collect_user_info);/*используем "стандартный" вызов для выполнения привычных действий*/ /*тут мы можем сделать что-то свое с данными*/ return $data; /*возвращаемся в текущий процесс исполнения*/ } Итак у нас в объявлении есть поле station_id связывающее объект с некоторой станцией из внешней таблицы station в которой станции разложены по строкам вида station_id, name. Так как в данных объявления при выборке мы имеем только ключ станции, а хотим получить именно ее имя и штатный трансформатор за нас этого не делает, то мы проиводим следующее foreach($data as $k=>$d){ if ( $d['station_id'] > 0 ) { $data[$k]['station'] = $data_model->get_string_value_by_id('station', 'station_id', 'name', $d['station_id'], true); }else{ $data[$k]['station']=''; } } Либо $station_ids=array(); foreach($data as $k=>$d){ $station_ids[intval($d['station_id'])]=intval($d['station_id']); } if(!empty($station_ids)){ $DBC=DBC::getInstance(); $query='SELECT `station_id`, `name` FROM '.DB_PREFIX.'_station WHERE station_id IN ('.implode(',', $station_ids).')'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $station_ids[$ar['station_id']]=$ar['name']; } } } foreach($data as $k=>$d){ if(isset($station_ids[intval($d['station_id'])])){ $data[$k]['station']=$station_ids[intval($d['station_id'])]; }else{ $data[$k]['station']=''; } } первый способ короче, но второй на больших количествах записей более продуктивен и более удобен, если нужно получить сложные названия текстового значения, например сцепить с названием станции еще и какой-то другой признак из свойств самой станции. Для select_by_query второй вложенности, например если нужно получить имя застройщика, которое является свойством объекта ЖК, с которым связан объект, первый вариант уже не проходит. Т.е. использовать его конечно можно, но количество дополнительных действий сразу перекрывает сложность второго способа. Поэтому используем сразу второй. $complex_ids=array(); foreach($data as $k=>$d){ $complex_ids[intval($d['complex_id'])]=intval($d['complex_id']); } if(!empty($complex_ids)){ $DBC=DBC::getInstance(); $query='SELECT d.`name`, c.`complex_id` FROM '.DB_PREFIX.'_complex c LEFT JOIN '.DB_PREFIX.'_developer d USING (developer_id) WHERE complex_id IN ('.implode(',', $complex_ids).')'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $complex_ids[$ar['complex_id']]=$ar['name']; } } } foreach($data as $k=>$d){ if(isset($complex_ids[intval($d['complex_id'])])){ $data[$k]['developer']=$complex_ids[intval($d['complex_id'])]; }else{ $data[$k]['developer']=''; } } Очевидно, что принцип схожий и разница заключается только в мелочах вроде запроса на выборку связанного объекта. При чем, в зависимости от сложности желаемого к получению текстового значения будет меняться и сложность запроса, которая запросто может распасться на несколько. В итоге наш локальный КС будет выглядеть таким образом: <?php class Local_Grid_Constructor extends Grid_Constructor { public function transformGridData($ra, $_collect_user_info=false){ $data=parent::transformGridData($ra, $_collect_user_info);/*используем "стандартный" вызов для выполнения привычных действий*/ /*тут мы можем сделать что-то свое с данными*/ $complex_ids=array(); foreach($data as $k=>$d){ $complex_ids[intval($d['complex_id'])]=intval($d['complex_id']); } if(!empty($complex_ids)){ $DBC=DBC::getInstance(); $query='SELECT `complex_id` FROM '.DB_PREFIX.'_complex WHERE complex_id IN ('.implode(',', $station_ids).')'; $query='SELECT d.`name`, c.`complex_id` FROM '.DB_PREFIX.'_complex c LEFT JOIN '.DB_PREFIX.'_developer d USING (developer_id) WHERE complex_id IN ('.implode(',', $complex_ids).')'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $complex_ids[$ar['complex_id']]=$ar['name']; } } } foreach($data as $k=>$d){ if(isset($complex_ids[intval($d['complex_id'])])){ $data[$k]['developer']=$station_ids[intval($d['complex_id'])]; }else{ $data[$k]['developer']=''; } } return $data; /*возвращаемся в текущий процесс исполнения*/ } } 2. Получаем дату в красивом формате Иногда нужно подготовить дату под вывод, что бы не мучаться с однотипными действиями в каждом шаблоне. Например подготовим дату добавления в виде "12 ноябра 2013 года". public function transformGridData($ra, $_collect_user_info=false){ $data=parent::transformGridData($ra, $_collect_user_info); $months=array( '1'=>'января', '2'=>'февраля', '3'=>'марта', '4'=>'апреля', '5'=>'мая', '6'=>'июня', '7'=>'июля', '8'=>'августа', '9'=>'сентября', '10'=>'октября', '11'=>'ноября', '12'=>'декабря', ); foreach($data as $k=>$d){ $month=date('n', $d['date_added']); $data[$k]['pretty_date']=date('j', $d['date_added']).' '.$months[date('n', $d['date_added'])].' '.$months[date('Y', $d['date_added'])]; } return $data; } и в поле pretty_date в шаблоне у нас будет искомая строка 3. День добавления Подготовим дату добавления, что бы она показывала было ли добавлено объявление сегодня, вчера или в другой день. public function transformGridData($ra, $_collect_user_info=false){ $data=parent::transformGridData($ra, $_collect_user_info); $now=date('dmY'); $yesterday=date('dmY', time()-24*3600); foreach($data as $k=>$d){ if($now==date('dmY', strtotime($d['date_added']))){ $data[$k]['pretty_adddate']='сегодня'; }elseif($yesterday==date('dmY', strtotime($d['date_added']))){ $data[$k]['pretty_adddate']='вчера'; }else{ $data[$k]['pretty_adddate']=date('d.m.Y', strtotime($d['date_added'])); } } return $data; } Этот вариант можно скомбинировать с предыдущим. 4. Форматирование адресной строки Форматируем строку адреса для списка вида "Нижний Тагил (Заводской), Лермонтова, 12" [Город (Район), Улица, Дом] protected function transformGridData($ra, $_collect_user_info=false){ $data=parent::transformGridData($ra, $_collect_user_info); foreach($data as $k=>$d){ $addrline=array(); if($d['city']!=''){ if($d['district']!=''){ $addrline[]=$d['city'].' ('.$d['district'].')'; }else{ $addrline[]=$d['city']; } } if($d['street']!=''){ $addrline[]=$d['street']; if($d['number']!=''){ $addrline[]=$d['number']; } } if(!empty($addrline)){ $data[$k]['pretty_address']=implode(', ', $addrline); }else{ $data[$k]['pretty_address']=''; } } return $data; }

https://yandex.ru/support/webmaster/realty/requirements.xml Яндекс сделал поле deal-status (Тип сделки) обязательным. Соттветственно выгрузчик стал его учитывать и заворачивать обяъвы без указанного значения. Пока мы отключили этот момент. Т.е. даже вопреки спецификации ЯН будет пока выгружаться и без такого значения. Со всеми последствиями. Те, кому это поле в какой-то мере критично, могут использовать текстовое поле с системным именем deal_status которое будет содержать один из вариантов, допустимых яндексом. На начало новой недели я сделаю поддержку этого поля в варианте "текстовое поле" и "список выбора", + глобальный вариант для монооперационных сайтов.

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

Все. Отбой. Смотрим поле Запрос для элемента выбора города в модели юзера select re_city.name from re_city order by name человеческим языком здесь значится, что "используй в запросе на выборку списка городов только значения из колонки name сортированные по полю name". Все бы хорошо, но разом с этим из выборки были исключены ключи, которые подставляются в аттрибут value для опций селектбокса списка городов и которые используются для создания связи между юзером и городом. Так что верный запрос должен был выглядеть или как select * from re_city order by name или как select city_id, name from re_city order by name Первый безопаснее, так как хз что может быть понадобится еще кроме названия и ключа в будущем. ПС. Поэтому и города не прописывались на юзера, так как не было идешки и, естественно, не выводились даже по последнему запросу. Проставляйте и наслаждайтесь. Для пробы на АН "Эксклюзив" я выставил.

1. нет любого случая - есть только один вариант city_name, ну или city_id для числа. 2. Город не сохраняется. Вот отсюда и проблема. Я задавал город юзеру, но после сохранения он все равно сброшен в ноль. По самому элементу в модели юзера косяков быть не должно. В редакторе она выглядит "як книжка пише". Проверьте таблицу re_user через пхпмайадмин, что творится с полем city_id. Является ли оно просто INT-типа, без всяких ключей на нем. Существует ли оно вообще. Не жалуется ли эта таблица на поломки и не просит ли починить ее. Начните с этого.

а в каком месте кода выплыла эта ошибка? там после того что вы написали еще должна быть строка где она "возбудилась". можете в приват ответить.

$query='SELECT COUNT( d.id ) AS _cnt, u.group_id, u.city_id, u.user_id, u.fio, u.profilevk, u.profileok, u.profilefb, u.groupvk, u.groupok, u.groupfb, u.phone, u.imgfile, u.mobile, u.email, u.site, u.skype, u.yac1, u.yac2, u.ofadres, u.vibernum, u.fullinfo, g.name AS group_name, ci.name AS city_name FROM `'.DB_PREFIX.'_data` d LEFT JOIN '.DB_PREFIX.'_user u USING ( user_id ) LEFT JOIN '.DB_PREFIX.'_group g USING ( group_id ) LEFT JOIN `'.DB_PREFIX.'_city` ci ON u.city_id=ci.city_id WHERE u.group_id<>4 AND d.user_id=?'; В city_name будет текстовое имя города. Это если в лоб. Но такой запрос конечно уже лучше делить на два более простых. Или его результат сохранять на какой-то срок, что бы он не пересобирал данные каждую секунду.

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

если номер платежа верный, но спотык точно на $stmt тогда все упирается в status и его значение. Так же можно убрать неиспользуемую переменную в запросе $payment в строке $stmt=$DBC->query($query, array($bill_id, $payment)); ----> $stmt=$DBC->query($query, array($bill_id));

проверьте файл header.tpl, что бы там было только одно подключение его. а logn_register.tpl.html Если вдруг в нем оно есть, то отавьте только в header.tpl

все норм. просто у вас 2 раза подключен файл /template/frontend/agency/js/interface.js в котором соержится навеска реации на клик по кнопке сабмита. поэтому при регистрации просиходит двойная регистрация. в ответ на первую вы получаете ответ об успехе, а на вторую сообщение, что такое мыло уже занято, так как оно стало занятым при первой регистрации. нужно просто найти второе подключение и убить.

Напомните адрес сайта.

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

Это встроено. При 5 кривых вводах пары логин-пароль все запросы по данному логину замораживаются на 5 минут и последующие вводы, без проверки, возвращаются как "неправильная пара логин-пароль", что бы отвадить брутфорсеров. В составе БД должна появиться таблица re_user_blocked_logins куда складываются записи о заморозках и срок "освобождения".

Через Линк-менеджер или как будто для боковой колонки?

замените на {if is_array($data.documents.value) && count($data.documents.value) > 0} {foreach name=j from=$data.documents.value item=document_item} <a target="_blank" href="{$estate_folder}/img/mediadocs/{$document_item.normal}">{if $document_item.title != ''}{$document_item.title}{else}{$document_item.normal}{/if}</a><br/> {/foreach} {/if} разница только в первой строке.

Кому-то я уже кажется такое делал. Зайдите ко мне в приват с фтп-доступом.

Галочка скорее всего сработала. Проблема может быть в том, что опция появилась позже чем часть шаблонов и некоторые шаблоны могут не обладать функционалом закрытия по ее включении. Обычно эот достигается следующим. В файле main.tpl шаблона все что в нем есть заворачивается в конструкццию {if $is_underconstruction_mode==1} {include file='main_closed.tpl'} {else} тут то что было в файле изначально {/if} Так же необходимо в папке шаблона разместить файл main_closed.tpl с содержимым <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>{$apps_words.system.SITE_UNDERC_TEXT}</title> </head> <body> <div id="tc"> <div class="tcinner"> <div class="tcinner-info"> {$apps_words.system.SITE_UNDERC_TEXT} </div> </div> </div> </body> </html> ну или иным, которое будет писать посетителю, что мы временно закрыты, но try again later.

а это нужно? не часто такое попадается в жизни.

Для капчи и для полей типа uploadify_image, upoadify_file, tlocation, separator, auto_add_value, select_by_query_multi - "хранить в таблице" должно быть выключено. Одним полям сохранение не нужно в принципе, а другие просто существуют в виде ссылок-фантомов.