abushyk

измените строчку if(count($imgs)>0){ на if(is_array($imgs) && count($imgs)>0){ в том кусочке который вы показали и зупастите выгрузку.

фф и хром в принципе уже больше года наверное не поддерживают флеш-плагин. если кнопка выглядит так http://www.awesomescreenshot.com/image/2538796/06c90b36eeb4315fef4983af5706cce7 или так http://www.awesomescreenshot.com/image/2538798/4668a1c7380a9b1cf3a4e5e6befd117d значит флеш-плеер в браузере выключен (они его часто вырубают самостоятельно не спрашивая).

Слишком много "если" в вопросе. Разницу между % и == вы указали правильно. Использование деления по модулю (%) позволяет вставлять периодично через равные промежутки. Использование вставления через равно ($smarty.section.i.iteration==10) вставляет четко в нужные места. Но особой разницы между ними нет. В вариантах не учтено, что если список выводится блоками, то не на каждом кране этот список будет по три в ряд (даже на той же реалии). Если же варьировать количеством вставляемых блоков, то перед выводом списка нужно читать значение {$ПЕРЕМЕННАЯ_СО_СПИСКОМ|count} - количество объяв и тогда принимать решение сколько выводить рекламы и через сколько объектов. В общем расчет сделать можно, но чем меньше будет если-вариантов, тем проще будет продумать хоть какой-то алгоритм.

Как это делается, можно посмотреть в любом из приложений, которое что-то выводит на сайте по справочнику в админке - новости, статьи, ЖК, отзывы... Никаких статических страниц тут не будет. Самым крайним вариантом может быть даже работа без приложения а просто вживив в main.php шаблона перехват какого-от адреса этого вывода и манипулирование там, выборки из БД, заброс в шаблон и вывод шаблона. Эта идея не то что бы была плохой. Она просто капец какая жуткая. Если охота взорвать себе мозг - можно так делать. В принципе оно даже будет немного работать, но ровно до момента, пока не станет нужно что-то связать с этим объектом или привязать его к чему-то. Если нужно сортировать что-то - добавьте отдельное поле Сортировка или Вес или Размер понтов и ставьте значение туда, условившись, что чем больше - тем лучше или наоборот. Но не используйте первичные ключи (идешки) для каких-то осмысленных сортировок.

Хотел спросить исправили ли вы только имя аттрибута на теге или еще и скрипт добавления объекта в Избранное, но глянув в сорцы скрипта увидел, что все сделали.))

В принципе относительные ссылки в движке везде. Это сделано как раз для того, что бы абстрагироваться от имени домена, и не менять его везде, как только сайт сменить доменное имя или реплицируется на другой домен. насчет различия относительных и абсолютных вы все правильно поняли. первые пишутся от слеша и браузер направляет переход по ним относительно текущего домена, а абсолютные указывают "точный" адрес страницы. Использование абсолютных ссылок в некоторых случаях действительно сохраняет работоспособность ссылки. Но не в случае перемещения ее где-то в пределах сайта - в этом случае путь по ссылке рассчитывается относительно домена, а домен, при "перемещения ее где-то в пределах сайта" как можно понять не меняется. Самый реальный пример абсолютных ссылок когда-то использовался для ссылок под логотипами в шапке и подвале сайта, как ссылка на главную. Делалось это для того, что бы при сохранении страницы на пк (когда правой кнопкой мыши и "Сохранить страницу...") хотя бы эти главные ссылки были цельными и юзер, прочитав сохраненную оффлайн копию, мог перейти уже на сайт в интернет на реальный сайт. Делает ли так кто-то еще до сих пор - мне не ведомо. Других случаев, когда нужен абсолютный урл мне не известно. Влияния использования абсолютного урла против относительного в сео я так же не замечал. По крайней мере, ни один десятка из сеошников, с которыми я занимался анализом последние 2 года, никогда не говорил о какой-то важности этого. ПС. Есть еще особый вид относительных ссылок. Те, что я описал - ведут отсчет от корня сайта (которые начинаются со слеша). А есть такие, которые ведут отсчет от текущего документа. Вы их видели, у них в составе есть две или одна точка (../img или ../../../settings/). Вот эти да, при перемещении вызываемого файла в другое место, ломают нафиг всю цепочку иерархии. Но таких ссылок на весь движок используется две или три для специфичных системных включений и никогда для ссылок на разделы сайта или какие-то публичные ссылки.

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

