abushyk

Посмотрите в Настройки - Дополнительно. Там должен быть параметр Параметры сравнения дублирующихся объявлений (apps.realty.uniq_params). Если он есть, то туда можно вписать свои значения по которым будет проверяться похожесть. Например city_id,topic_id,priceили street_id,number,floorт.е. системные имена полей по которым идет сравнение.

нет. движок не обработает их, посему и не умеет формировать.

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

Никаких новых из тех, что были на 5 версии в этом списке нет. Что в какой-то мере обнадеживает))

поправил

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

Например в pure по моим предположениям должно быть. Тот что лежит у меня имеет локализированый обработчик ЖК в том числе и вывод объектов в шаблоне карточки конечного ЖК. Некоторое понимание вполне может понадобиться. Если бы вы получали движек в состоянии "вот тебе есть поля, больше их не будет, добавить свои ты не сможешь, заполняй то, что есть", тогда да, все ваши действия свелись бы к введению данных. Но поскольку такой вариант почти никого не удовлетворяет, то имеет место более свободное обращение с форматом объектов и, соотв. невозможность предугадать все возникнущие на стороне пользователя варианты вывода и обработки. И тогда может понадобиться некоторое умение.

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

Работ по адаптации под 7 не проводилось, поэтому пока считаем, что не адаптирована. Ошибка произошла из-за устаревшенго и наверное уже последнего места, где делается попытка использовать устаревшую библиотеку работы с БД. Большая часть пользователей ее не замечают, так как хостеры еще часто поддерживают ее. Но более продвинутые хостинги уже начинают просто вырубать. Для решения достаточно просто в db.inc.php удалить строки if (!isset($__connection)){$__connection = mysql_connect($__server, $__user, $__password) or die('Не удалось поключиться к серверу БД (' . mysql_error() . ')');mysql_select_db($__db)or die ('Не удалось подключиться к БД(' . mysql_error() . ')');mysql_query("SET NAMES utf8");}Ошибка с ключем это 99% последствия описанной выше ошибки.

Абсолютно не имеет разницы ситуация когда в одной базе много таблиц с разными префиксами и когда несколько баз с однопрефиксными таблицами. Кроме случая, когда на хостинге стоит ограничение на количество баз. Грубо говоря префиксы менять можно. Но есть далеко ненулевая вероятность, что где-то еще используется старый префикс re_ в явном виде. Поэтому надпись "не менять" мы пока не убираем. Если вы расплодите кучу баз у вас вместо проблемы разделения данных на вывод станут не менее сложные проблемы, такие как синхронизация общих данных и справочников, проблемы сквозной авторизации, что бы на каждом сайте пользователь не держал логин-пароль и просто обилие данных которыми нужно управлять. Если все деление ограничивается только объявлениями, то проще вскрыть обработчик сетки и карточки и вариативно загнать в него настройки (например в зависимости от домена-субдомена), которые определят дополнительные фильтрующие параметры (город, район), которые не будут подчиняться значениям из запросов а будут встраиваться мертво. Тем самым вы сделаете внутреннюю скрытую фильтрацию на одной базе объявлений с одной админкой и зависящих от домена настроек. Это будет самой легкой частью. Дальше становится проблема новостей и подобных сущностей при желании разнести которые аналогичным образом вы становитесь счастливым обладателем некое кастомного мода сайтбилля))

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

даже больше, если забайкальского рабочего запросить с номером в самих картах в браузере, то находит, а вот через геокодер - нет.

Вы правильно написали - {$photo.title}

Для тех, кто следит за темой добавлю решение проблемы: внимательно следите за именами параметров. В данном случае я не заметил, но имя параметра было написано prew_width вместо prev_width, что провоцировало его игнорирование и неправильную установку высоты картинки.

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

В некоторых шаблонах там уже есть вывод вложенных объектов. Обычно просто в редакторе форм для data добавляется поле-справочник complex_id для указания приндлежности к ЖК. Расставляются эти принадлежности. В настройках самих ЖК есть галочка - Выбирать объекты ЖК в карточку ЖК или как-то вроде этого. Тогда при формировании просмотра ЖК привязанные объекты будут подхватываться и выводиться в карточку ЖК. Это так вкратце и для ситуации в вакууме.

Маловероятно. Одно время у меня была идея вынести все включаемые скрипты-стили наружу из модулей и сформировать пулл библиотек. Конечному пользователю оставалось только бы при использовании каких-то возможностей включать библиотеки и этого пула в активные (что естественно требует понимание большего, чем просто добавить элемент uploads в редакторе форм и сразу им пользоваться), что бы они подключались. Но поскольку энтузиазма я не заметил, то и это пока ушло на полку.)))

одной базы как общего набора таблиц или как просто хранилища реплицированных таблиц с разными префиксами?

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

ОФФТОП Магическая фраза))) После нее с вероятностью в 99% зарываешься в код дня на два)))

Вы реально готовы и сможете прописать тайтл для каждой фотки?

1. Если у вас такая здоровая карта на морде сайта с кластеризацией, то она обновляется раз в сутки. Если нужно быстро сбросить кеш, на время отладки например, то ищем в папке /cache/ файлі типа map_data_...txt и удаляем. Кеш сборсится и данные обновятся. Для остальных типов карт - на них выводятся только объекты с координатами. явными. 2. координаты заданы для такого объявления? И если заданы, то каким образом. Есть еще небольшой глюк в карточке. Но что бы его решить мне нужно будет фтп. 3. В чем сложность?

Тогда пока будет так как вы сделали, а на след обновления я немного там сменю логику и идешка автоматом будет включена в список.

Тут все верно. Просто на тот крайний уровень, который работает с ответом клиенту, эти данные не приходят и дажде не предусмотрено слота, через который можно было бы его отдать. А без ИД узнать этот же ИД нельзя, как бы дико это не звучало. Можно пытаться вызывать запрос на последний добавленный ИД, но опять же между вставкой и запросом может пройти еще 100 других запросов, что сводит результативность к нулю. Быстро решить можно путем добвления строки $form_data['id']['value']=$new_record_id; в файле /apps/system/lib/frontend/form/add.php в строке ~~479 перед $table_view = new Table_View(); Тогда идешка нового объекта будет включена в список выводимых параметров в сводке после подачи.

Спору нет, но разбивка данных по группам в форме, в просмотре и даже группировка их для объекта выводимого в списке - все это может иметь разные принципы группирования. А создать какой-то универсальный вариант будет сложновато.