abushyk

phpMyAdmin, таблица apps, выполнить операцию Очистка. Открываете в майадмине список таблиц вашей БД. напротив каждой таблицы есть куча кнопок.Ищете напротив таблицы re_apps кнопочку мусорного бака и тултипом Очистить (не крестик и удалить). Если был включен режим кеширования приложений, то они позаписывали туда свои абсолютные пути. А если вы переложили сайт в другую папку, а не просто залинковали субдомен на старое место, то реальные пути изменились, а из кеша он читает еще старые и пребывает в непонятке.

100%. Это были танцы на костях приложения Статичные страницы с целью пришить им третью руку) Блог - просто выдавал список страниц из списка, нечто вроде микрозамены для Статьи. А Реккомендейшнс - это кажется был вариант выдать их по некоторому типу.

1. Проверьте в редакторе форм создана ли там модель с именем ipoteka 2. Напишите мне в приват с доступами по фтп к сайту.

Напишите мне в приват доступы в админку. Еще проверьте вот что - откройте объект на фронте и в админке. Выполните поворот в админке и обновите страницу на фронте через контрол+ф5, что бы удостовериться, что фото реально не повернулось. Бывает, что работает кеширование статических материалов на сервере и поворот не отображается потому что основные параметры картинки не изменились.

В любую форму, которая в Редакторе форм имеет физическое представление в виде таблицы (в Редакторе форм возле в строке с именем модели нет кнопки "Создать таблицу"), можно добавить поле типа uploads и использовать его для присоединения графических материалов. Для заявок на аренду - это модель data_get_rent и она обычно имеет физическую таблицу под себя. Обязательно задавайте максимальный размер на фотку для полей на таких формах. И по-меньше делайте его. Но есть другая проблема. Uploads не корректно работают, когда на странице более одной формы с элементом добавления графики. Поэтому если разместить такое поле в форме Напишите нам в подвале той же реалии, то будут проблемы со всеми полями на всех формах, которые выводятся в страницу, так как на всех страницах будет эта форма Напишите нам. За эту проблему я знаю уже давно, но пока предложитьиного варианта, кроме того, что бы следить, что бы соблюдался принцип "одна страница - одна форма" не могу.

/usr/bin/wget - это расположения исполняемого модуля который выполняет функцию запроса адреса "как будто-то кто-то в браузере смотрит этот адрес" (грубо говоря). Т.е. тут сервер не запускает непосредственно какой-то скрипт на сервере, а просто запрашивает страницу и сервер, отдающий эту страницу, выдает ее, выполняя все действия, которые бы он выполнил, если бы вы просто в браузере запросили эту страницу.

Настройки - Общее - Версия Bootstrap. Посмотрите указано ли там что-либо. Если не указано или указано не число 3, то поставьте его.

Найдите файл /apps/system/js/dropzone/dropzone.css в нем 518-522 строку замените на background-position: 0 -123px; height: 174px; width: 100% !important; margin-left: auto !important; margin-top: -40px !important; font-size: 14px; line-height: 22px;

Нет, форм не нужно. Нужно просто разместить дубликат стилей в файле стилей шаблона и переопределить в нем по своему. Например если исходный стиль .dropzone_inner .dz-default.dz-message { background-image: none; font-size: 24px; text-align: center; line-height: 32px; left: 0; width: 100%; margin-left: auto; } а мы хотим уменьшить шрифт и добавить цвет, то в стили шаблона добавляем .dropzone_inner .dz-default.dz-message { font-size: 10px; color: Red } и, если вдруг стили шаблона загрузятся ранее стилей исходных, то поменять на .dropzone_inner .dz-default.dz-message { font-size: 10px !important; color: Red !important; } т.е. вы тянете нужный класс и в нем переопределяете тоько нужные вам своства.

Эти стили применяются на всех элементах такого типа - uploads и docuploads. И только на них. Но вы можете разместить эти классы в файле стилей своего шаблона и там их поменять. Тогда эти изменения коснутся только фронтальной части, но не затронут админку.

protected function exDescription($data_item) { $data_item['text'].=' ТУТ ВАШ ХВОСТ'; return parent::exDescription($data_item); } во такую функцию определите в local_site.php внутри блока class local_yandexrealty_site extends yandexrealty_site { }. И хвост добавится и лишних локализаций будет меньше.

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

Карточка у вас стандартная или свой вариант в папке шаблона? ПС. Нашел в чем проблема.

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

Но так как все включали, то стало как бы можно. В каком месте или по какому действию? Для этой опции так же необходимо иметь в модели объекта поле с системным именем archived типа checkbox с доступом только для админа.

