abushyk

в приведенном мной примере данные выбираются as is без учета видимостей по группам, и аналогий в модели user, и любых других условий. Это просто выборка из БД. Для использования других условий, в том числе извлечения текстовых значений для поле типа select_by_query, подгрузки дополнительных данных из связанных таблиц нужно использовать уже совершенно другой подход, с запросами по нескольким таблица, с выборкой не из БД а через функции Data_Model.

точно пропустил.

Уже лучше, хоть все еще абстрактно)) Понятно уже что ошибка на запросе к БД. Но не понятно в каком месте кода она возникает. В логе отсылка на сам модуль работы с запросом а не на точку появления ошибки. Посмотрите через пхпмайадмин в таблицу re_user. Есть ли в ней колонки active, email и pass

В main.php шаблона внутри блока if ( !$has_result && preg_match('/^account/', $REQUESTURIPATH) ) { сделать $current_user_info=array(); $DBC=DBC::getInstance(); $qery='SELECT * FROM '.DB_PREFIX.'_user WHERE `user_id`=?'; $stmt=$DBC->query($query, array(intval($_SESSION['user_id']))); if($stmt){ $current_user_info=$DBC->fetch($stmt); } $this->template->assert('current_user_info', $current_user_info); После этого в шаблоне у вас есть {$current_user_info} содержащее все данные текущего пользователя в простом виде. Напр. {$current_user_info.login} - логин. Естественно select_by_query значения будут присутствовать только в виде ключа.

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

Вы колонку ID у объявления не удаляли? Дайте ссылочку на сайт.

Если вы имеете в виде, что все что отмечено стрелочками на скрине - это один абзац, то в строке с первой стрелочкой удалите </p>, в строке со последней - <p>, а в тех, что между ними и <p> и </p>.

Напишите мне в приват доступы по фтп и адрес сайта. 500 означает ошибку сервера. ее нужно смотреть или по логам или отладкой.

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

иногда проще вывести меньшую разрешенную часть, чем запрещать вывод большей запрещенной. можно делать и так как пишу и так как вы говорите - разница в общем только в наглядности. Редкое добавление нового\новых полей на устоявшемся сайте и последующая правка шаблона под вывод этих параметров достаточная цена за простоту, гибкость и понятность самого шаблона. тут все зависит от концепции шаблона и предпочтений. хоть плюсик, хоть словами, хоть вообще не выводить эту строку если отсуствие галочки означает отсутствие телевизора. в 99% "возможно пригодится" не работает) Любой шаблон с адекватно разверстанной и приятной глазу подачей данных и меньшим количеством параметров даст фору лобовому автовыводу с тысячей значений "на всякий случай". Это я вам гарантирую. Никто не любит свалку в параметрах. Я хочу четко понимать где локация объекта, где его ценовые характеристики, где контакты, а где начинка.

имел в виду разметку а не имена невыводимых полей. Если вы напишете {$data.ploshad.value} - то вы 100% будете знать что выведется площадь и только. Если вы не напишете {$data.ploshad.value} - то площадь не выведется. Вот проще уже не бывает. А в цикле автовывода выводится ВСЕ каруселькой и зависит от разных правил доступности по группам. Так какой способ однозначнее, очевиднее и надежнее? с помошью новой разметки вы только симитировали структу ячеек, как табличку, только с плавающим количеством колонок в строке. А теперь вам нужно браться за укршение самого содержимого ячеек. У вас там есть имя параметра и его значение {$data_item.title} {$data_item.value_string} их нужно стилить по разному, что бі они отличались. Значит оборачиваете их в разметку, например <label>{$data_item.title}</label><span class="pval">{$data_item.value_string}</span> и начинаете приделывать стили к label и span.pval в контексте блока краткого описания. Только тут следует быть внимательным - разные типы элементом имеют разное представление в странице - это может быть и текст, и чекбокс для поле checkbox.

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