В панели GoogleAds наверное. Это вроде его код.

Данные в список объявлений выбираются в том виде, в котором они хранятся в базе данных в таблице re_data. Для строковых данных это приемлемо, но часто возникает необходимость получения данных, которые имеют тип select_by_query и хранятся в смежных таблицах. Такие данные доступны в данных объявления в списке в виде числового идентификатора. Некоторые из них, например city_id, region_id, гриддер умеет поставлять сам в виде текстовых названий соотвествующих городов и регионов. Но пользовательские доступны только в виде идентификатора. Для того, что бы например подтянуть в список имя направления или шоссе из пользовательского справочника можно использовать Локальный грид-менеджер. Но с версии system 3.3.17 доступна следующая настройка: Общее - core.listing - core.listing.select_query_fields В этом поле можно перечислить необходимые для текстуализации поля и имя переменной в которой они будут лежать. Например у нас есть поля Направление (route_id) и Материал фундамента (fundament_id) каждый из которых имеет тип select_by_query и его значения расположены в отдельных справочниках направлений и фундаментов. В обычной ситуации в данных объявления в шаблоне мы имеем доступ только к {$grid_item.route_id} и {$grid_item.fundament_id} где у нас лежат малоупотребимые цифры 5 и 9. Мы то знаем, что route_id=5 - это "Алтуфьевское шоссе", а fundament_id=9 - это "гранитный блок", но это не удобно. Тогда, в упомянутое поле настройки мы записываем строки route_id=route_name fundament_id=fundament_name каждая строка отдельно. Формат прост системное имя select_by_query-поля, а после равно имя переменной в которой будет текстовое значение. После этого у нас в объекте будет два значения - {$grid_item.route_id} с числовой идешкой и {$grid_item.route_name} c текстовым названием значения. Если не указать значение после равно, то текстовое значение заменит собой значение в route_id, что не всегда рационально. Не следует злоупотреблять этой опцией и вытаскивать все параметры, что придет в голову. Всегда проверяйте, действительно ли оно вам там нужно.

Если не включена настройка в блоке настроек приложения ЖК под названием "Разрешить создание пользовательских объектов" тогда только админ. Если включена, то может любой зарегистрированный. Без регистрации в любом ее виде добавить ЖК нельзя.

версия цсс зависит не от шаблона, а от браузера. если браузер понимает и орисовівает цсс3, то отрисует. если не понимает, то не отрисует. самое простое - использовать <div class="span4"></div> обертки, что бы верстать в 3 колонки. Но для бустрапа2 для правильной расстановки нужно каждые 3 блока span4 заворачивать в <div class="row-fluid"></div> что весьма усложнит логику автовывода. Можно выводить просто в li но задать для них свойства float: left; width: 33%; Тогда они будут пытаться стать в строку по три. Но тут сильно будет зависеть от контента внутри li. А для мобильных прописать media-query для разных ширин экрана с заменой width на соотв. Например для экранов до 500px width:100%; для экранов до 800px width:49%; а для остальных останется 33%

Для дом.риа есть модуль export_domria

Для строк - это как раз самая правильная сортировка. Пробел тут не поможет, результат будет тот же. Можно попробовать отсортировать по разбитому названию ORDER BY CAST(name AS UNSIGNED), name т.е. мы сортируем по двум значениям - приведенному к беззнаковому числу названию, а потом по полному имени. Тогда оно выставит сначала по порядку числовых префиксов в названии, а потом, внутри одинаковых числовых начал, уже отсортирует как строки. Либо добавить в модель районов поле sort_order и проставить его числами и сортировку для элемента указать по этому полю. Этот вариант требует немного ручной работы, но более надежен, прост и позволяет даже некоторые районы всплыть вверх в обход порядка (если такое нужно).

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

Напишите мне в пм фтп. у меня уже есть исправление (на фб формат ответа поменялся), но я просто не выдал его еще в обновления.

