поле "PAY_SYSTEM_ID" там есть только это. это Платежная система, которой (будет) оплачен заказа.
А уж если вручную был выставлен флаг оплаты заказа, то заведите свойство в заказ. Если платежной системой,автоматизированной, то значение вам подойдет.
вам бы почитать документацию, как устроены компоненты, шаблоны_сайта, шаблоны_компонентов, комплексные компоненты
Цитата
Tatc пишет: захожу в [catalog] и вижу там в папке битрикс [catalog.element]. А внутри темплэйт и резалт_модифаер. Компонента там нет.
увы, но он есть. site/bitrix/components/bitrix/catalog.element/component.php(именно файл)(про правку битриксовых компоннтов я писал выше) и не шаблона сайта, а от корня путь.
Жан-Пьер Бар Д'ак пишет: ну почему нет-то? если мне базовую цену надо узнать, GetBasePrice вполне зашибись...
там есть текст: "При установленном модуле торгового каталога можно выводить и цены элемента. Для этого в качестве одного из полей необходимо указать CATALOG_GROUP_<PRICE_CODE>, где PRICE_CODE - ID типа цены."
на пальцах: используя ваше CPrice::GetBasePrice($id) вы получите цену у одного элемента.
Имеем выборку из 200 элементов вы будете делать 200 запросов на получение их цен? Удачи. Я думаю правильное использование CIBlockElement::GetList у вас займет намного меньше чем 200 запросов.
Tatc пишет: уууф, тяжко пока это все для моего понимания Я думала, надо будет в section.list лезть)
а что значит "вынести его в отдельное пространство"? Скопировать прежде, чем редактировать?
да
#SITE_DIR#/bitrix/components/#пространство#/catalog.element/ Пространство bitrix трогать не рекомендуется ибо при обновлении сайта, ваш код может быть стерт.
а так, вам надо скопировать, заменить 1 строку в файле компонента component.php и изменить вызов компонента с bitrix:catalog.element на #ваше пространство#:catalog.element
в стандартном catalog.element при указании кода элемента не проверяется раздел
Вот что делает этот метод:
ха, причем, если указан ИД элемента, он вернет его же
Так вот, вы можете кастомизировать _компонент_(вынести его в отдельное пространство) и указать SECTION_ID или SECTION_CODE там, где на первом скрине стоит 2 false подрят
День добрый дамы и господа. Для некоторых групп пользователей планируется сделать долгое хранение сессии, чтоб при закрытии-открытии браузера сессия сохранялась и сайт не просил авторизацию. Менял время жизни сессии у группы и не помогло. в куках написано "сессия" и все
А что это за компонент такой "user.list"? вообще насколько я помню в CUSER::GetList нет рандомной сортировки => нужно предварительно составить массив ID пользователей, например: 1)узнать последний ID пользователя 2)сгенерировать массив из rand(#стартовый#,#максимальный#) 3)отфильтровать по новому массиву. Итого: 2 запроса
также можно сделать фильтр по случайной маске логина(1 символ,например.почему нет?!) в таком случае имеем 1 запрос
Если выгрузка идет из 1С, а там это как характеристики, такую штуку решал. работает до сих пор на 4х запросах. Там одно свойство, множественное. из минусов: реально легко запутаться в логике работы фильтра.
Можно сделать интерфейсом "таблицы", где ячейка это конкретное значение. А где хранить эти ячейки и в каком виде без разницы, что создавать класс для работы с ними, что хранить в инфоблоке.
Антон Долганин пишет: Есть еще 4й вариант - PROPERTY_<CODE> в Select. Вот им и надо пользоваться. Все остальное придет с пониманием и вы сами поймете, где что применяется.
Этот вариант я подразумевал в 3й способе, может просто немного не правильно написал. Но если какое то свойство удаляется, из инфоблока, а в коде остается, то запрос выполняется очень долго. Т.к не может найти нужное свойство.
в таком случае лучше будет до запроса элементов, выдернуть свойства у инфоблока и сформировать массив $arSelect. это будет меньше запросов нежели вариант 1.
Мне же не всегда надо получать все свойства. А если в arSelect указывать то получается на каждое свойство 1 запрос к базе.
1)пишем массив нужных кодов скойств 2)достаем свойства у инфоблока 3)формируем массив $arSelect с учетом массива(1)
даже выбирая все свойства, это лучше чем извлекать свойства циклом J элементов, по N свойст: 1)1й ваш вариант запросы = J*2 2)2й ваш вариант запросы = J*2 3)3й ваш вариант запросы = N(А если их нужно не все, то и N Будет меньше)+1;
Антон Долганин пишет: Есть еще 4й вариант - PROPERTY_<CODE> в Select. Вот им и надо пользоваться. Все остальное придет с пониманием и вы сами поймете, где что применяется.
Этот вариант я подразумевал в 3й способе, может просто немного не правильно написал. Но если какое то свойство удаляется, из инфоблока, а в коде остается, то запрос выполняется очень долго. Т.к не может найти нужное свойство.
в таком случае лучше будет до запроса элементов, выдернуть свойства у инфоблока и сформировать массив $arSelect. это будет меньше запросов нежели вариант 1.
Krakozebl пишет: Вообще-то сейчас по закону нельзя указывать пол или возраст в тексте вакансии, так как это не является профессиональными навыками по которым и нужно оценивать кандидата.
вы,будучи HR, к вам приходит _человек молодой_ (18) || (50) лет. Вы ему откажете с вероятностью 99% или 101?
Это хорошо, но версия jquery не контролируется, live убрали поддержку, определение браузера тоже, а в старых разработках применялись эти методы. Уж лучше подключать конкретную версию. Последний сайт делал на 1.9.1 и отдельно подключал скрипт определения браузера и live больше не использую.
для извращенцев: 1)собираем все версии jq в одну директорию 2)каждую добавляем в систему
тогда костыль: заведите товар типа "товар от поставщика" и к нему кидайте свойства :название,марка,модель. но это глупо потому что вам придется как то визуально скрывать это "товар от поставщика" и подменять его на "название".
Этого товара на нашем сайте нет, но его нужно добавить в корзину. Следовательно по логике, нужно добавить данный товар на сайт и уже его добавлять в корзину.
Вот и хочется избежать создание товара на сайте, но если этого не избежать, может у кого какие мысли есть и т.п.
А что мешает скриптом на лету добавлять его к себе в базу? модель есть, название есть, цена есть, количество есть, производитель есть.