abushyk

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

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

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

кроме заголовка темы))))

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

что такое "авто-выгрузка"?? выгрузка в Авито?

вы хотите не добавлять в модель объекта поле Регион, но что бы в выгрузку шли значения регионов?

Да, она не идет из коробки. Исходно на выгрузку идут все активные объявления. Если в настройках приложения указать имя чекбокса, то только тогда оно начнет его отслеживать. Так как у вас чекбокса нет, но 700 объяв все равно есть в фиде - значит чекбокс тут не при чем. Так же фильтрует настройка "Количество дней за которое будут выбраны объявления для выгрузки" которая отсекает откровенно древние позиции. Посмотрите что стоит у вас там и каковы даты добавления объектов в БД. Ну и дальше изучать лог - выгрузчик, хоть и по минимуму, но пытается отсекать явно невалидные параметры.

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

нет. это сейчас у вас каша в типах)))) там в кучу и аренда, и вторичка (которая подразумевает скорее всего продажу, но далеко не факт), и дома (которые в таком виде могут означать и аренду, и продажу, и что угодно), и жилые комплексы (который тоже хотят иметь подпункты двушки-трешки-студии). Это само по себе не плохо, но требует некоторых аксиом и некоторого дублирования. например вы аксиоматично допускаете, что "Дома" - это продажа. Это ясно вам, потому что это ваша задумка, это ясно мне, потому что я уже представляю логику, но это нифига не ясно посетителю. Как это выглядит - https://bn.ua/ В сайте есть два параметра - тип объекта(комната, квартира,...) и тип контракта (продажа, аренда, посуточно) - никаких разделов типа Продажа квартир или Аренда домов не существует вообще. Путем их перекрещивания образовываются фантомные разделы всех вариантов комната+продажа, комната+аренда,.... Идея похожая как вы делаете в линкменеджере, где некий адрес-урл создает фасад для фактических параметров типа topic_id=N&optype=M Но возможно это избыточно и имеет смысл взять логику как у Игорь Ивановича - https://realty-centrum.com/, где он выделил разделы аренды и продажи, правда не до конца, оставив за бортом загородку и участки (смотрим выше про допущение аксиом).

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

наличие селекта, даже с многовыбором, подразумевает одно имя переменно. если у вас есть поле refrigerator и tvset, то таким селектом напрямую вы их с формы все-равно не отправите. Но вы можете отправить что-то типа <select name="home_opts[]" multiple="multiple"> <option vale="refrigertor">Холодильник</option> <option vale="tvset">Телевизор</option> </select> т.е. в запросе у вас будут ходить не привычные refrigerator=1&tvset=1 а нечто более замудренное home_opts[refrigerator]=1&home_opts[tvset]=1 соотвественно там, где реализован перехват переменных из запроса и их обработка, нужно будет скорректировать условия, если ранее вы проверяли наличие refrigerator и его равенство 1 перед тем как добавить условие поиска по полю refrigerator, то теперь нужно перехватить из запроса переменную home_opts, проверить в ней наличие ключа refrigerator и тогда уже добавить условие. все то же самое, только чуть другим путем. ПС. я возможно не понял вопроса, поэтому ответил на то, что как мне кажется я понял)

Это бывает, когда дважды включается файл <script type="text/javascript" src="{$estate_folder}/template/frontend/{$current_theme_name}/js/search_form.js"></script>. Посмотрите файлы связанные с формой поиска. Бывает, что форма поиска включается с помощью search_form.tpl в котором включается standart_search_form.tpl. так вот включение search_form.js должно быть только в одном из них, например в самом верхнем.

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

Сделайте скрин с настроек приложения Geodata и приложите файлик realty_grid.tpl пожалуйста.

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

