abushyk

По кнопочке и ее классу. Что бы не вносить изменения в системный шаблон и не тянуть весь шаблон мейлбокса в локалку сделайте так В файле \apps\mailbox\site\template\form.tpl в строчке <span><a href="#" id="complaint_this_adv" class="btn btn-info"><i class="icon-white icon-warning-sign"></i> {$apps_words.mailbox.MAILBOX_COMPLAINT}</a></span> кусочек class="btn btn-info" замените на class="{$mailbox_btn_classes_complaint}{elseif $mailbox_btn_classes!=''}{$mailbox_btn_classes}{else}btn btn-info{/if}" После этого в файле шаблона карточки в включении мейлбокса {include file=$apps_mailbox_block title_data=[$data.topic_id.value_string,$data.city_id.value_string,$data.street_id.value_string] to=$user_data.user_id.value send_friend_window_hide=1 mailbox_btn_classes_complaint="btn btn-primary"} Я уже планировал добавление таких мелких включений без локализаций, но они еще не вышли в обновления.

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

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

Немного не то. Например не прокатят номера документов, которые запросто могут начинаться с ведущих нулей. Т.е. значение запишется, но данные будут не совсем верные. Или например номера телефонов без префикса страны с кодом оператора, начинающимся на 0. Не знаю как в РФ, а в Украине наверное все сотовые начинаются именно с нуля в своей привычной записи и большинство кодов городов. С новой версии будет rules в виде numerical под хранение числовых последовательностей с возможностью указания максимальной и минимальной длинны. Думаю часть потребностей такой тип охватит.

не появится) это не стандартная штука.

не то меню. не список разделов. меню, которые отдельно создаются. как в реалии вверху в полоске Продать, Сдать, контакты или в подвале for_user_menu (Пользователю).

Я бы посоветовал не использовать параметр с именем srch_word для поиска по тексту. Параметр с таким же именем обрабатывается системой и могут быть нестыковки в результатах.

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

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

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

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

Да сам скрип-то сработает. Проблема в другом: 1. в странице нужен этот блок расширенного поиска, что бы было что открывать или где показывать. 2. если блок расширенного поиска встроен в форму поиска в виде показываемо-скрываемого блока, то при закрытии его может понадобиться очищать выбранные в нем значения. Вот https://pastebin.com/ANT1GXSN я взял из шаблона файл standart_search_form.tpl и прикрутил к нему "расширенный" поиск.

Нет. Выключить выдачу ссылок меню в карту сайта настройками нельзя. Но я учту.

Только есть одно но - сайтбиль не обрабатывает район как точку доступа к странице с метой. Т.е. для страны, региона и города вы можете прописать алиасы и мету и при переходе на адреса этих объектов вы будете получать соотвествующие списки и мета-данные, но для районов такой функционал не поддерживается. Максимум, что можно сделать с районом - это отфильтровать в поиске c параметом district_id=N, но речи о мета-данных тут уже не идет.

Для городов, райнов, стран, регионов в Редакторе форм для соотвествующих моделей city, district, country, region вы можете добавить три поля с системными именами meta_title (тип safe_string), meta_keywords (тип safe_string) и meta_description (тип textarea). Либо вы можете использовать кнопку в редакторе форм она добавляет эти три поля в таблицу. После ее использование нажмите в том же ряду кнопку Обновить - она шестая справа, синяя.

Вы сделали отличный скрин с красной стрелкой указывающей куда писать. Туда и впишите.

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

В общем-то все так и есть. Только крошки не только в разделах. Но и в ЖК, статьях, новостях и прочих приложениях. Так же они могут быть сложными - вложенность Тип - Локация - Контракт. Плюс к этому есть разброд и шатание в внешнем виде крошек в разных местах и отсуствие возможности повлиять на это. Именно поэтому я и хочу сделать их единым элементом. Как сделал с постраничной навигацией, которая теперь может описываться своим файлом шаблона в нужной разметке без колдовства со стилями, что бы заставить стандартную разметку выглядеть адекватно в конкретном шаблоне. К тому же у крошек есть два концептуальных варианта описания в схеме, если ничего не изменилось, - линейный (когда размечена просто цепочка) и вложенный (когда более верхние элементы цепочки оборачивают своим описанием более низшие).

