abushyk

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

Но шаг в ползунке поменять можно, высчитываются только крание значения, а шаг = 1 как самый универсальный. Для реалии в /template/frontend/realia/js/search_form.js есть два запуска ползунков вида simple_slider.slider({ step: 50000, /*єто нужно добавить*/ range: true, ..... и extended_slider.slider({ step: 50000, /*єто нужно добавить*/ range: true, ..... ширина шага на ваше рзумение. Но если даже диапазон цен станет меньшим чем есть, шаг останется таким же.

карточка только показывает эти ссылки. но кто-то их должен перехватить вне карточки и показать наборы по параметрам этих ссылок. Все это уже есть в лобовом решении через Линк-Менеджер. Крафтим ссылки вида (city_alias+topic_alias), пакуем их в линк-менеджер, параметризуем парами city_id=N&topic_id=M, вешаем тексты, идем пить пиво.

если быть честным до конца, то ответ на этот вопрос должен давать тот, кто заказывает такие крошки))) крошки не должны быть (не обязаны быть) как солдаты все одного роста и в сапогах. суть крощек в том, что бы их целевой страницы дать быстрый достыуп "наверх" к релевантным страницам. другими словами в карточке это может быть Италия\Сицилия\Квартиры на Сицилии\Квартиры в Палермо\студии в Палермо а в странице условно "Квартиры в Палермо" это уже может иметь вид Италия\Вся недвижимость на Сицилии\Жилая недвижимость на Сицилии Крошки это не только и не столько путеуказатель, но еще и дополнительная перелинковка для разброса веса.

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

прописать куда?

Я загнался. Нужно без звездочек. .zip,.mdb,.pdf

у меня тоже. видимо что-то я за сильно ограничил.

Так точно. Меняются только модификатор перед одной сигнатурой и тип параметра приводится в соотвествие с родительской во второй. Второе в принципе не страшно, если игнорить strickt-сообщения.

Хотя вот теперь уже не уверен. Лучше пока создавайте, а я потом проверю, нет ли там условия не сохранять без наличия обработчика.

Админка - Редактор форм Дальше как для любого элемента модели выбираем нужный докаплоадс, например в data, и жмем кнопку Редактировать. В длинной форме, где указываем тип эелемента, имя для человеков, хранить ли в БД, в раделе Параметры добавляем новую пару инпутов и вписываем в левый инпут accepted а в правую список дозволенных расширений в указанном формате.

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

констатирую факт, что стоит заменить.

Редактор форм. Откріваем нужный докаплоадс элемент на реактирование. В секции Параметры добавляем параметр accepted и указываем допустимые значения в виде *.zip,*.mdb,*.pdf Данные расширения заменят собой стандартные. Т.е. то, что укажете, то и будет принимать.

и опять все упирается в то, что будет подразумеваться под пунктом раздела (или того, что записано в Структура). Ведь его можно мыслить как тип недвиги (квартира, дом, участок), а можно как рубрику (продажа квартир, элитная недвига, учатки в аренду). И первое значительно уже чем второе, что более гибко, так как "простые" типы я могу смешивать с другими свойствами и получать диковинных зверей - напр. тип "квартира" + количество комнат=3 получается трехкомнатные квартиры. Прибавив к этому признак контракта я получу продажу\аренду трешек. А смешав тот же тип и галочку у моря у меня будет "квартиры у моря". А вот комбинирование типа "продажа квартир" уже меня ограничивает именно "продажей". В идеале каждое свойство должно быть максимально однозначным. Тогда с ним проще управляться. Но все зависит от конкретных условий и требований.

Для тех, кто читает. Admin: - в списке объектов autocomplet-поиск сведен в единую функцию - скорректированы отдельные интерфейсные элементы и стили - Добавлена опция генерации PDF - Добавлен грид для генерации универсальной таблицы на основе модели - подкорректирован интерфейсный функционал Afyexporter: - добавлена возможность указывать список полей, содержащих графические материалы. Например ял выгрузки в секцию картинок фотографий объекта и его планировок, если они расположенны в отдельных полях. Avitoexporter: - для продажи добавлена настройка признака прав собственности - добавлен вывод номера дома в адрес - добавлено параметризирование размерностей полей метража Banner: - убраны старые функции Billing: - добавлены настройки, позволяющие установить срок выделения, ВИП или выделенного статуса для пакетных использований, вместо стандартного срока в 30 дней. - для невалидных значений периода для пакетных опций вип, премиум и выделено всегда возвращается месячный срок - исправлена ошибка в распознавании сервисов приобретенных пакетных статусов в рамках тарифа - Добавляем недостающие поля в таблицу bill Cianexporter: - добавлен вывод срока предоплаты для аренды (prepay-term) для Нежилой - установлено правило вывода параметров расстояния до метро пешком и транспортом в режим вывода одного. Значение расстояния до метро транспортом будет выведено, если оно указано и если не указано расстояние до метро пешком. Client: - для формирования информации о заявке в приложении используются данные из БД о сохраненной заявке, для получения возможности присоединять к информации о заявке графические и документальные материалы. - добавлено сохранение ID заявки в данные клиентских заявок Complex: - добавление поля активности в модель ЖК - испралена ошибка в регулрно выражении поиска по имени - добавлены настройки для полей формы поиска - добавлена возможность вывода приложения на главную страницу - добавлена возможность подсчеа количества просмотров (требует наличия в модели поля view_count) - исправлены базовые шаблоны - добавлена настройка убирающая заголовок из шаблона приложения для избежания дублирования заголовков - добавлены языковые переменные - добавлен шаблон формы поиска и механизм обработки поиска по данным ЖК с поддержкой полей - city_id, district_id, metro_id, room_count_N, price_min, price_max, square_min, square_max, floor_count, build_year, ready_quarter - облагорожен базовый шаблон - добавлен шаблон вывода внутренних объектов ЖК Config: - добавлена настройка подключения "классического" локального грида (расположенного по определенному месту) - добавлена настройка под указание дефолтного часового пояса - добавлена настройка позволяющая указать группу гостей-анонимов для присовения им правил видимости элементов модели по группам - добавлены настройки максимального количества неправильных авторизаций и времени заморозки аккаунта Customentity: - создание модели пользовательской сущности с учетом прав видимости по группам и активности Developer: - добавлен признак активности к Застройщик иобработка признака - добавлены опции включения списков ЖК в страницу просмотра Застройщика и в страницу списка застройщика - добавлены языковые метки Excel: - добавлена очистка недекодируемого символа _x000D_ - Вывод лога после парсинга - добавлена фильтрация выгрузки по complex_id - исправлен путь подключения PHPExcel - geo теперь доступно для редактирования из excel ExcelCompany: - исправлен путь подключения PHPExcel ExcelFree: - добавлена очистка недекодируемого символа _x000D_ - исправлен путь подключения PHPExcel Geodata: - добавлена настройка выключения зума по скролу на карте указания позиции. пи выключенной настройке карта зумится на десктопах свыше 800px и не зумится на меньших экранах - исправлено неправильное позиционирование карты - добавлена возможность для карты в форме функционировать в среде YandexMap версии больше 2. Критично для шаблонов использующих старщие версии в фронтальной части. - Добавлен параметр кэш карты Interkassa: - алгоритм формирования кнопки оплаты учитывает только ID счета и вспомогательные данные выбирает сам игнорируя переданные Kvadroom: - добавлены настроечные поля позволяющие указать истоника данных площадей участков и их размерность - лог выгрузки перемещен из папки приложения в папке cache Language: - системные языковые переменные - исправлена логика сохранения переводов для избежания вырезания тегов из переведенных меток - добавлены новые словарные метки Mailbox: - добавлена возможность локализировать письмо-уведомление о новой заявке на сайте Mapviewer: - добавлены настройки исходного масштаба карты, переключения в упрощенный режим и передачи разметки с данными на карту, для вывода побочного списка. - скорректирован алгоритм вывода на карту - почищены базовые шаблоны приложения MemoryList: - исправлен путь подключения PHPExcel - Добавил вывод списка сохраненных - memorylist - вспомогательное приложение для формирования списков для пользователей. Menu: - исправлен алгоритм формирования ссылок с учетом заверщающего слеша - Сделал вывод грида элементов меню в порядке сортировки. Mestoexporter: - подвключены правильные словари My_Banners: - хранение промежуточных состояний для приложения перенесено из сессии в куки Mysearch: - Убрал устаревшую кнопку run Newsparser_rbc: - исправлен путь подключения сторонней бибилиотеки Prian_Exporter: - добавлена настройка позволяющая указать фильтрующее поле типа checkbox для отбора в выгрузку Predefinedlinks: - добавлена обработка концевых слешей при редиректе с разнорегистрового алиаса и в сайтмап - добавлен функционал под ajax-список. Reviewer: - добавлены переводы и языковые переменные Seo: - добавлены настройки для глушения географических адресов - добавлена настройка управляющая установкой концевого слеша в автоурлах - добавлена настройка изменющая алиасную часть ссылки объявления вместо стандартной realty - скорректирована функция автопростановки алиасов объектов - Добавил опции для загрузки информации о городе, регионе, стране в карточку объекта (вся модель как есть) Sitemap: - Добавлена генерация city System: - включено использование настройки часового пояса - для полей типа uploads и docuploads отключена принудительная очистка загруженных файлов при возрате формы из-за ошибки заполнения данных - добавлены языковые переменные - чистка неиспользуемого функционала - правки связанные с переводами и использование Accessor - для списокв объектов в админке едусмотрена обработка ситуации вывода списка с колонками, которые уже удалены из модели - в Table_View вывод медиа в виде ссылок на объекты на сервере - Добавлена иконка для генерации PDF - Убрал из метода удаления проверку прав доступа (теперь проверкой должен заниматься конкретный вызывающий класс) - Перенес метод удаления - Перенес включение проверки permission в grid - добавлены языковые переменные - убран лишний функционал из tag_manager - в модели исправлен алгоритм проверки правильности выбора для автокомплит-полей в режиме мультиязычности - добавлена точка входа для ajax-операций приложений с целью избавиться от файлов ajax.php в приложениях - исправлена ошибка при удалении изображений - исправлена ошибка в рассчете уже загруженных изображений на uploas-полях с ограничением по количеству - для авторизации условие проверки по login или email поставлено в зависимость от настройки login_by_email - при регистрации при включенной настройке login_by_email поле login будет обрабатываться "по наличию". При присутсвии такоового, в данном режиме, и будучи пустым, будет проинициализировано e-mail. Так же все проверки этого поля будут проводиться при его наличии в модели. - table_view расширен на обработку полей типа docuploads для использования в заявках - исправлены системные языковые метки - измен формат сообщения о незаполненном поле для правильного отображения в разных языках - исправлена ошибка поиска по тегам в списке объявлений в админке - исправлена работа транслитератора для избежания формирования строк с несколькими дефисами подряд - добавлена возможность настройки количества неправильно введенных логинов при авторизации и времени заморозки аккаунта - добавлены login и email в выбираемые данные пользователя при авторизации - кэшируем карту - создаем таблицу cache при обновлении - возвращено функциональное меню в приложениях в админке - заблокирован вызов построителя сетки в админке для приложений без установленого $this->table_name - скорректирована логика работы с полем user_id в админке при расшаренном доступе - исправленя работа геокодера в карточке при просмотре объекта - заблокирован доступ к полю email при использовании опции email_as_login в модуле профиля пользователя - Установка контролов (в том числе memorylist) - Добавил функции с возможностью подключения списков сохранения пользовательских выборок. - Догружаем дополнительные данные из страны, региона, города по требованию Table: - добавлена поддержка настройки группы Гости при инициализации модели Tlocaion: - в выборке данных для автокомплит-поля улицы добавлен учет текущего языка. Twitter: - исправлен путь подключения tmhOAuth библиотеки - При наличии ошибки выводим сообщение об ошибке Upper: - исправлена система логгирования использованных апов. Из логгирования исключены пакетные апы, которые могли занижать число бесплатных. Userdata: - Скрипт для создания вспомогательных таблиц Watermark: - добавлены языковые папки Yandexrealty: - выгружаемые названия типов коммерческой недвижимости изменены на англоязычные - исправлены ошибки в переменных - расширены возможности для поля deal-status - использование поля типа select_box - добавлен вывод площади участка для Коммерческая - участки - добавлено игнорирование ошибки при выгрузке без обязательного параметра deal-status - возвращено функциональное меню приложения - добавлены ассоциации коммерческих типов - добавлены поля под указание истоников площадей земли - параметр deal-status сделан обязательным согласно спецификации Yandexrealty Parser: - добавлена возможность загружать географию связанно - Установка лимита количества объявлений для парсинга картинок за цикл Добавил опцию поиска названия ЖК в описании

так делать допустимо. других вариантов и нет.

Последние два ворнинга возникают из за предпоследних двух. в том же файле локального гриддера protected function prepareRequestParams($params, $premium){ ===> protected function prepareRequestParams($params, $premium=false){

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

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

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

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

Я тоже не отмахиваюсь)) я просто пытаюсь объяснить, что настраничное представление данных настолько субъективно, что редко когда удается нарисовать какой-то универсальный вариант. тем более, что заранее шаблон в принципе даже не знает какие поля могут быть в модели, не говоря уже об их текущем смысловом наполнении. Поэтому в шаблонах исходно размешаются некие полуабстрактные заготовки или полуидеи, которые обычно нуждаются в корректировке согласно смыла сайта, но в целом могут являться базисом. Либо можно как в КПСС, я четко говорю какие поля вы можете иметь и как они должны называться и какой смысл они будут иметь и реализовую их поддержку в шаблонах. Но это тоже плохой вариант, так как ни разу не гибкий и все завязывается на третьего человека, т.е. меня или Диму)))

Это вообще не вариант, так как одну улицу можно привязать только к одному району.

/template/frontend/estetico/standart_search_form.tpl строка <div id="extended_search"{if !isset($smarty.request.extended_search)} style="display:none;"{/if}> уберите в ней красное условие и так же можно убрать ниже сворачивалко-разворачивалку <a class="search_page_toggle advanced-search" href="#">{$L_ADVSEARCH}</a> так как форма уже будет развернута