Если количество ЖК в базе не исчисляется сотнями, то: 1. В main.php в папке шаблона внутри класса class frontend_main extends SiteBill_Krascap создаем функцию function preloadComplexAliases(){ $cache_time=86400; //1 сутки $aliases=array(); $cache_file=SITEBILL_DOCUMENT_ROOT.'/cache/cache.local.complex_alias.txt'; if(file_exists($cache_file) && (time()-filemtime($cache_file))<$cache_time){ $aliases=unserialize(file_get_contents($cache_file)); }else{ if(file_exists($cache_file)){ unlink($cache_file); } $aliases=array(); if(1==(int)$this->getConfigValue('apps.seo.no_trailing_slashes')){ $trailing_slashe=''; }else{ $trailing_slashe='/'; } $DBC=DBC::getInstance(); $query='SELECT complex_id, url FROM '.DB_PREFIX.'_complex'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ if($ar['url']!=''){ $aliases[$ar['complex_id']]=SITEBILL_MAIN_URL.'/'.$this->getConfigValue('apps.complex.alias').'/'.$ar['url'].$trailing_slashe; } } } $f=fopen($cache_file, 'w'); fwrite($f, serialize($aliases)); fclose($f); } return $aliases; } которая будет отдавать нам массив в котором ключем будет идешка жк, а значением по этому ключу - ссылка на него. Функция будет кешировать данные в текстовый файл на срок $cache_time=86400; //1 сутки. Если ЖК меняются-добавляются у вас чаще, то можно сделать это значение поменьше. 2. внутри функции main() в этом же файле делаем заброс этих данных в шаблон $this->template->assert('complex_aliases', $this->preloadComplexAliases()); это можно разместить в самом начале функции, но не выше строки global $__site_title, $folder, $smarty; 3. Теперь в любом шаблоне фронта вы можете использовать переменную {$complex_aliases} если в этом случае у вас доступна идешка ЖК. Например в карточке это может выгядеть так {if $data.complex_id.value>0} {if isset($complex_aliases[$data.complex_id.value])} <a href="{$complex_aliases[$data.complex_id.value]}">{$data.complex_id.value_string}</a> {*выводим название в виде ссылки*} {else} {$data.complex_id.value_string} {*ссылки по каким-то причинам нет, выводим только название*} {/if} {/if} Почти аналогично это будет выглядеть и в шаблоне списка. Таким нехитрым способом с минимальным кешированием мы можем обеспечить себя каким-то дополнительными сквозными данными в шаблоне.

в большинстве случаев это будет называться флеш-анимация или gif-анимация

Вопрос по фоткам думаю можно считать закрытым. Как и предполагалось проблема в разрешении исходного фотоматериала.

В настройках в Общее должен быть параметр link_street_to_city. Он указывает привязывать улицы к городу. Если его сделать ноль (или разотметить, если это чекбокс), то удет считаться что улицы привязаны к районам.

<IfModule mod_rewrite.c> RewriteEngine On #с www на без www - тут же одним махом заворачиваем гарантированно и на хттпс RewriteCond %{HTTP_HOST} ^www.metrpro\.ru$ [NC] RewriteRule ^(.*)$ https://metrpro.ru/$1 [R=301,L] #с http на https - уже только адреса без ввв RewriteCond %{SERVER_PORT} !^443$ RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L] #с без слеша на со слешем - финальное условие чисто на концевой слеш RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} !(.*).php$ RewriteCond %{REQUEST_URI} !(.*).xml$ RewriteCond %{REQUEST_URI} !(.*).html$ RewriteCond %{REQUEST_URI} !(.*)/$ RewriteRule ^(.*[^/])$ $1/ [L,R=301] </IfModule> склеят или нет, но лучше склеивать самому.

да. при любом обновлении системы, обновления никогда не заливаются и, думаю, никогда не будут заливаться в папку /template так как почти всегда там есть какие-то свои наработки и изменения.

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

нет, не правильно. 1. $current_user_info существует ТОЛЬКО в шаблоне. нигде в коде она не будет доступна, хотя бы потому, что она даже создается вне того кода, где вы пытаетесь ее использовать. 2. просто смешанный синтаксис из, грубо говоря, двух языков. Не все можно слепить из кусочков. Если вам так хочется, то вы можете в своем локальном user_data.php убрать вывод getTopMenu что бы эта менюха не выводила никаких кнопок. А потом в реалти_грид_аккаунт.тпл сделать, уже привычными средствами шаблона, перед таблицей свои кнопки, в том числе и ту "Добавить объявление", которую изничтожите в getTopMenu.

Если вы не используете поля типа uploadify_image, а только uploads, то допустимо закрыть папку /cache/upl/ вообще безусловным Deny from all. Разрешение на картинки дано исключительно ради поддержки этого элемента, так как он оттуда показывает превьюшку на форме при загрузке. Я потом подберу ему другой способ превьюирования, совместимый с uploads, и это разрешение станет неактуальным.