верно. в точку вот в ту строку ничего вносить не нужно, так как она обрабатывает невыводимые поля. а в те, что ниже, где уже есть какие-то теги - да. оффтоп. Знаете зачем придумали строительные панели? Для удобства прораба. Он быстро краном монтирует из панелей блоки этажей и гонит кран на следующую стройку поднимать следующее типовое здание. Для этого же нужен и автовывод в карточке. Если вы захотите применить новую финскую кладку кирпича в вашем доме, то вы не будете использовать бетонные панели и выдалбывать зубилом на них прожилки, имитирующие кирпичную кладку. Пока вы пребываете в смятении относительно того какова будет финальная модель вашего объявления автовывод логичен. Но,фы когда вы уже определились с ней и новые поля в вашу модель добавляются эпизодически раз в месяц в лучшем случае, то есть смысл снести его и расписать нормальный осознанный вывод только тех полей, что вам нужно и в такой разметке, что вам требуется не мучаясь с попытками вставить все это в условия автовывода (вот например карточка - https://abestate.ru/retail/realty704/ группировано, читабельно, но автовыводом без повреждения мозга так не сделать). Автовывод - это универсальное решение, но никак не лучшее и не самое удобное.

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

Вы вложили текст в <div class="bottom-wrapper"> а нужно в <div class="bottom container">

Способ через спан3 может быть, но я его не буду описывать поскольку его ценность, применимо к автовыводу параметров, будет только в том, что бы показать как можно извратиться, что бы достать пяткой до левого уха через спину. Первое что вам нужно сделать это заменить вывод параметров с табличного, как исходно в реалии на списочный. Т.е. ваши параметры должны выводиться не <h2>Кратко</h2> <table> {foreach from=$hvd_tabbed item=tab key=tabname} .... {elseif $data_item.type eq "select_by_query"} {if $data_item.value_string!=''} <tr><th>{$data_item.title}</th><td>{$data_item.value_string}</td></tr> {/if} {elseif $data_item.type eq "select_box_structure"} {if $data_item.value_string!=''} <tr><th>{$data_item.title}</th><td>{$data_item.value_string}</td></tr> {/if} .... а в стиле <h2>Кратко</h2> <ul> {foreach from=$hvd_tabbed item=tab key=tabname} .... {elseif $data_item.type eq "select_by_query"} {if $data_item.value_string!=''} <li>{$data_item.title} {$data_item.value_string}</li> {/if} {elseif $data_item.type eq "select_box_structure"} {if $data_item.value_string!=''} <li>{$data_item.title} {$data_item.value_string}</li> {/if} .... А дальше берем сss и для li делаем стили {float: left; width: 33%} для больших єкранов и для меньших {float: none; width: 100%}. Тогда они сами будут становиться в строку по три без лишней математики.

в main.php шаблона есть строки if (!$has_result) { $work_subcontroller = 'realtygrid'; //$params['_collect_user_info']=1; $this->template->assert('main', '<p><br></p>' . $this->grid_adv($params)); if ($REQUESTURIPATH == '' && empty($_GET)) { $this->template->assert('main_page_view', 1); $work_subcontroller = 'home'; } } замените их на if (!$has_result) { $work_subcontroller = 'realtygrid'; if ($REQUESTURIPATH == '' && empty($_GET)) { $this->template->assert('main', '<p><br></p>' . $this->grid_adv(array('topic_id'=>3))); //тут вместо 3 поставьте идешку нужного вам раздела $this->template->assert('main_page_view', 1); $work_subcontroller = 'home'; }else{ $this->template->assert('main', '<p><br></p>' . $this->grid_adv()); } } Должно получиться, но пейджер, который выводится ниже объяв на главной учтет этот параметр и переход на страницу 2 произойдет с учетом указанной вами идешки.

В принципе можно и самостоятельно. Там суть только в том что бы правильные параметры формы в полях проставить и передать на адрес прижения. Само приложение с последних версий умеет обрабатывать ряд переменных запроса - city_id, district_id и еще несколько. Я сегодня ночью подниму файлі и напишу подробнее.

я добавил вам отступ сверху и обертку.

Это должен быть отдельный поиск. Если вы хотите, что бы выбрав на этой форме район вы получили в выдаче квартиры в этом районе смешанные с ЖК в этом районе, то так не выйдет. Сборщик ищет данные только по одному типу объектов. Поиск ЖК нужно выделить в отдельную форму. Я сначала думал может паровозом прицепить к поиску квартир поиск по ЖК по данным параметрам, но там возникает слишком много вопросов при постраничке, так что это не вариант.

Нет в интернете милиметров.))) Есть пиксели. Оберните весь ваш текст в блок <div style="margin-top: 5px;"> ТУТ ВАШ ТЕКСТ ВЕСЬ </div> margin-top: 5px; указывает на сколько пикселей отодвинуть вниз блок. меняйте и подбирайте подходящее значение.

Меню в главной навигации - это для того, что нужно поставить ПОСЛЕ топиков в навигашке Меню перед главной навигацией - это для того, что нужно поставить ПЕРЕД топиками в навигашке

а вот он впереди. в принципе я могу сделать и второе меню, которое будет ставиться ПЕРЕД топиками в отличии от того первого, что идет в хвост.

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

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