abushyk

пришлите в почту админку. интересно откуда берется это размер 150х525.

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

Они означают буквально следующее: - сделайте мне превьюшку к фотке в размере 710х525 при чем обрежьте мне картинку так, что бы не было белых полос ни сверху ни снизу, а большую картинку для просмотра сожмите что бы она по большему размеру не вылазила за 1000 пискселей. Превью может быть и меньше 710х525, но если вы сожмете окно браузера до менее чем 600 пикселей, то иконки станут колонкой и фото будет маловато для заполнения места, поэтому ее можно\нужно поставить максимально побольше. Это не фото такое получается. Это в разметке оно так показывается, поскольку область просмотра под него меньше самой фотки. Там нужно просто убрать ограничения .properties-grid .property .image img{ height: auto; width: 100%;} в /template/frontend/realia/css/realia-blue.css

О каком заказе речь? О добавлении объявления без регистрации?

Эти вкладки для деления полей только на форме добавления\изменения. Они не учитываются и не планировались учитываться при выводе в просмотр. Максимум, за что там можно зацепиться, это имя таба, но, если вдруг вы его переименуете, то вся логика отвалится. Можно менять автовывод в карточке с цикла {foreach from=$hvd_tabbed item=tab key=tabname} по всем табам, на прямой доступ {foreach from=$hvd_tabbed['Основное'] item=data_item} вывод элементов.... и так для каждого таба. Но это плохо.

Никак. Коэффициент применяется к обеим вариантам всех изображений. Возможно стоит будет подумать над этим.

Там устроена задержка загрузки карты, что бы она загружалась с оттяжкой и, из-за большого объема своих данных, не стопорила загрузку остального сайта. В megamap.tpl есть строка var time_offset=1000; которая ставит эту задержку в миллисекундах.

1. Улучшить никак. Только путем перезагрузки. Старые плохие фото не улучшатся ни от каких настроек. 2. Фото точно были загружены после выставления этих настроек с третьего скрина?

Зато классный кириллический домен))) Вообще-то это и есть нормальный адрес и вид домена такого типа. А не тот, что буковками русскими. ПС. И когда уже обанкротятся регистраторы кириллический доменов? )))) Как вариант http://www.etown.ru/s/topic/782-%D0%BF%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B5-%D1%81%D1%83%D1%89%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%B8-%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD/ но все зависит от того, что с этим делать дальше.

В тему http://wiki.sitebill.ru/index.php?title=%D0%9F%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%22RSS_%D0%BD%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B5%D0%B9_%D1%81%D0%B0%D0%B9%D1%82%D0%B0%22#.D0.9E.D0.BF.D0.B8.D1.81.D0.B0.D0.BD.D0.B8.D0.B5

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

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

Где-то близко, но не там. 1. Это сработает если картинки в uploads так кук у него физически есть колонка. Для uploadify_image пройдет мимо кассы с ошибкой скорее всего закончившись пустой выдачей, так как у этого типа поля нет физической колонки (но даже если колонка будет, то там все равно левые данные находятся). 2. Подозреваю, что будет подтормаживать. Поскольку картинки для uploads хранятся в виде сериализованного массива, то сортировка эта получится по очень длинной текстовой строке, что может привести к затормаживаниям. Уж лучше тогда держать дополнительное вычисляемое поле image_count в котором хранить числовое количество картинок, которое обновлять например раз два в сутки и уже по нему давать сортировку.

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

/template/frontend/agency/css/style.css стр. 1727 (то что левее описания) .t_i_title {width: 250px;padding: 7px 0 0 8px;}и стр.1732 (блок самого описания).t_i_desc {padding: 7px 0 0 8px;width: 200px;float: left;}В обеих есть width: NNNpx; Нужно для каждой подобрать новые NNN (напр. для первого блока 150, а для второго 300) но так, что бы в сумме они все равно составляли то число пикселей, которое сейчас у них есть (450). ПС. Нумерация строк в файле стилей примерная и может отличаться от того, как в вашем файле.

Если алиас простые, напр: сайт.ру/город сайт.ру/страна то географические объекты имеют возможность указать для сабя алиас+мета-поля в самом редактировании этого объекта географии Если алиасы комбинированные сайт.ру/город/тип_недвиги/тип_контракта сайт.ру/город-тип_недвиги-тип_контракта то для формирования их (алиас, фильтр-параметры, мета) служит приложение Линк-Менеджер (predefinedlinks). А в плане вывода тут единой механики нет пока.

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

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

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

http://www.etown.ru/s/topic/1462-поиск-по-id/?p=16045

смотрим этот вариант http://www.etown.ru/s/topic/2452-обновление-system-3036/?p=27186

Понял. Бокс типов так же формируется в обход стандартной инициализации модели. В блокнот.

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

Понравились мне последние два коммента. Хорошо, что многие люди уже четко понимают, что все то, что есть на сайтах, которые постят котиков, не всегда логично и оправданно на сайтах с недвижимостью.))

У вас есть возможность списаться со мной в скайп или аську?