abushyk

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

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

И возвращаясь к шаблону, логику сокрытия цены я что-то упустил. Когда она не должна показываться?

btw Игорь Иванович предложил единственный гарантированно действующий на данный момент вариант. Когда-то раньше было отдельное поле под добавление вложений. Но последний раз в действии я видел его года полтора назад и тогда оно имело кучу ограничений. Поэтому сейчас вот так просто порекомендовать его к использованию я бы не стал.

1. Этажи: /template/frontend/realia/realty_grid_list.tpl блок <div class="area"> <span class="key">{$L_FLOOR}:</span><!-- /.key --> <span class="value">{$grid_items[i].floor}/{$grid_items[i].floor_count}</span><!-- /.value --> </div>заменяем на{if intval($grid_items[i].floor)!=0 && intval($grid_items[i].floor_count)!=0} <div class="area"> <span class="key">{$L_FLOOR}:</span><!-- /.key --> <span class="value">{$grid_items[i].floor}/{$grid_items[i].floor_count}</span><!-- /.value --> </div> {elseif intval($grid_items[i].floor)!=0} <div class="area"> <span class="key">{$L_FLOOR}:</span><!-- /.key --> <span class="value">{$grid_items[i].floor}</span><!-- /.value --> </div> {elseif intval($grid_items[i].floor_count)!=0} <div class="area"> <span class="key">{$L_FLOORS}:</span><!-- /.key --> <span class="value">{$grid_items[i].floor_count}</span><!-- /.value --> </div> {/if}/template/frontend/realia/realty_grid_thumbs.tpl - аналогично 2. Площади блок <div class="area"> <span class="key">{$L_SQUARE} м²:</span><!-- /.key --> <span class="value">{$grid_items[i].square_all}/{$grid_items[i].square_live}/{$grid_items[i].square_kitchen}</span><!-- /.value --> </div>заменяем на{if intval($grid_items[i].square_all)==0 && intval($grid_items[i].square_live)==0 && intval($grid_items[i].square_kitchen)==0} {else} {assign var=x value=array()}{if intval($grid_items[i].square_all)!=0} {append var=x value=$grid_items[i].square_all} {else} {append var=x value='-'} {/if} {if intval($grid_items[i].square_live)!=0} {append var=x value=$grid_items[i].square_live} {else} {append var=x value='-'} {/if} {if intval($grid_items[i].square_kitchen)!=0} {append var=x value=$grid_items[i].square_kitchen} {else} {append var=x value='-'} {/if} <div class="area"> <span class="key">{$L_SQUARE} м²:</span><!-- /.key --> <span class="value">{$x|implode:'/'}</span><!-- /.value --> </div> {/if}/template/frontend/realia/realty_grid_thumbs.tpl - аналогично

Админка - Редактор форм. Выбираем модель к которой нужно добавить поле. Для Объявлений - это data. Жмем там кнопку с плюсиком, открывается форма добавления нового поля для формы.

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

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

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

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

1. Премодерация работает в зоне ЛК. Что бы объявления от админа сразу появлялись на сайте - он должен добавлять их с админки и ставить галочку Опубликовать. Каких-то преференций для админа работающего с ЛК как-то не планировалось. 2. /add ни админ, ни риелтор не должны добавлять. Это чисто гостевая точка. С нового обновления будет внутренний запрет на любую попытку добавить через эту форму любому авторизированному пользователю. На форму есть несколько рецептов, как принудительно уже сейчас завернуть пользователя с этой формы наего ЛК. Аналогично, так как форма гостевая, капча на ней must be. И, кажется, на нее даже не будут влиять права видимости, если для этого поля их проставить в Редакторе форм. 3. "ставлю как 0 так и 1" значит добавляете скорее всего через /add, которая является "подозрительной" и априори не публикует, но и так как это не ЛК, то настройка модерирования на нее так же не распространяется.

По типу сделки (если речь о продаже или аренде) у вас не получится подцепить вкладки, так как они создаются по типу недвижимости. Разве что вы сделаете корневыми разделами вашей структуры Аренда и Продажа, куда уложите уже типы объектов.

Выгрузка есть, так как есть ответ в xml, иначе было бы 404. Просто выгрузка пустая. Первое что мне приходит в голову - у вас нет поля выбора страны в объявлениях, а оно обязательное поле. На первом скрине видно поле Единое название страны. Так как у вас одна страна - впишите туда ее название в виде Беларусь.

На них направлены запросы. Значит они создают вес для остальных страниц. Потеря этих ссылок в 404 не профукает их вес? Лучше что бы они не 404 тогда после удаления отдавали, а 301 наверное.

