abushyk

Фраза permission denied на скрине говорит, что все не так радужно. Права на каталог - это одно. А права на файлы в каталоге - это отдельная песня. Вы мучали footer.tpl. Смотрите, что стоит именно на этом файле. Если все ок, тогда гоу вверх по дереву проверяя каждый каталог.

Нет. У вас нет прав на запись для папки шаблона. тплєдитор - єто только инструмент, а реально через него вы правите файлы в /template/frontend/ваш_шаблон/

Нет прав на запись в папке шаблона. А вы как раз пытаетесь перезаписывать файлы из его папки.

1. /template/frontend/agency/css/style.css - тут подобрать класс, который свойственен спецпредложению и добавить в него стилизацию в виде линии обводки. А сами спец выводятся в right_special.tpl, верно. 2. у агенси нет "цветовых гамм". Можно просто менять стили и создавать свой вариант расцветки.

1. Поиск по комнатности в данных осуществляется по полю room_count, которое должно содержать чисельное значение. 2. Расположение объявления в разделе типа Квартиры - 1-комн. никаким боком не влияет на поиск по комнатности. Кроме случаев. когда на форме поиска выбран раздел "Квартиры - 1-комн." 3. Результат поиска по комнатам зависит от того, как передано количество комнат в запросе. Если передано в виде переменой room_count=N, то поиск будет оуществляться именно по совпадению с N Если передан массив room_count[]=N1&room_count[]=N2&room_count[]=N3, то поиск комбинируется из всех этих условий через ИЛИ (если N принимает значения от 1 до 3, то поиск дополняется условие по совпадению данных с 1-3. Если передано 4, дополняется условием "комнатность >3")

Если пропал дизайн, значит в новых правилах скорее всего пропустили отменяющие условия RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dи реврайтер отправляет запросы вообще ко всему на index.php вместо того, что бы отправлять на соотв. статический файл.

district: linked = street_id,district_id depended = city_id;settlement_id Вот с таким я бы был поосторожнее только. Зависимость от более чем одного элемента может порождать артефакты на форме при даже легкой нестыковке. При прямом выборе на форме зависимости отработаю нормально, так как при выборе они учитываются через linked-параметр, для которого ниспадающие зависимости могут ветвится. А вот при вытягивании данных из БД и генерировании формы с выбранными значениями уже работает depended-параметр. И что он там решит выдать в поле district при уже выбранных двух city_id и settlement_id - загадка.

ПС. С фото должен быть подход иной. Автор должен понимать, что фотки - это плюс в карму. Ища жилье многие просто даже не смотрят объявки без картинок. Грубо говоря отсутствие любых данных о объекте, но наличие в нем картинок дает профит по сравненю с объектом у которого выписаны все параметры с офигительной детализацией, но нет картинки. Это нужно донести до пользователя. Ну и я бы "укорачивал" срок жизни объявлений без фоток. Минимальным скриптом проверял бы периодично количество фоток на объявках и при нулевом их содержании или малом (1-2) слал бы месседж. А если срок подачи такой объявки перевалил бы за N дней, то просто тер бы роботом.

Как-то одно другое взаимоисключает, не? Для uploads может быть применен параметр min_img_count со значением числа минимально необходимого количества фоток. По сути єто будет что-то типа рекьюред. Но любое насилие порождает противодействие, так что если "вам нужно что бы были фотки" будьте готовы к модерации этих нужных вам фоток. Ибо если я не хотел грузить фотки, а вы меня заставляете - я навалю вам в картинки первое что найду на ПК, лишь бы обойти требование обязательность - т.е. котики, собачки, цветочки. В итоге мы придем к ситуации, которая была и до этого - в каком-то проценте случаев фоток по факту не будет.

Да. Хотя эта функция уже практически не используется.

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

Щас угадаю.))) Вставили как {$data.id.value} а не {/literal}{$data.id.value}{literal}

Только не говрите, что вы вот так с PAGE_ID и вставили)))) Вместо этой метки нужно было поставить что-то уникальное. Например мы выводим виджет на странице объекта, тогда туда ставим {$data.id.value}. В итоге в каждой карточке у нас получится уникИД в виде идешки объекта. Правда я хз что делать, если понадобится поставить комменты например еще и на странице раздела. Ну кроме колдовских вариантов.

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

А что сделать ЭТО? ))))

Есть еще css-хак, но я не уверен в его кроссбраузерности. Для элемента-вместилища применяется стиль max-width: 100px;white-space: nowrap;overflow: hidden;text-overflow: ellipsis;Тогда он формирует вместилище до указанной ширины, а после нее начинает обрезать внутренний текст примерно вот так Или можно сделать изменение файла /template/frontend/freehold/user_menu.tpl где строку {$fio} изменить на {$fio|truncate:100} которая не даст имени пользователя вывестись более 100 знаков.

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

/apps/admin/admin/template1/data_form.tpl

Не просто спутники, а вообще все города. Тгда в иерархии они станут на одном уровне с метро и вместе с ними пудут дочерними к тому, что стоит в поле Город. И выбирать их можно будет вместе. ПС. Но это решение чисто ради метро. Я не говорю, что это хорошо отразится на выгрузках.

Спасибо, что нашли)))) А я два месяца ломаю голову почему на сайте, где на форме десяток текстареа тупит форма))) История такова. Когда формируется текстареа с эдитором, то сначала создается обычная текстареа с идешкой, а потом по этой идешке цепляется скриптом эдитор. Изначально под идешку я выбрал таймштамп времени создания поля, но на резвых хостах они содавались практически в один момент и получалось что у всех полей одна идешка и редактор цепляется только к первой. Вот я и затормозил процесс искусственно)) А теперь смотрю, что и в идешку соль добавил, а sleep не убрал.

