abushyk

Походу вы ошиблись с селекторами. Наставили всюду id, а в агенси там классы .t_i_photoи тд.

Берем /apps/admin/admin/template/realty_grid.tpl копируем в /template/frontend/шаблон/apps/admin/template/realty_grid.tpl В скопированном {$L_STREET} заменяем на Место Строчку <td width=13% class="row_title">Дом</td> убираем и убираем строчку <td>{$grid_items[i].number}</td>А в строке <td colspan="14"> 14 меняем на 13

На Предварительный просмотр отправляли? Можете заслать файл этот на abushyk собака gmail.com ?

Спишитесь со мной через скайп или аську. Контакты в профиле.

Тут нужно смотреть, что должно получиться в конце. У вас будет и дальше следить маска, а на странице вы хотите выводить форматированные номера?

1. Эта опция обуславливает количество похожих, а не их наличие. И нулевое значение значит не ноль штук, а просто неуказанное значение - например забыли выставить или просто нет в конфиге такой опции. Так что тут все правильно сработало - она не выключает. А отдельного выключателя нет. Можно просто убрать вывод похожих в шаблоне. 2. А если нажать F5 в ЛК? Такие глюки бывают, так как отдельные части страницы могут генерироваться немного ранее самой операции удаления. Т.е. сформировался или взялся из кеша блочек слева, а потом прошло удаление, а потом наступил вывод страницы. Т.е. объявления уже нет, но память о нем жива. И посмотрите не включено ли приложение Упарвление кешем.

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

Запустите поиск по форуму по template_search Если не найдете, я завтра напишу.

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

Настройки - WatermarkPrinter там селектбоксик с расположениями.

Тут именно вопрос в количествах. я сечас работаю над вариантом папочной раскладки. в данный момент по принципу 201502, 201503 - типа год+месяц. Возможно уточнить папки до дня, напр. 20150517, 20150518, но если парсинг активный и в день вы вгрузите 1000 объяв, то мы получим ту же ситуацию, только в профиль. У вас будет лям картинок не в папке /img/data, а в /img/data/20150517, что в принципе не изменит ситуацию.

Пока идет разговор об этом постараюсь почерпнуть полезной практической информации)))0 А сколько примерно картинок и с какой периодичностью заходит в папку при парсинге нельзя никак определить? Например парсим раз в 6 часов в среднем по 1000 объяв за заход. В итоге по ~20 картинок на объект. В итоге 4*1000*20 картинок в сутки.

1. Для указания подённой стоимости необходимо вести в модели объявления поле cost_per_day, которое будет содержать стоимость дня аренды. Это поле не конфигурируемо в данный момент, поэтому системное имя должно быть сохранено. 2. Учет занятых дат ведется следующим образом: клиент вытыкивает нужные даты, эти даты проверяются по базе среди наличествующих дат. Но не по всем, а по "проверенным". Каждый диапазон бронирования имеет признак "проверености" (is_validated) - обычно это чекбокс в данных брони, поэтому при проверке учитываются именно эти даты (что бы в случае ботоатаки вам не побронировали все даты и не сделали невозможным бронирование вообще). Так же и на календарик выводятся только "проверенные" даты. Именно поэтому сразу после бронирования ваши даты не будут отмечены в календаре, так как они исходно не "проверенные". 3. Учет заявок не резервирование происходит в самом приложении Резервации, в приложение Клиент, при наличии оного. Отправка письменных уведомлений управляется настройками (чекбоксы): 'apps.reservation.notify_admin_about_reservation_orders' - слать нотификацию админу 'apps.reservation.send_user_reservation_data' - уведомление тому, кто осуществил резервирование 4. Т.е. бронировщик подает заявку, заявка уведомляет админа, админ принимает решение бото-заявка это или нормальная. Соотвественно удаляет ее или связывается\дает указание связаться с клиентом+ставит отмтеку что is_validated, что бы она уже учитывалась в календаре и при выборе дат. Кажется ничего не пропустил. В самих резервациях не видит. Но видит в Клиент. Да. Это подтверждение физического создания заявки. Но так как система полуавтоматическая и связь с клиентом неизбежна, мы решили пойти именно этим путем, что бы клиент хоть примерно помнил где и что он нажимал. cost_per_day, там чуть выше описал. Только подёнка.

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

Нет или не создалась модель contactus. Либо она есть, но был изменен способ проверки существования модели приложением Клиент, который рисует форму внизу. А так как обновиться нельзя, то и применить актуальную проверку не получается. Можете временно погасить эту форму внизу. /template/frontend/realia/footer.tpl Строку ClientOrder.init_form('order_form1', 'contactus');предварить двумя слешами //ClientOrder.init_form('order_form1', 'contactus');Либо перед этим пройти на адрес сайт/contactus - произойдет прямое обращение к модулю и модель должна прописаться, если проблема именно в ее отсутствии.

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

Мне нужно увидеть код, что бы сказать что-то определенное. Контакты в профиле.

filter must have too.

Основной задачей меню является вывод пунктов Структуры. Оно умеет это от рождения. А дополнительные пункты вводить в себя мы его как раз научили. Вот это "Коммерческая недвижимость" - это и есть ваша структура. В данный момент она у вас состоит из единственного корневого пункта, вот он и выводится. А 'position'=>'behind\after' указывает именно куда относительно пунктов Структуры вставить ваши кастомные пункты.

Описание как работает приложения на данный момент (именно на данный, так как будет изменение): 1. В настройках приложения (Настройки - Сайтмап) устанавливаются параметрі периодичности и прочая техническая дребедень. Там же указываются наборы данных включаемые в сайтмап (страны, объявления, категории и проч). Некоторые приложения такие как ЖК и Застройщики могут уже включать в свои настройки пункты разрешающие их выгрузку в сайтмап (тут в зависимости от текущей версии). 2. Генерируется сайтмап. Генерирование происходит нажатием кнопки Генерировать в Приложения - Sitemap. В результате файл будет создан и вы получите ссылку на него. Данный сайтмап является техническим. Другими словами для роботов. Для человеков любят делать еще нормальный сайтмап - типа оглавления у книги.

Я так понимаю, теперь нужно дважды думать, что пишешь в код))

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

Что именно не получается?

Купить или снять квартиру идет в Админка - Приложения - Заявки на аренду

Может быть, что маска на поле и его тип mobilephone были применены не сразу, а после того, как часть пользователей была добавлена. Те, которые добавляли "до маски" имеют номера вида +7 (918) 367 66 67 (т.е. как ввели). Те, кто "после маски" имеют номера 79181885535 потому что маска определяет формат вводимого значения, а не хранимого, и все значения номеров приводятся к цифровому виду без скобочек-плюсиков-минусиков.