Я бы в роботс закрыл все адреса типа *?что бы поисковик ничего лишнего не думал. Или ловил бы их, анализировал и делал редирект на куда-то поприличнее. например как эту ссылку http://prorealproperty.com/spain/?optype=2&topic_id=6131 которая уводит на http://prorealproperty.com/spain/sale/1-komn-kvartiri/ А что будет когда начнется отсев неактивных с их удалением? Или вы решили не удалять их совсем?

Я не совсем осознаю проблему, но единственными ссылками, которые зависят от фильтра - это ведь постраничка и сортировка. Но в таком случае будет мало очищать форму, так как очистка формы не приведет к очистке ссылок навигации и сортировок. Т.е. после очистки формы нужно делать принудительный редирект на главную страницу. В любом другом направлении опять подцепятся параметры. Значит очистку формы нужно делать не на форме, а внутри кода, ловить куки, смотреть нет ли метки посещения, если нет, то убивать все параметры поиска и направлять на главную, так как направление на любую другую страницу с параметрами опять подвяжет их в постраничку и сортировку. Поскольку форма писка лишь создает интерфейс тыканья и выбора значений, но не принимает участия в обработке параметров. Но например я нафильтровал для друга пулл подходящих вариантов и даю ему ссылку на него. По вашей же политике мой друг пойдет лесом, так как попытавшись зайти на сайт с готовыми параметрами вы его отправите хз куда очистив их. Если вы их не очистите, то все параметры осядут в постраничку и сортировку и будут влиять на дальнеший его трекинг, даже если вообще удалить форму поиска с сайта. Для таких случаев и делаются посадочные страницы и навссылки на важные разделы. Форма поиска - это самы простой и самый бесполезный инструмент на сайте. Человек любит и хочет тыкать в ссылки, а не выбирать в куче возможных параметров чекбоксы или выпадающие списки. И даже если человек зашел на сайт по километровому запросу с сотней параметров у вас уже должны быть на готове 10-20 ссылок на важные места вашего сайта. Только не найдя этих ссылок "случайный" гость начнет тыкать переход по страницам. Но в вашем случае, я так понинимаю, все упирается в верхний список локаций, при выборе пункта из которого у вас срабатывает запуск поиска с формы? имхо там у вас просто неправильный подход. такие ссылки, да еще расположенные в самом верху зоны юзера, должны быть отправными точками, а не очередным параметром. Если я вижу список городов, то кликнув по нему я естественно ожидаю нефильтрованного результата, а никак не уточнения моего прошлого поиска конкретной локацией. Я бы просто сделал эти локации ссылками вида /?city_id=N и /?district_id=N. Или при сохранении текущей логики занес бы их все-таки в форму для сохранения целостности поиска.

Это именно значения по которым могут ранжироваться объявления или вообще сам механизм установки и накрутки этого ранжирования?

Учтено.

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

По улучшению управления контактами есть уже наработка. Осталось еще прогнать тестирование, так что пока в доступ не даю. Приоткрою завесу: - можно будет указать как глобально, так и для отдельных групп источник данных контактов (профиль, поля из объявления или их смесь). Напр. для группы админы установить подсос данных только из объявления, а для групп Риелтор и Агентство только из профиля на сайте. - можно будет по группам или глобально указать тип владельца выгружаемого объявления, все эти agency\owner без привлечения приложения company, которое вместе с остальным функционалом позволяло влиять на это значение.

if ( !$has_result && preg_match('/^add(\/?)$/', $REQUESTURIPATH) ) {if(0==(int)$_SESSION['user_id']){header('location: '.SITEBILL_MAIN_URL.'/register/');exit();}... тут все что было}Вот это условие я бы еще расширил до if ( !$has_result && preg_match('/^add(\/?)$/', $REQUESTURIPATH) ) {if(0==(int)$_SESSION['user_id']){ header('location: '.SITEBILL_MAIN_URL.'/register/'); exit();}else{ header('location: '.SITEBILL_MAIN_URL.'/account/data/?do=new'); exit();}... тут все что было}Тогда получится логичное - гостя будет отправлять на регистрацию, а авторизированного в ЛК.

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

Не вижу в верхней части возможности выбора города.

В /template/frontend/real-spaces/realty_grid.tpl есть вывод пейджера. Скорее всего в виде <div class="pager">{$pager}</div> Уберите class="pager" оттуда. Это самый минимум, что можно сделать.

Можете просто заменить файл /img/no_foto.png на свое изображение с таким же именем. Это будет простой путь. Либо пройтись по всем шаблонам, где выводятся списки, и сменить вывод там на другое имя.