abushyk

Тут будет иметь смысл на такие, заведомо числовые поля поставить параметр rules. Например для тех, что могут быть дробными, поставить rules в виду Type:decimal Для тех, что могут быть только целыми Type: int Это не даст людям вводить шопопало, что они обычно и делают. Type:decimal будет заворачивать все неподходящие по формату значения, а если то-то задаст вместо точки запятую, то заменит ее на точку. Это будет входная проверка. Не лишним будет прогнать базу по таким полям, что бы привести ее к "математическому" виду. Плюс, можно в саму логику расчета добавить приведение числа к нормальному виду, если не делали прогонку самой базы. ПС. Установку rules следует использовать. по моему опыту ересью в числовых значениях грешат не только люди, но и довольно крупные фирмы. часто с выгрузок я засасывал в "числовых" полях значения вплоть до "сто квадратных метров" (что совершенно неделибельно) ))))

Тут дело не в точности скорее. Подозреваю, что 64.7 передается как 64,7 . Так как запятая применима разделителем целой и дробной частей только в рукописном тексте, то это число для математический операций приводится к числовому виду в 64. Отсюда и отличный от ожидаемого результат.

Нет. Автоматически ни карточка, ни список таких манипуляций не проводят. Слишком много вариантов. Например как вывести 256 769 или 400 550 345. Такие преобразования логичнее оставлять или в шаблоне или в локализациях из-за их специфичности применения. Так как 256 769, в зависимости от контекста может имет вывод и 256тыс или 256,8тыс или 257тыс или даже 260тыс. Если логику такого преобразования вы представляете, то я могу подсказать алгоритм преобразования числа для шаблона. Если не представляете, то универсального просто не существует.

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

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

ВЫВОД ЗАКЛАДОК проверяем есть ли юзер-формы {if isset($local_search_forms) && $local_search_forms|count>0} если есть <ul class="nav nav-tabs" id="search_forms_tabs"> выводим закладочку для стандартной <li><a href="#main_sf" data-toggle="tab">Все</a></li> а теперь в цикле выводим закладочки для юзер-форм {foreach from=$local_search_forms key=ftname item=ftdata} <li{if $ftdata.active==1} class="active"{/if}><a href="#{$ftdata.id}" data-toggle="tab">{$ftname}</a></li> {/foreach} </ul> {else} если юзерформ нет, то и закладок нам не нужно {/if} ВЫВОД ФОРМ проверяем есть ли юзер-формы {if isset($local_search_forms) && $local_search_forms|count>0} <div class="tab-content"> <div class="tab-pane" id="main_sf"> выводим панель стандартной формы {include file='new_search_form.tpl'} </div> а тут в цикле выводим панельки юзерформ {foreach from=$local_search_forms key=ftname item=ftdata} <div class="tab-pane{if $ftdata.active==1} active{/if}" id="{$ftdata.id}"> {$ftdata.body} </div> {/foreach} </div> {else} если юзерформ нет, то высыпаем просто одну нашу стандартную {include file='new_search_form.tpl'} {/if}

Вы буквально двух строк не дошли до цели) <div class="tab-pane" id="main_sf"> {include file='new_search_form.tpl'} </div> это и есть включение "стандартной" формы.

Редактор форм - Формы поиска - только создает форму. Совершением поиска это не занимается. Для поиска нужно использовать или template_search-подход или local_grid_constructor-подход. Сама форма только плодит параметры вбрасываемые в запрос и выводит нечто похожее на форму в шаблон. Как обрабатывать эти параметры и обрабатывать ли вообще - это уже выше способностей формы.

У городов нет поля url (Алиас, safe_string) в модели или оно есть, но не заполнено.

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

/apps/toolbox/admin/admin.php строка 645 UPD строка 602 $params[$uf]['ph']=$this->getConfigValue('apps.realty.data_image_preview_width'); замените на $params[$uf]['ph']=$this->getConfigValue('apps.realty.data_image_preview_height');

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