1. Запрос 'UPDATE '.DB_PREFIX.'_data SET `active`=1 WHERE `active`=0 AND `optype`=1 AND `rent_end`<=\''.$rent_margin.'\' AND `rent_end`>=\''.$now.'\''; Часть выделенная зеленым возможно не нужна. Если был сбой и какие-то объявления не активировались, но дата окончания ренты их выпала из промежутка между сегодня и сегодня+5дней, то они зависнут неактивными. В таком случае лучше активировать все, у чего конец ренты истекает в пределах ближайших 5ти дней, даже если эта дата истечения в прошлом. 2. Значение $rent_margin. 2a. Если поле rent_end имеет тип date, то $rent_magrin=strtotime(date('Y-m-d 23:59:59', (time()+5*86400))); или если забить на условности, то $rent_magrin=time()+5*86400; 2б. Если поле rent_end имеет тип dtdatetime, то $rent_magrin=date('Y-m-d 23:59:59', (time()+5*86400)); Т.е. крайним сроком для рассчета истечения ренты мы назначаем полночь дня, через 5-ть дней от сегодня (момента запуска крона). Иначе стартуя крон в час ночи, вы будете освобождать объявки у которых истекает срок аренды до часу ночи, фактически выкидывая день. Это не принципиально. 3. Значение $now (если используется) всегда $now=date('Y-m-d H:i:s', time()); ПС. Дима в принципе верно написал, но переставил просто крайние границы местами.

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

приходите ко мне в пм с фтп, адресом сайта, доступом в админку и, было бы супер, с доступами в phpmyadmin

Я тут потыкал у себя на таком шаблоне. Попробуйте в файле header.tpl где стоит запуск этого слайдера, найти блок $( document ).ready(function( $ ) { $( '#example3' ).sliderPro({ width: 960, height: 500, fade: true, arrows: true, buttons: false, fullScreen: true, shuffle: true, smallSize: 500, mediumSize: 1000, largeSize: 3000, thumbnailArrows: true, autoplay: false }); }); в нем, после autoplay:false поставьте запятую и строку imageScaleMode: 'contain' Эта настройка указывает не путаться заполнить фоткой все место в слайдере, а наоборот, будет пробовать вписать его полностью в выделенное место.

Это вы в карточке пытаетесь их растянуть на http://dom.promtex.net.ua ? оффтоп. чисто по человечески, как пользователь, я бы посоветовал не тянуть фотки, а вывести их заведомо меньшими блоками, например как в базовом агенси, без слайдера. Или сделать область слайдера заведомо меньшей, что бы фотки если и тянулись, то минимально. просто когда картинка в 400 пикселей растянута стилем или программно до 800 - это создает жутко гнетущее ощущение, что, когда камера на 2Мп есть почти у каждого школьника, владельцу сайта пофигу на клиентов, которые в 90% случаев хотят посмотреть именно фотки. клиенту нет разницы, что ваши поставщики данных не имеют больших фоток, но когда ему вываливать обезображенную раздутую картинку - он скорее всего свалит. лучше имхо показать "мол да, мы не доработали и фотки адекватной пока нет, но вот посмотрите то, что есть, пусть и небольшое", чем показать огромную, но размазанную картинку, отбив у него всю охоту смотреть дальше.

Что бы оно любые фотки и меньшие этого размера, и больше вписывала точно в этот размер?

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

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

В карточке объекта заголовок фото доступны в элементе title. Например в цикле, где выводятся фотки {section name=j loop=$photo} можно запросить {$photo[j].title} и выведутся заголовки прописанные в админке. В списках почти аналогично. Внутри цикла, который выводит объекты {section name=i loop=$grid_items} мы вызываем {$grid_items.img[0].title} и получаем описание от первой картинки, которая выводится в список. В самом общем смысле, везде где у нас есть вывод фоток из стандартных элементов модели, там, у каждой фотки кроме параметров .normal и .preview (содержащих мини-картинку и большую фотку), есть параметр .title который содержит и описание.

Поле "Поле, отвечающее за признак продажи" и вообще настройки тогда не трогаем. Добавляем в модель data поле deal_status. Для всех объектов ставим в это поле значение "переуступка". Все.