Leaderboard

1) Все объявления поданные с фронта сайта через форму /add/ при отключенной опции авторегистрации привязываются к некоторому абстрактному пользователю с именем Незарегистрированный. 2) данная опция не дает активировать объявление из ЛК разрешая пуликацию на сат ТОЛЬКО администратору из админпанели. Т.е. даже если владелец отметит Активно в ЛК и сохранит, галочка все-равно будет сброшена и поставить ее сможет только админ после проверки. 3) а некоторые операции стоит блок-проверка доступности операции для админа. если в одном браузере открыт и фронт и админка. и там и там с залогинившимися пользователями - может наступить момент, что их сессии частично перекроют друг друга, что может привести к некоторым глюкам. Попробуйте закрыть браузер, а после открытия, зайти просто в админку и посмотреть сохранилась ли проблема.

Приветствую! Ну, тут где-то Вы правы... Просто привык, что существуют уже продуманные решения... А если говорить о конечной цели, то в принципе, её можно было уловить из моего "потока сознания" выше.)) Вопрос в методах её реализации... Хотя да, перечитав свои посты чуть выше - понял, что это довольно проблематично))) Попробую ещё раз описать то, чего желаю добиться... Необходимо реализовать посуточную аренду совместно с долгосрочной, не создавая для этого отдельных категории. Чтобы пользователь при добавлении объявления о сдаче квартиры (как посуточно, так и долгосрочно), выбирал только одну категорию. Например: человек при подаче объявления о сдаче 1 комн. квартиры, которая сдаётся посуточно, но может сдаваться и долгосрочно, выбирает только категорию "Аренда 1 комн. квартиры" (а не "Аренда 1 комн. квартиры" вместе с "Посуточной арендой 1 комн. квартиры"), где помимо основной "посуточной цены", он может проставить 2-ю цену за долгосрочную аренду. Для соискателя такой квартиры можно ограничится одним пунктом в "Основом меню" - "Посуточная аренда квартир" (помимо расширенного поиска), откуда ему выведутся все квартиры, сдаваемые посуточно (а там он уже сможет их дополнительно отфильтровать, используя "сетку-фильтр" на Главной). Ну, вот как-то так я себе это всё представляю...))) Что касается реализации этой схемы, то тут мне видится создание трёх дополнительных колонок: 1) "Чекбокс о сдаче посуточно" - для последующей выборки таких объектов из таблицы. Хотя, если возможна выборка в зависимости от заполненности поля "Цена в сутки", то этой колонкой можно принебречь 2) "Цена долгосрочная" 3) "Цена в сутки" Создание именно 2-х новых полей с ценами, позволит не перемешиваться с продаваемыми объектами в поиске по цене. Далее, необходимо вывести всё это дело: 1) добавить в Главное меню ссылку вида site.ru/index.php?extended_search=1&topic_id=0&floor_min=&floor_max=&floor_count_min=&floor_count_max=&square_min=&square_max=&price_min=0&price=0&region_id=0&city_id=0&district_id=0&geoautocomplete%5Bstreet_id%5D=&street_id=0&daily_rent=1 2) Каким-то образом компактно реализовать вывод обоих цен на "предварительном просмотре" и основной карточке объекта Т.е. мы добиваемся того, что основой будет "Долгосрочная аренда" (под неё и создаются все катеории), а "Посуточная" - дополнительная (её выборка делается посредством фильтра). P.S. Я ещё полностью не изучил все возможности движка, поэтому может всё это можно реализовать по-другому. Да, и сам я не "супер-проггер"!)))

У вас в настройках флаг наложения вотермарков выключен.

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

Допустимое системное имя элемента этого типа: tlocation (и не иначе) Этот тип поля не хранится в БД as is. Поэтому галочка Хранить значение поля в таблице должна быть снята. Задачи компонента 1) управлять географической структурой адресных полей 2) реализовывать подбор данных для элементов географии не-tlocation, но с параметров autocomplete=1 Тип поля модели, отвечающий за адресные данные. Содержит в себе 5 встроенных компонентов country_id - идентификатор страны из таблицы country region_id - идентификатор региона из таблицы region city_id - идентификатор города из таблицы city district_id - идентификатор района города из таблицы district street_id - идентификатор улицы из таблицы street Предполагает наличие иерархической зависимости именно в порядке country_id -> region_id -> city_id -> district_id -> street_id Есть одно исключение. Если указан параметр link_street_to_city из иерархической цепочки исключается звено district_id, и street_id считается зависимым от city_id. Принципиально каждый компонент этого типа не обязана соответствовать буквально своему названию. Например city_id может указывать на район области в тот момент, когда region_id указывает на область, если в соответствующих таблицах city и region содержатся данные о областях и районах областей. Допустимые параметры: visibles - перечень отображаемых компонентов. Указывается в формате компонент1|компонент2|компонент3 Порядок компонентов не важен. При отсутствии этого параметра или его пустом значении будут отображены все компоненты. (Это поведение будет изменено. При отсутствии этого параметра элемент не будет генерироваться. Поэтому лучше явно указывать список выводимых частей) Например region_id|city_id выведет селектбоксы для региона и города. Результат default_country_id, default_region_id.... - значение по умолчанию. например выбрано для отображения регион и город. Если текущее значение country_id не установлено, список регионов с списке выбора регионов будет установлен соответственно default_country_id, если оно задано и не равно 0. В противном же случае будет выведен список всех регионов из таблицы region show_names - признак того, нужно ли выводить возле каждого подэлемента tlocation имена-метки. По умолчанию и при отсутствии данного параметра считается включенным (=1) Включено Выключено names - имена отдельных элементов. Задаются в формате имя_подэлемента:имя_метки|имя_подэлемента2:имя_метки2 Обновление вывода. С версии system-2.5.25 и tlocation-1.1 генератор формы возвращает tlocation в форму не как обычный эемент (заголовк и кусок хтмл для вставки), а как коллекцию элементов. Для тех, кто использует базовый файл /apps/system/lib/frontend/search/kvartira_search.php для генерации форм поиска это изменение учтено. Тепер такие блоки как {$country_list}, {$city_list}, которые находились в шаблоне форму поиска, при наличии элемента tlocation будут заменены соответствующими кусочками элемента tlocation. Но ничто не запрещает присваивать разметку этих элементов другим переменным шаблона и свободно перемещать их в пределах формы. Те, кто использовал локальные формы поиска с {$tlocation_form_element_simple.html} столкнутся с багом.