Андрей Быкадоров (Все сообщения пользователя)

В смысле для записи в поле CONFIG в БД? Это понятно. Потом, когда надо вытащить сохраненные значения и склеить их со структурой конфига - разобрался - метод Bitrix\Sale\Delivery\Services\Base::glueValuesToConfig не может приклеить их к структуре для кастомных типов множественных. Для простых множественных типа String умеет, а для более сложных, например, встроенного кастомного Period, если сделать его множественным, уже не умеет.

Переопределил этот метод в обработчике, чтобы он умел склеивать данные со структурой посложнее, + getEditHtml  +getEditHtmlSingle пришлось поправить, осталось с js разобраться, т.к. кнопочка Добавить ведет себя неадекватно.

Возникла необходимость сделать пользовательский тип свойства для службы доставки, как описано здесь
https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=7350&LESSO... (для свойств службы доставки используются те же классы, что и для свойств заказа)
Проблема возникла с попыткой сделать множественное (MULTIPLE) свойство пользовательского типа. Похоже, классы, которые готовят данные для записи значений этих свойств в БД в поле CONFIG, а потом читают их из него и готовят их для представления в виде элементов формы, не рассчитаны на множественные свойства. Ну, т.е. такой случай, вроде обрабатывается алгоритмами этих классов, но правильно прочитать и обработать конфиг с данными, который сами же записали, они не могут.
Встречался ли кто-то с этим и так ли это или я что-то не так делаю и стоит разобраться глубже? Может, кто-то видел службы доставки с множественными свойствами пользовательского типа?
В принципе, можно плюнуть на подготовленный на странице редактирования службы доставки конфиг и в getEditHtml класса типа свойства самому прочитать из БД сохраненные значения свойства, к чему и склоняюсь, но, может, более цивилизованное решение таки существует.

не уверен, что понял вопрос, но почему не передать его просто get параметром в url?

сохраняются в таблицах базы данных, а не в папке.

то же самое - function vkapi_vkmarket() менять на __construct

ну, это уже php пошел, а не Битрикс, разбирайтесь, читайте мануал, полезно будет, тем более написано, что за ошибка
типа

Как, интересно, в одно и то же свойство можно записать два разных типа?

посмотрите внимательно на диаметр одного и на диаметр другого товара в админке, чем они отличаются. Если поле текстовое, то часто такое получается, когда у вас есть "17" и "17 " (пробел после).

я смотрю в фаерфоксе в консоли на XHR запрос типа POST https://ваш_сайт/bitrix/components/bitrix/sale.order.ajax/ajax.php , разворачиваю его, жму вкладку Ответ, там то, что компонент отдал по аякс запросу - если в коде php ошибка, то там дебажная информация по этой ошибке, файл, строка, стек вызовов, их хватает обычно, чтобы найти и исправить. У вас не так?

Вам лучше включить debug=true в .settings.php и в консоли браузера посмотреть на аякс ответ модуля оформления заказа. Там, скорее всего, будет описание ошибки с указанием файла и строки.
А по коду - ну, вижу разве, что устаревший split() на explode надо бы заменить, но, возможно и еще что-то. Гораздо удобнее искать баги с дебаггером)).

Может, в init.php прописать custom_mail, которая не будет делать ничего?

на событие сохранения заказа повесьте обработчик, пример разделения оплаты на 2 части есть в  этом уроке https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11471

phpversion()

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

если единоразово надо выполнить код, то идите в админке в Настройки -> Инструменты -> Командная PHP-строка

более цивилизованный вариант - найти в $arResult лишние товары и убрать их.

ну, например, повесьте на загрузку страницы вызов BX.Sale.OrderAjaxComponent.sendRequest(). Ваш $arResult сформирован до того, как вы удалили товар из корзины, поэтому нужен еще один запрос.

Возможно, какие-то правила css вашего сайта у вас просто радиобаттоны прячут. Нажмите F12 и посмотрите, что там с ними творится.

Вам лучше сюда,

https://dev.1c-bitrix.ru/support/forum/forum32/topic149070/

там уже 6 страниц написали про подобные несчастия. В вашем случае сначала смотрите модуль, в котором определен класс CVsfrProstroi ищите метод ShowPanel, добавляйте ему static и смотрите, что получится.

Ну или просто обновите этот модуль, если такое возможно.

нет, не надо никуда копировать компонент

ну вообще можно при добавлении в корзину задать значение свойства, например в Add2BasketByProductID, в третьем аргументе можно передать значение свойства, которое введет пользователь. Потом оно прекрасно хранится в БД, отображается в корзине и потом в заказе.

Но обычно в шаблоне компонента присутствует немалый js код, который добавляет товар в корзину и надо для каждого конкретного разбираться как он работает и править-кастомизировать его, чтобы он принимал и передавал дальше в корзину значение свойства, которое задал пользователь.

Загляните в таблицу b_user_option в последние записи для того пользователя, который это сделал, там найдете в категории main.interface.grid  в поле VALUE массив десериализуйте, поправьте значение page_size, сериализуйте обратно и сохраните.

SetPropertyValuesEx, только задавайте свойство массивом Array( "VALUE" => Array( "TEXT" => "ваше содержание поля", "TYPE" => "HTML") );
https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblockelement/setpropertyvaluese­x.php Пример 2. Если это действительно нужно, непонятно зачем, но вам виднее.

Да, вы правы, тип в редакторе по умолчанию задается в поле DEFAULT_VALUE:  a:2:{s:4:"TEXT";s:0:"";s:4:"TYPE";s:4:"HTML";}

USER_TYPE:HTML
поле DEFAULT_VALUE задает значение по умолчанию, а не тип.