1. фотка приходит на сервер 2. читаются настройки что бы определить макс размеры на большую фотку и на превьюшки. определяется необходимость четко выдержать размер как для большой, так и для маленькой 3. исходное фото идет на обработку - из него по размерам и необходимости обрезки параллельно лепится превью и полноэкранка, которые идут в папку медиа 4 согласно настроек (юзается вотермарк, но нужно иметь копию без оного) - делается или нет дубликат большей (той которая сделалась из исходной в предыдущем пункте) в отдельную папку 5. согласно настроек на большую наносится вотермарк 6. исходник удаляется Это при первичной загрузке. При перерезке исходником выступает большая картинка или, при наличии, сохраненные дубликат большей без вотермарка. мелкая фотка нарезается из большей (поэтому если вотермарки наносились и не хранилась копия без него, то на мелких появятся они тоже) и заменяет собой предыдущую мелкую. исходня фотка (большая), не удаляется естественно. Да. тулбокс точно понимает параметр preview_smart_resizing=1 на элементе и должен понимать глобальную настройку "Использовать умную подгонку..." Никак. Вы управляете не пропорциями, а лимитными размерами. Они косвенно определяют пропорцию. На мелких можно резать - это превьюхи, допустимо для них. На больших обычно резать нельзя по двум причинам: 1. кому нужна большая фотка объекта обрезанная четко под заданный объект, где отрезались края? там ведь может быть что-то важное 2. фотки бываю портретные и альбомные. т.е. понятие пропорции для них как пятое колесо - можно, но не нужно. превьюхи вписываются повсюду в дизайн и что бы не развалить его они должны иметь формат, пусть и с потерей инфы. но полноэкранки как раз для посмотреть и резать на них что-то - догматизм перфекционизма. ПС. вообще четко зарезать большие фотки можно и иногда нужно, но это частные случаи и они не относятся к такмим фоткам, как фотки интерьера или окрестностей. Это больше относится к элементам с фото которые хранят дизайнерскую графику, напр. у меня есть города а в модели города есть поле под графику, куда я кидаю фотки для шапки. коглда клиент заходит на конкретный город, ему в дизайн соотв. каждому городу выставляется фотка под шапку из этого поля. тут да, мне нужно конечные фотки одной пропорции и одной ориентации и пофиг, если там чуть шпили на фотке срежет или землю немного обрежет.

вот так {0~~} {1~~первичная продажа} {2~~переуступка права} {3~~первичная продажа вторички} {4~~прямая продажа} {5~~встречная продажа} {6~~прямая аренда} {7~~субаренда} {8~~продажа права аренды} не используйте текстовые ключи для значений, только числовые. модуль выгрузки в яшу уже понимает это поле и в таком формате. а для работы с данными переход на числовые ключи съекономит вам тыщу-другую нервных окончаний.

такого типа нет, поскольку ссылка - это просто текст, если говорить грубо. Выведется ли она в виде html-элемента, простой текстовой строки или еще как-то иначе - этим должен управлять шаблон. Поддерживать элементы под такие типы - слишком накладно, потому что через два часа после добавления поддержки такого типа у нас выстроится очередь заявок на добавление типов элементов: комнатность (выводит строку "Комнат 5"), "цвет стен" (в виде виджета цветных квадратиков), "скидочная цена" (пишущая зачеркнутую цену) и ... да миллионы их))) понятно что вы хотите все это реализовать автовыводом, но поверьте мне, обычно проще разметить нормальный вывод элементов в карточке без него и получить офигенную карточку, чем пытаться впихнуть невпихуемое. тем более что набор элементов данных объявления рано или поздно приобретает статичный вид и перестает пополняться новыми полями.

В Натсройки - Дополнительно есть "Использовать умную подгонку превьюшек". Поставьтее ее в 1 или отметьте чекбокс, если єто чекбокс. При ней ВСЕ превьюшки (на всех объектах-новостях-и где только есть картинки) будут зарезаться четко в размер указанный в настройках, но именно зарезаться. Если такое нужно только для одного поля с фотками, то в Параметры в настройках этого поля в редакторе форм добавьте пареметр preview_smart_resizing=1 Это аналогично предыдущему, но имеет область действия только конкретный элемент.