Был такой случай. Но там была МСК+Подмосковье. Если не ошибаюсь, мы или просто отвязали метро от города и сделали его сквозным или опустили города на уровень районов города, а в поле города разместили глобальный субрегион - Москва и окрестности, к которому и привязали метро.

Метод VK.Widgets.Comments принимает три параметра. .... page_id Идентификатор страницы на Вашем сайте. Произвольное число. Используется в том случае, если у одной и той же статьи может быть несколько адресов, а также на динамических сайтах, у которых меняется только хеш. Значение по умолчанию равно контрольной сумме от location.href. VK.Widgets.Comments("vk_comments", {limit: 10, width: "576", attach: "*"}, PAGE_ID);

Самое первое и самое главное. Есть два типа поля под картинки. Точнее три. 1. photo - это поле-исключение. Оно используется только в профиле юзера под хранение аватарки. Только объект юзера может это поле обработать. Вставлять его в модели других объектов просто не имеет смысла. 2. uploadify_image - это такая округлая серовато-черная кнопка с надписью фото. Самое старое поле под картинки в истории сатбилля. Это поле ссылочное. Т.е. реально оно хранит картинки, но не прямо с данными объекта к которому привязано, а в отдельной таблице, связь которой с объектом, к которому привязано фото, образуется через ключ. Ключевое словосочетание в предыдущем предложении в отдельной таблице. Т.е. просто добавить поле uploadify_image в модель мало, нужно еще пойти в БД, создать таблицу и указать связки между ней и объектом в настройках поля картинки. Есть у этого поля еще одно ограничение - оно может быть только одно на объект, нельзя создать два поля такого типа например в модели объявления или заявки. Точнее создать можно, но все картинки будут идти все-равно в первое из них. В общем для определенных случаев поле очень хорошее, но для быстрой набивки картинок не фонтан. 3. uploads - это такая серая прямоугольная область на форме куда можно высыпать фотки тягая их мышкой или, кликая в него, вызывать окошко добавления фоток. Прелесть поля в том, что а) их может быть много на один объект - планировки, фотки квартиры, портреты жильцов, сканы документов бти... в общем пока база данных не скажет стоп. б) оно хранит данные о фотках сразу с объектом в отдельном поле - никаких доптаблиц или настроек в принципе для бытового использования не нужно. Теперь вернемся к вашим формам. На ней явно поле типа uploadify_image, фотки оно пытается принять, даже принимает, ищет табличку куда бы уложить, не помню точно какие настройки оно будет использовать, если таблицы не найдет, но подозреваю, что фотки просто сбросит. Подозреваю, что про дополнительную таблицу для такого поля вы услышали сейчас впервые и соотв. таблицы скорее всего нет. Попробуйте создать новое поле под картинки в заявке, но уже с типом uploads. Назовите его как-то иначе, а старое поле погасите. Можно изменить тип старого поля, но тогда прийдется обновить таблицу, таккак старое поле не подразумевало физической колонки под себя, а новое ее требует. Далее. Что бы сработал метод Дмитрия, обращение к заявке должно идти через приложение Клиенты, т.е. /client/order/ipoteka Если вы пытаетесь прогнать заявку напрямую, через ipotekaorder, то стандартный модуль никогда не сохранял свои данные, а просто перенаправлял их в упакованном виде в приложение Клиенты и отправлял на почту. Напрямую через это приложение-модуль сохранить фотки не выйдет, потому что у него вообще от слова совсем нет никакого хранилища, куда бы он мог положить свой объект, а следовательно и не к чему привязать картинки. Именно поэтому он и показывал как создается "справочник пользовательских объектов", который как раз и является тем самым хранилищем.

Это ящик Пандорры. Проверка, так сказать, на баланс любопытства и взвешенности)) Это техинструмент для всяких внутренних операций. Бытовому пользователю он не нужен по причине отсутствия у него дружественного интерфейса. В общем начинал я его делать для людей. но в результате опять получилось как для себя. Ну и я бы не тыкал там ничего без полного резервного копирования сайта))) Из Uploadify в Uploads - это механизм переливки фоток из поля типа uploadify_image в uploads. Это два разных механизма хранения медиа-файлов и поэтому потребовалась оболочка для автоматизации этого процесса. Как показал опыт - редковостребовано, поскольку люди быстро привыкают к тому, что есть, и если оно не сильно скрипит, не настроены ничего менять. Ну и у каждого из этих способов есть свои плюсы и минусы, поэтому сориентировавшись на их баланс скачка между типами элементов же не нужна Подгонка превьюшек - механизм подрезки превью по новому размеру. Например у вас были превью 200х100, а вы изменили дизайн и теперь вам нужно 100х100.Ставить новый размер и перезаливать кучи картинок не всегда удобно, поэтому эта штука берет ваши большие картинки и делает из них превью уже по новому размеру. Операция трудоемкая. На больших количествах картинок потребутся мощный хостинг и довольно большой лимит оперативы и времени исполнения. В основном может использоваться при отладке шаблона. Напрмер сделали фотки, посмотрели дизайн - фигня, перекроили, под дизайн зарезали превьюшки, опять посмотрели. И так пока результат не будет ок. После этого настройки оставляются в покое, тестовые объявки идут в топку и пошла обычная загрузка. (по крайней мере я так делаю, поскольку одновременно приходится пользоваться несколькими шаблонами, а держать пачки тестовых данных, включая картинки для них не всегда удобно.)

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