Открываете список групп в системе и тыкаете Редактировать на нужных группах. В строке браузера будет ... /admin/index.php?action=group&do=edit&group_id=3 вот эта цифра после group_id и есть нужные вам идешки. Вносите их в то поле в виде 3,5,12 - через запятую. Группу Админов выносить в список доступных к регистрации я не советую. Разве что вам нужны какие-то незнакомые люди с доступом в админку и всеми правами в ней.

Да. Бот всегда будет видеть дефолтный язык. Человек же, переключая язык, может запросить страницу на другом, недефолтном языке. Для сео этот вариант не подходит, так как бот не узнает про другие языки. В этом случае следует использовать систему поддоменов вида en.site.ru, fr.site.ru и т.д., которые будут ссылаться на один и тот же сайт, но, в зависимости от поддомена, будет включаться нужный язык. Тогда и роботы оценят наличие мультиязыка и людям будет понятно. Но с таким подходом будет проблемой вынести на поддомены еще что-то, например отдельны страницы локаций или других объектов. Верно. Это исправимо. Сейчас выбор языка идет как ссылка с параметром. Но где-то я использовал переключение языка как отправку запроса на сервер с просьбой переключить язык + рефреш текущей страницы, которая просто перезагружала страницу, но уже вступало в силу запрошенное изменения языка и она отображалась на другом языке.

Разметку под крошки в шаблоне сделать нельзя. Для некоторых объектов был вариант выноса крошек в шаблон (жк например) или формирования крошек в "доступном" коде (ЛК и его страницы), но это были частные случаи. Основная масса крошек создается внутри системных файлов. Как только я приведу все крошки к одному месту создания я сделаю под них шаблон с учетом схемы или возможности указания своего шаблона.

Это можно понять только экспериментальным путем - ставить разные настройки и загружать на пробу и смотреть. Тут получается поиск баланса между крайними "хорошее качество+конский размер" и "плохое качество и минимальный размер"

настройки - Общее - Заголовок сайта(site_title) - наверное это то, что вам нужно. Это дефолтный заголовок, который выдается, если другого конкретного найти не удалось. По сути он и есть главный.

Да. Берем новое содержимое для файла \apps\system\lib\frontend\search\kvartira_search.php из https://pastebin.com/5t6Bsj07 В файле main.php вашего шаблона находим строку запуска формы поиска $kvartira_search_form = new Kvartira_Search_Form(); и после нее добавляем $kvartira_search_form->setCustomElements('city_id', array('parameters'=>array('autocomplete_notappend'=>1))); Аналогично можно для формы сделать неавтокомплит поле, если на форме добавления оно с автокомплитом $kvartira_search_form->setCustomElements('city_id', array('parameters'=>array('autocomplete'=>0))); Либо вообще сменить тип элемента $kvartira_search_form->setCustomElements('city_id', array('type'=>'select_by_query_multiple')); Но, если у вас стандартный модуль поиска и не древняя версия движка, то при поиске с формы добавление автокомплитов не должно происходить - этот момент я изменил уже довольно давно.

Для добавления выбора группы при регистрации: 1. в модели user для поля group_id в его настроках снимаем видимость для группы Админов - снимаем все выделения, что бы поле было доступно ьез ограничений 2. Настройки - Общее - ID групп, допустимых к выбору пользователем(newuser_registration_shared_groupid) - в єтом поле через запятую перечисляем идешки групп, которые мы разрешаем выбирать для себя новому пользователю при регистрации. например 6,3 Соответственно блок выбора группы при подаче объявления не нужен, так как сам аккаунт уже определяет, кто подал объект. Для замены слова Агент на Собсственник\Агентство (имя группы владельца объекта) в файле realty_view.tpl в <div class="title"> <h2>Агент</h2> </div> меняем на <div class="title"> <h2>{$user_data.group_id.value_string}</h2> </div>