или просто добавить поле типа textarea и через перенос строки набивать туда номера хоть сотнями)

Это не связано со способом формирования конечной строки. Это логика как и что взять. А как полученное склеить - это отдельный процесс. да, для php правильно. Но смарти - это не php в чистом виде. а если вы хотите делать это в шаблоне, то вам придется пользоваться правилами языка смарти.

Объединение строк в smarty происходит не через точку, а через модификатор cat http://www.smarty.net/docsv2/ru/language.modifier.cat.tpl Но вариант на массиве, по моему опыту, чаще более читабельный и удобный.

Я так понимаю вы хотите сделать что-то типа автогенерируемого текста на базе данных объявления. 1. такое лучше не делать в шаблоне. шаблоны, хоть и активные, но должны содержать поменьше такой механической логики. они часто из-за этого становятся нечитабельными. 2. если делать такое в шаблоне, то вот вариант {*создаем накопитель*} {assign var=x value=array()} {*наполняем накопитель*} {if $data.utug.value==1} {append var=x value='утюг'} {/if} {if $data.tv.value==1} {append var=x value='телевизор'} {/if} {if $data.refgigerator.value==1} {append var=x value='холодильник'} {/if} {if intval($data.sea_distance.value)>0 && intval($data.sea_distance.value)<501} {append var=x value='море в шаговой доступности'} {elseif intval($data.sea_distance.value)>500} {append var=x value='до моря '|cat:$data.sea_distance.value|cat:' м'} {/if} {*вываливаем накопитель в шаблон*} {if $x|count>0} <div>Мы предлагаем: {$x|implode:', '}</div> {/if} логика имхо очевидная, перебираем параметры и решаем, что закинуть в накопитель. потом склеиваем все зяпатой и отдаем наружу. если финальные предложения более сложные, чем банальное перечисление, то нужно создать несколько накопителей, собрать каждый из них, вывалить их в переменные и потому в последний накопитель загрузить эти переменные и уже вывести из него - тут все зависит от споьсоба склейки. можно склеивать потоково, как вы показывали, но там более сложные условия, нужно контроллировать что есть, что нет, где ставить запятую, а тут по факту код сам склеивает, вы только говрите что именно ему нужно объединить в строку.

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

кажется я описался. {$complex_info.devEloper_id._info}

а вот это уже сложнее. то, что вы нашли - это автовывод, когда вы не указываете что и куда выводить, а шаблон сам по кругу фигачит вывод всего, что ему пришло. В целом удобно, но когда нужно изменить вывод только какого-то одного свойства - жуть. То, где у вас есть похожее - это вывод значения для случая, когда значения в .value приходят в виде массива. Но для єтого єлемента они хоть и приходят в виде массива там, но в .value_string, которые склеивается запятой, они не массив, а уже склеенная строка, поэтому там оно не отрабатывает. Вам нужно каким-то образом ловить ваш элемент, пусть даже по системному имени. Там есть отлов полей fio, email. Аналогично вам нужно помать по имени вашего мультиполя и внутрь выставить вот ту штуку, что я написал. .... {elseif $data_item.name eq "phone"} {assign var="agent_phone" value=$data_item.value} {elseif $data_item.name eq "email"} {assign var="agent_email" value=$data_item.value} {*ЭТО БЫЛО*} {*НАЧИНАЕМ ВНЕДРЯТЬ*} {elseif $data_item.name eq "МОЕ_МУЛЬТИПОЛЕ"} {if $data_item.value_variants_array|count>0} <tr><th>{$data_item.title}</th><td>{', '|implode:$data_item.value_variants_array}</td></tr> {/if} {*ЗАКОНЧИЛИ ВНЕДРЯТЬ*} {*ПОЕХАЛО ДАЛЬШЕ, ЧТО БЫЛО*} {elseif $data_item.type eq "destination"} ....

да да. вокруг названия поля. означает - сделать для всех строк для которых выполняется условие после WHERE. Так как 1 - єто єкивалент истины, то условие после WHERE в виде единички выполнится для любой строки. Другими словами это читается как "сделать для всех".

А это нужно смотреть в модели девелопера, под каким именем значится телефон.