Довольно давно получил на эту тему рекомендацию. Если клиент просит конкретную цену, то оцениваешь реальные, без оптимизма и обмана, предполагаемые трудозатраты по верхней планке и из этого рассчитать сумму. Премия получаемая как разница между реальным и предполагаемым это так же и страховка клиента. Так что тут все правомерно.
Так же стоит понимать что мы продаем бизнесу а не соседу. И расходы эти покрываются не из зарплаты физика а из оборотных средств компании. Для бизнеса, даже небольшого, несколько тысяч рублей не великие затраты, гораздо важнее предсказуемость расходов и надежность работы бизнеспроцессов.
Как вариант
сначала с помощью CIBlockElement::GetList собираете $arIDs массив подходящих id товаров. Затем из этого создаете фильтр для компонента
global $arFilter;
$arFilter = ["ID"=>$arIDs];
и в вызове компонента прописываете
'FILTER_NAME'=>'arFilter',
Пагианция выстроится как надо
Это сильно зависит от того что это за тип свойства у вас. Это равно может быть связанный элемент, список или текстовая строка. Подходы соответственно разные. Опять же непонятно вам нужен список всех возможных значений или всех использовавшихся.
это стандартная регистрация, она не подразумевает телефон. Дополнительные данные - телефон, дата рождения, почтовый адрес и т.п. вносятся в личном кабинете кастомной формой.
Если хотите именно в регистрацию добавить телефон, то я вижу два пути:
- создать собственную форму с собственным обработчиком который будет принимать данные, создаст юзера с этими данными и авторизует посетителя под новосзданным юзером. и внедрить эту форму на закрытые страницы
if (!$USER->IsAuthorized())
{
форма
} else{
закрытый контент
}
- создаем форму и обработчик, форму ставим вместо содержимого кастомного шаблона компонента system.auth.registration
а зачем вы в резервирвируемом количестве указываете "1" если задача снять с резервирования? Может лучше так
\Bitrix\Catalog\Product\CatalogProvider::ReserveProduct( '1111', '', 'N' );
И проверьте подключен ли в этот момент модуль каталога
<?
if (CModule::IncludeModule("catalog"))
{
//здесь можно использовать функции модуля
}
?>
dikey58, Нет я в целом про обходной путь. Как сказал PetrPo то решение сыроватое. А лично я с сырыми решениями битрикса не рискую связываться, баги случаются в самых неожиданных местах. Но если это решит ваши задачи, то и отлично.
Ну добавьте тогда еще еденичку ))
Вошел в fl.ru прочитав php для дебилов и курс bitrix для имбицилов. Уже несколько лет не могу снова проплатить проф аккаунт потому что не кончаются заказы.
Эк сурово забрались. лезть в код компонента если не хочешь кастомизировать дело безблагодатное. Лучше поискать события в шаблоне компонента sale.basket.basket. например в дефолтном шаблоне в файле js\component.js есть подходящая функция applyPriceAnimation в которую можно подцепится и конечную сумму ттам же считать.
Если выпало внизу, то проверить код футера глазами и шаблонов компонентов которые в футере. Это если через админку.
А так, проще скопировать на локальный файлы сайта и сделать полнотекстовый поиск, с помощью notepad++ или иного ide, по характерным словам из этого скрипта. Так найдете где он расположен и сразу будет видно где нарушение.
Самый костыльный метод.
Ловишь jquery событие прерасчета цены в корзине по изменению элемента и вписываешь это значение в цену заказа.
А по уму находишь у корзины функцию инициирующую перерасчет и добавляешь туда ajax запрос обновляющий область "оформления заказа"
альтернатива есть. Я обязательно напишу об этом когда-нибудь, пока еще сама не укрепилась на новом поприще - в процессе. Главное: без особой просадки по деньгам, что не мало важно для нас - взрослых людей.
Спасибо за такой развернутый ответ.
Значит сваливать с битрикса в режиме эвакуации пока не стоит, но посматривать по сторонам надо...
D7, по моему скромному, провалилась просто потому что была совершенно непонятна среднему разрабу и плохо документирована. Возможности вроде и есть, а как использовать понятно плохо и через документацию не прорваться. То есть провал не разрабов, а руководства. А сейчас это уже и устаревает.
YMakeev, Страшно, а что делать?
На самом деле не все так плохо, файловая копия как правило есть на локалке. На сервере соответственно серверный бекап. Работа через ftp. В ide есть стрелочка "назад". Ну и php это "язык созданный умирать", а значит подвешивание машины не грозит. Так, что падение скрипта, выбрасывание warning, e_notice и т.п. не повод для расстройства, а рабочий момент исправляемый за секунды. К тому же и это бывает редко, все же не в слепую работаю.
Но все это не отменяет потребности в документированном контроле версий.
Так же стоит понимать что мы продаем бизнесу а не соседу. И расходы эти покрываются не из зарплаты физика а из оборотных средств компании. Для бизнеса, даже небольшого, несколько тысяч рублей не великие затраты, гораздо важнее предсказуемость расходов и надежность работы бизнеспроцессов.