abushyk

{elseif $data_item.name eq "CDRNAME" && $smarty.session.user_id!=ADMIN_ID && $data_shared.user_id.value!=$smarty.session.user_id} где вместо ADMIN_ID прописать числовое ID пользователя-админа.

Изначально я делаю выгрузку только под обязательные поля для формата. Т.е. если ЯН-формат требует квартиру, то выгружаете ли вы на сайт, который принимает и не показывает, или на сайт, которые принимает и не показывает, если в формате написано must have, значит в выгрузку оно пойдет. Это следует четко помнить - набор и обязательность полей регламентируется форматом, а не тем, куда вы данные в этом формате тулите. Потом, по "требованию трудящихся" я могу добавлять больше полей, которые не есть обязательными. Зачастую в выгрузках вы сами указываете источник данных в виде системных имен полей либо условий. Так что там, где это допустимо и значение не является обязательным, вы можете не указывать поле-источник. Если же вы хотите варьировать одну и ту же выгрузку в разных видах, т.е. кому-то отдавать номер квартиры в ЯН-формате, а кому-то фигу с маком - то локализация кода выгрузки и погроммирование.

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

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

Перед строчкой {elseif $data_item.type eq "price"} добавьте {elseif $data_item.name eq "CDRNAME" && $data_shared.user_id.value!=$smarty.session.user_id} и поменяйте CDRNAME на системное имя поля с кадастровым номером.

Только сокрытием в шаблоне карточки. И еще списка, если этот номер выводится в данных в списке объектов. Что бы показать как это сделать в карточке, мне нужен код шаблона карточки.

Этот вариант ЛК "с окошками" не отрабатывает параметры "обычного ЛК". Для этого у него и есть окошки, что бы набивать параметры. Так что запустить адрес с active=notactive в нем не пройдет.

Я бы сказал да)

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

только тут символы следует читать как байты. А один символ в utf-8 - это 2 байта. Так что реально символов будет вполовину меньше. Это мелочь, но часто ставит в ступор))

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

У вас список объектов в ЛК типа как в админке с этими окошками поиска в шапке?

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

ответа на что вы ждете?

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

реалии это не касается

Потому что до этой границы блоки, которые формируют сеточную структуру в бутсрапе - спан3 и спан9 еще располагаются рядом и имеют определенную численную ширину. Ниже этого размера эти блоки принимают процентную ширину в виде "100%" т.е. перестают иметь определенную ширину и начинают зависеть от экрана. С этого момента у нас и начинались проблему у фоторамы при рассчете ширины.

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

запустите браузер с выключенным javascript и посмотрите, появятся ли эти стили. если нет, значит какой-то плагин их применяет.

С помощью пользователя doma мы обнаружили, что при новых стилях наличествует схлопывание страницы, у которой очень мало контента (например адрес /account/data под гостем). Для ликвидации этого схлопывания предлагается обернуть новые стили меазапросом @media (max-width: 767px) { body #wrapper-outer #wrapper { display: block; height: auto; } body #wrapper-outer #wrapper #wrapper-inner { display: block; height: auto; } body #wrapper-outer #wrapper #footer-wrapper { display: block; height: auto; } } В итоге на микроэкранах мы получаем адекватную фотораму, а на десктопах, где фоторама у нас не уплывала, получаем нормальные "полупустые" страницы без схлопывания.

нет, страницы, как таковой нет.

В файл перевода шаблона разместите перемнную L_NEED_AUTH_WITH_LINK="Для доступа в этот раздел сайта вам необходимо <a href=%s>пройти авторизацию</a>" и измените ее текст внутрикавычек на свой вкус. Метка %s должна быть размещена в этом тексте и она при обработке будет заменена на ссылку на страницу авторизации (login) ПС. Файл перевода - это файл по пути /template/frontend/ваш_шаблон/language/код_языка/dictionary.ini Если такого нет, то пути и конечный файл нужно создать. Код языка - это одна из меток языков, которые вы задали в Редакторе переводов - ru, en, fr. Если языков несколько - идентичные файлы переводом должны располагаться в каждой соотвествующей папке. Если сайт моноязычен, то код_языка будет равен ru и файл перевода будет один.

Нет. Это в шаблоне так прописана логика, что она конфликтовала с некоторыми переменными в запросе, в частности со значением переменной order в виде date_added

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

поправил. дело не в кнопках, а в условиях в шаблоне было.