-
Публикаций
148 -
Зарегистрирован
-
Посещение
Весь контент Алексей Склейнов
-
обращайся))) нарисуем))))
-
В общем выложу свое решение, раз тема поднята была. if(!empty($filter['nosorting'])) $nosorting_filter = $this->db->placehold('NOT IN (SELECT 1 FROM __products_categories pc WHERE pc.product_id = p.id) = ?', intval($filter['nosorting'])); это запрос к БД по фильтру отсутствующих товаров в категориях (то есть - товаров не принадлежащих ни к одной категории) остальное делается по аналогии как выше заметил Kors. Собственно для чего нужен такой фильтр? - Выборка товаров нуждающихся в сортировке по категориям.
-
Народ, подскажите лаконичное решение для фильтра товаров не принадлежащих ни к одной категории в админке. Начал с этого: <!-- Фильтры --> <ul id="all_filter"> <li {if !$filter}class="selected"{/if}><a href="{url brand_id=null category_id=null keyword=null page=null filter=null}">Все товары</a></li> <li {if $filter=='nosorting'}class="selected"{/if}><a href="{url keyword=null brand_id=null category_id=null page=null filter='nosorting'}">Не сортированные</a></li> <li {if $filter=='featured'}class="selected"{/if}><a h
-
я полагаю что дубликат свойств товара (а это именно свойства, характеристики) не имеет смысла делать, а значит нужно применить ключи к необходимым существующим свойствам и выводить их по фильтру ключа в шаблоне. Что касается админки, то здесь придется писать собственные обработчики(обработчик) и страницы (страницу).
-
да, работал на локалке, иначе не сбрасывал бы... возможно вам яша отдает страницу геоположения... но по парсу страницы характеристик этот скрипт верен... на днях выкладываю на хост движок, проверю и профикшу, потом сброшу и тот вариант. Проверяйте свои настройки местоположения, пробуйте заходить через прокси... точного ответа дать сейчас не смогу.
-
// Для использования прокси используйте строки: define("USE_PROXY", 0); // 1 = использовать прокси define("PROXY", 'xxx.xxx.xxx.xxx:80'); define("PROXY_USER", 'login:password'); // Настройка региона в маркете define("REGION", '101852'); // 213 - москва, список регионов: http://search.yaca.yandex.ru/geo.c2n define("DOMAIN", 'market.yandex.by'); // для России нужно market.yandex.ru session_start(); // Временный файл для хранения cookies // Так как временный файл существует до окончания выполнения скрипта, // сохраняем его содержимое в сессию $cookies_filename = tempnam(sys_get_temp
-
а... ты про это.... первый - просто пример использования {section} вместо {foreach} в котором можно сделать вывод в обратном порядке в самом шаблоне, просто поменяв пару строк. что по сути с реверсом идентичено (автор темы бы понял что к чему, не лузер вроде, как мне показалось), а кто касается подробного рассмотрения ситуации именно одного товара, то вариант Корса (разделить нормальные и ненормальные) более благоразумнее в данной ситуации и их можно выводить вообще в разных таблицах. Приклеил якорь - "ненормальный" и все, он уже отшельник))))) живет с такими же ненормальными отдельно в своей
-
Перед тем как умничать следовало бы понять о чем вопрос... ведь по сути его может и устроит вывод в обратном порядке (по умолчанию нормальные товары первоочередной значимости вносились сразу в базу и попадали вниз списка, а при пагинации их не удобно доставать) при котором товары первоочередной значимости вверху таблицы выводятся соответственно. Именно поэтому я и предложил такой вариант.
-
{* секции могут иметь вложенность любой глубины. Используя вложенные секции, вы можете обращаться к сложным структурам данных, таким как многомерные массивы. В этом примере $contact_type[customer] - это массив типов контактов для текущего клиента. *} {section name=customer loop=$custid} <hr> id: {$custid[customer]}<br> name: {$name[customer]}<br> address: {$address[customer]}<br> {section name=contact loop=$contact_type[customer]} {$contact_type[customer][contact]}: {$contact_info[customer][contact]}<br> {/section} {/section} м
-
кстати хорошую мысль ты родил)))) вот смотри что работало бы в пользу... я вообще со стороны разработчика CMR и заказчика в одном лице... товарные запасы - не мешало бы конечно существующие формы расчетов сделать в автоматическом режиме, естественно для систем, которые контролируют фактическое движение (реализацию). для чего это нужно... скажем ты за товаром катаешься раз в месяц (определенным товаром), но у одного поставщика получаешь несколько и разного... и согласно фильтру товаров поставщиков, а может и месторасположения поставщиков при критической отметке одного из товаров - формирует
-
ты меня извини конечно... не хочу показаться первобытным человеком - но я имею коммерческое образование и опыт работы в торговле на руководящих должностях в огромнейшей торговой сети и вот что отмечу от себя... эта система будет полезна только тем людям, которые не знают как делается анализ в априори, как рассчитывать товарные запасы, изучать спрос, проводить маркетинг... это для людей, которые дальше монитора не видят по сути... вот что ты отслеживаешь в ней? просто движение... на кой черт это нужно, когда по закону торговли нужно продавать не то что изготавливают, а то что покупают... а у те
-
кстати забавный случай у меня приключился... в форме использовал переменную "call" - обозначил чисто вызов специалиста.... что бы понятнее было, в самой форме выглядит вот так <div class="form-group"> <label for="input_call" class="col-xs-4 col-sm-4 control-label">Вызов специалиста</label> <div class="col-xs-8 col-sm-8"> <input id="input_call" name="call" type="checkbox" class="checkbox" value="1" {if $call}checked{/if}> </div> </div> в итоге форма не работает, ни в базу, не отправка админу не осуществляется, хотя обработчик все че
-
ты прав, но как расширение функционала пусть будет отдельный обработчик, который впоследствии можно будет применить не только конкретно к блогу но и к подобным модулям (новости, история и т.п.) а также в целом где необходимо превью.... да и потом, я, к примеру, не расширяю существующую форму обратной связи, а как правило добавляю свою, если она отличается от дефолтной... да, отдельным файлом, но когда заказчик просит что то изменить в ней - мне проще работать с собственным файлом... плюс при последующем обновлении движка эти файлы (поскольку они отдельные) не будут затронуты, а это значит что
-
все нормально работает за исключением удаления ресайзов...для этого вместо public function delete_image($id) { $query = $this->db->placehold("SELECT image FROM __blog WHERE id=?", intval($id)); $this->db->query($query); $filename = $this->db->result('image'); if(!empty($filename)) { $query = $this->db->placehold("UPDATE __blog SET image=NULL WHERE id=?", $id); $this->db->query($query); $query = $this->db->placehold("SELECT count(*) as count FROM __blog WHERE image=? LIMIT 1",
-
удаление в админке превью - в post.tpl добавляем // Удаление изображений $(".images a.delete").click( function() { $("input[name='delete_image']").val('1'); $(this).closest("ul").fadeOut(200, function() { $(this).remove(); }); return false; }); ща посмотрю что с удалением из директории и при удалении статьи
-
да.. это решение как превью для блога, можно и галерею, но придется чуть иначе подойти к вопросу - по примеру товаров или перечислением изо в строке изо таблицы базы данных с последующие расшифровкой в скрипте и обработкой в массив и какой смысл в этом для типового решения, когда можно чисто в редакторе приметить для блока с галереей идентификатор или класс и обработать ява скриптом в необходимом вас виде и функциями анимации, предпросмотра и т.п.
-
отдельный момент, по ошибкам, раз уж начал этот вопрос... в целом Симпла для сео отличный движок, вопросов нет, и семантика и проработка пользовательских моментов при заполнении ключевых слов и описания, нет правда микроразметки в дефолтном шаблоне, но это не касается движка, но отсутствует правила кеширования и сжатия, так что этот момент стоит проконтролировать владельцам сайтов. конечно эти установки индивидуальные - но рекомендуемые...