Да, все верно. Внутри if($data_item['__property_supertype']=='room' || $data_item['__property_supertype']=='flat'){ } идет HouseType и значение "Кирпичный", а внутри следующего далее if($data_item['__property_supertype']=='houses'){ } уже WallsType и "Кирпич"

хм. у меня в репозитории последняя 0.1.4 но с 0.0.8 по логам в ней уже для WallsType Кирпич, а для HouseType - Кирпичный. Есть еще один вариант, почему может не срабатывать. Порядок обработки такой: 1. Проверяется заполнено ли Материал дома. Глобальное значение. Если оно указано, то для всех объектов ставится значение материала оттуда и дальше все игнорится. 2.Если с глобальным значением не сложилось, то проверяются все заданные условия для конкретных материалов. первый, у кого будет найдено совпадение, будет отдан как определенные (проверка идет по ключевым значениям для полей выбора. для select_box с вариантами {a~~b} проверка будет делаться именно по а). Судя по скринам, там настройки были прописаны в нижнем регистре "кирпичный", а в значения вариантов полей уже были изменены на "Кирпичный". Т.е. ни одно условие по материалу не перехватывалось (еще один привет числовым ключам в select_box ))) ) 3. если все еще совпадений не нашлось, то в дело вступает настройка Материал дома. Системное имя поля со значениями - в ней указывается системное имя поля которое содержит avito-style значения материалов. т.е. иными словами это должны быть поля у которых в виде значений присутствуют полные аналоги вариантов от авито. 4. Если же предыдущие 3 пункта не сработали на конкретном объекте, то проверяется есть ли что написано в настройке Материал дома. Остаточное значение и, если есть, то это идет в материал. Это как раз настройка на случай "что бы не было пусто". Что-то мне подсказывает, что проблема могла\может возникать на 3-м этапе. Когда по материалам сравнение не прошло, а в Материал дома. Системное имя поля со значениями указано имя поля с материалами, только они ни разу ни авито-style.

Но! Это касается только вывода ссылок. Запросы по ссылкам что со слешем, что без слеша, обрабатываются одинаково. Поэтому даже если у вас все ссылки будут выведены со слешем, но я изменю адрес ссылки убрав слеш и перейду по ней, система все равно даст ответ. И вот для этого вам и будет нужен редирект - именно что бы свернуть возможные "не те" ссылки на "те".

Большая часть ссылок в коде создается системой. В зависимости от настройки СЕО-оптимизация - Не использовать концевые слеши (по умолчанию слеши добавляются) адреса будут снабжаться концевым слешем или нет. Слеш не будет добавляться под файлоподобные адреса, например которые заканчиваются на .html. Это не касается ссылок, создаваемых в шаблонах - там они прописываются и код к ним доступа не имеет. Меню реалии, несмотря на то, что это код, так же локализовано и не имеет прямого отношения к системе, поэтому там простейшим решением будет проставить слеши руками. Аналогичная манипуляция может потребоваться в файле user_menu.tpl - там тоже много ссылок не из кода, но в принципе контент этого файла может быть вообще завернут в ноундекс так как для роботов в нем нет ничего интересного. В списках, если это не совсем древние шаблоны, адреса ссылок на объекты уже идут из системы и должны формироваться с учетом настроки "использовать слеши". В списках объектов ЖК для реалии и ряда других шаблонов может нарушаться правило про слеши - ранние версии имели почти каждая свой модуль ЖК в котором может содержаться код сборки объектов и, соотвественно, формирования для них ссылок еще по старому варианту, без учета слешей. В таком случае спишитесь со мной в пм и я посмотрю.

А какая версия у модуля выгрузки в Авито сейчас текущая доступна с обновлений? До версии 0.0.8 там точно была ошибка в написании значения WallsType - вместо "Кирпич" было "Кирпичный" как для материала домов. Но ее я исправил еще в начале ноября.

1. Смотрим есть ли в нашем шаблоне файл \template\frontend\ШАБЛОН\apps\complex\language\ru\dictionary.ini 2. Если нет, то копируем из \apps\complex\language\ru\dictionary.ini этот файл по указанному выше пути и очищаем его (тот который скопировали в шаблон). 3. Если файл есть в шаблоне, то не очищаем 4. Открываем файл \template\frontend\ШАБЛОН\apps\complex\language\ru\dictionary.ini и добавлем в него новую строку в конце APP_BC_TITLE="Своя строка для вывода в хлебных крошках" 5. Сохраняем изменения.

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

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

Только не перед, а после {$estate_folder}. <a href="{$estate_folder}/...

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