abushyk

После такого возникает вопрос, а зачем вам вообще это было нужно?))) Людям это в принципе не нужно. Все то, что вы сделали интересно исключительно поисковым системам и прочим роботам. Т.е. на вопрос "что делать" остается не так уж много ответов: а) перелинковывать тексты и страницы этим ссылками б) размещать их на биржах ссылок в) размещать их на своем сайте для удобства навигации (сомнительное использование, но может иметь место) г) скармливать в ПС.

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

В форме на последнем скрине поставьте галочку Хранить значение в таблице UPD А на втором скрине в заголовке таблицы re_city тыкните шестую кнопку - синюю с тремя полосочками, что бы структура таблицы перепроверилась на соотв. колонкам в БД.

Что бы подцепились мета данные города, а страница города стала посадочной, необходимо выделить эту страницу как посадочную. Для этого в модели city добавляется поле url типа safe_string, которое будет служить вместилищем алиаса-урла для этого города. После этого в форме правки города вы заполянете это алиас чем-то вроде alushta-gorod-itd и, уже при обращении по адресу сайт/alushta-gorod-itd/ вы будете получать и нужную мета-данные и фильтр по городу Алушта. UPD. Отправка одного city_id со значением идешки города означает всего-лишь отправку данных с фильтра поиска. Входящие в пулл параметров отправленных с формы отдельные параметры не рассматриваются по отдельности, поэтому на их основании невозможно выяснить идет ли речь в поиске о городе или о стране например (можно передать city_id=2&topic_id=4 и тут уже никто, кроме отправлявшего не скажет хотел ли он получить страницу города с ид=2 и объявлениями отфильтрованными по topic_id=4 или все же страницу раздела c topic_id=4 зауженную до города с ид=2). Единственным исключением из этого правила является topic_id, который умеет превратить переданный topic_id в числовом виде обратно в алиас пункта структуры, но, думаю через 3-4 версии мы избавим поиск от этого колдунства.

Нет. Жмем отправить всем. Получаем форму без адресата. Пишем сообщение и Отправить. И оно идет все зарегистрированным.

а это что?

Зашлите ссылку на сайт в ПМ. или напишите мне в скайп или аську (данные в профиле), посмотрим, что с картинками.

и даже числовой идентификатор пользователя в БД тоже может быть отнесен к персональной информации. тут точно без сто грамм юриста будет не разобраться))

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

оно самое

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

А поле translit_alias в модели data почему погашено?

насколько мне не изменяет память, то нет. Новый формат должен применяться ко всем новым.

Получается выборкой. По сути это аналог поля street_id из модели объявления. Может не инициализироваться для формы поиска если не стоит галочка Настройки - Общее - Выбор улицы в форме объявления

Напомните ваш сайт или напишите мне в аську или скайп, я посмотрю, что там у вас с установкой параметризации формата алиаса. ПС. Параметризованный алиас применяется в момент сохранения нового объявления. Если вы просто измените в настройках формат, то на старых объявлениях ничего не изменится. Все применится только с новых.

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

1. Как Дмитрий отметил - алиасы статьи и списка статей (простого или внутри категории) должны быть разными. Это специальный шаг для избежания двойственности определения, как мы имеем сейчас на структуре, когда не всегда можно достоверно сказать по форме или структуре урла был ли это запрос к иерархии, к городу, с статической странице, алиасированной ссылке на объект или запрограммированному линку и приходится ворошить сотни записей ради нахождения одного совпадения. 2. Соотв. вытекает из предыдущего. Это все-таки инструмент категоризации статей, а не создания красивых иерархических адресов. 3. Спасибо, что обнаружили. Уже внес правки и со следующей версии будет учитывать настроечные.

Не понял? Со сдвигом - это значит, что для конкретного обявления указывается этажность от другого объявления, следуюего далее? Если да, то проверьте не вставили ли вы в данные для спецпредложений вывод от сетки в виде {$grid_items.floor} так как слайдер прокручивается по переменной {$special_items} или {$special_items2}

Если вы хотите отсеять "случайных" пользователей, а всю работу по сбору данных об объявлении скинуть на менеджера-риелтора, который свяжется с заявляющим владельцем и, уточнив у него данные, внесет позицию в БД уже под свой аккаунт (что в принципе может повысить качество данных и не оставит объявление в подвешенном состоянии - то ли есть владелец, то ли он уже давно забил), тогда лучше скинуть это в заявки. Например вот тут http://an-pdm.ru/client/order/newclient/мы убрали вообще обработку /add а вместо нее разместили ссылку на форму создающую только заявку с первичными данными. При создании заявки администратор говорит менеджеру с кем связаться и уточнить данные и далее все манипуляции по внесению в БД выполняет именно риелтор.

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

Есть два способа добавить объявления с фронта сайта: 1) гостевой - /add - форма доступная для любого пользователя, в том числе и для незарегистрированного. Размещает объявление в БД согласно настроек, привязывается к дефолтному пользователю, обладает доп. полями типа Ваше имя, ваш телефон для фиксации владельца 2) пользовательский - /account/data/?do=new - добавление из ЛК. Форма аналогичная админской с некоторыми поправками на права видимости и доступность отдельных элементов. В некоторых условиях эти два функционала могут видоизменяться, как то: а) первая глушится и добавить могут только авторизированные б) перехватывается ссылка первой формы и, при авторизированном пользователе идет редирект на форму в ЛК в) перехватывается первая ссылка и аналогично предыдущему, но пересылает на форму регистрации Когда-то в базовом движке был даже принудительный перехват адреса первой формы и загрузка для авторизированного пользователя по ее адресу формы из ЛК. Почти как б) только без редиректа. Но не уверен, что этот рудимент сохранился в полной мере во всех шаблонах. Скорее она могла бы, а не должна. Мне встречались случаи, когда ссылку /add глушили а вместо нее пользовались формой заявки, аналогичной Связаться с нами, только сформированной под забор первичных данных о недвижимости для последующего прозвона. Тогда эта форма обрабатывалась приложением Клиент и не мусорила в базе объявлений. Но тут уже на вкус и цвет.

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

Это получится сложная морока со скриптами, аякс-обработчиками и прочими радостями. Вам нужна именно совсем-совсем своя форма? Ведь большая часть полей что для квартиры, что для дома - совместные.

Если формы поиска создавались через Редактор форм, то никак разделить нельзя - движок рассматриват список категорий как единое и нераздельное целое. Для "разрезания" списка разделов формирование форм поиска или их частей нужно переносить в код и там разделять.

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