В документации описано присвоение значения типа "Список":
Код
//описание массива для свойства типа "Список"
$arrProp = Array();
$arrProp[ID или CODE] = Array("VALUE" => $ENUM_ID ); //ENUM_ID - это ID значения в списке
Fatal error: Call to undefined method CSearch::DelayedStemIndex() in /bitrix/modules/main/classes/mysql/agent.php(162) : eval()'d code on line 1
А переиндексацию сайта не пробовали делать? Ещё путь до файла указывает на скрипт механизма "Агентов". Можно посмотреть список агентов на предмет ошибочных обработчиков.
Цитата
Дмитрий пишет: Хостер, видимо, блокирует eval().
Каким образом проверяли? Например разместите в корне скрипт и посмотрите, каков будет результат вывода.
Только что перепроверил из режима правки - редактирование параметра работает ровно также как и из административного раздела. А зачем Вам опция MULTIPLE для типа параметров CUSTOM?
Поле типа TEXTAREA в свойствах заказа ограничено длинной 255 символов, Создал дополнительное поле типа TEXTAREA в свойствах заказа, а оно почему-то ограничено длинной 255 символов
Dmitry Sirotin пишет: А как быть, если потребовалось хранить для заказа большой фрагмент текста? Ведь для значений свойств установлено ограничение в 255 символов.
Евгений Платонов пишет: На практике, куча инфоблоков для каталог а - бред )
Аргументируйте. По мне, так это вполне логично. Инфоблоки предназначены для хранения однотипной информации. Каталог разбивается по типам товаров на несколько инфоблоков. Для доступа к каждым товарным позициям можно использовать несколько компонентов Каталог в разных директориях (/alcoholic/, /non-alcoholic/, /supplies/). Для вывода баннеров и прочих слайдеров можно использовать компонент Лента новостей. http://dev.1c-bitrix.ru/user_help/content/iblock/components_2/news/news_line.php
Так и не удалось записать значение полей в результат веб-формы этим способом. Но задача всё-таки решилась двумя дополнительными вызовами CFormResult::SetField() после создания результата.
Можно просто вручную распаковать из архива дамп БД и загрузить. А если в резервной копии ничего нет, кроме дампа БД, то и restore.php не должен ничего кроме этого загрузить.
На сайте создана веб-форма с двумя полями. Веб-форму планируется применять для хранения административной информации. По идее в обработчике события необходимо создать результат этой формы с заполненными полями. Для этого используем API метод CFormResult:Add.
Код
if (CModule::IncludeModule("form")) {
$arValues = array (
"status_SIMPLE_FORM_3" => 4,
"form_text_ADDITIONAL_16" => $ID,
"form_textarea_ADDITIONAL_17" => $sField
);
if ($iResultID = CFormResult::Add(self::ORDER_SUPPLEMENT_FORM, $arValues)) {
$sEvents .= "\n" . "Дополнительные поля сохранены: #" . $iResultID;
} else {
$sEvents .= "\n" . "Ошибка сохранения дополнительных полей";
}
global $strError;
$sEvents .= "\n" . "strError: " . "\n" . var_export($strError, true);
}
В лог пишется сообщение об успешной записи результата для формы, а strError выводит значение NULL. Но если просмотреть результаты веб-формы, то поля остались пустыми. Подскажите в чём может быть ошибка?
Можно попробовать использовать событие OnAfterUserRegister. Создаёте почтовый шаблон письма о согласии пользователя на подписку и в обработчике OnAfterUserRegister вызываете почтовое событие, в зависимости от параметров пользователя. В качестве примера приведу обработчик, который высылает пользователю сообщение с купоном скидки после регистрации.
Поле типа TEXTAREA в свойствах заказа ограничено длинной 255 символов, Создал дополнительное поле типа TEXTAREA в свойствах заказа, а оно почему-то ограничено длинной 255 символов
Возникла идея аналогично использовать свойство заказа типа TEXTAREA. Создал свойство, организовал необходимый обработчик события, а после вызова CSaleOrderPropsValue::Add() значение в БД отсутствует. Какой тогда смысл в свойстве типа TEXTAREA, если установлено ограничение в 255 символов?
Михаил Вицен пишет: Столкнулся с тем же моментом, но где стоит ограничение нашёл сразу. Скажите - кошерно ли менять подобные вещи руками в базе и не слетит ли эта "модификация" после обновления?
Самого интересует этот вопрос, но думаю, что менять в базе не "кошерно" и при наличии в обновлении таблицы `b_sale_order` тип поля вернётся в прежнее состояние.
Может кто-нибудь подсказать, как выйти из данной ситуации?
Пока никаких решений больше нет, кроме как добавить в шаблон JS с выводом предупреждения об ограничении.
В скрипте /bitrix/php_interface/include/catalog_export/yandex_run.php есть вызов метода CCatalogProduct::GetOptimalPrice(). Проследите за формированием тега <price />.
В этом же скрипте для $minPrice можете применить функцию ceil() для округления в большую сторону.
На сколько я понял, цена в выгрузке формируется на основе метода CCatalogProduct::GetOptimalPrice(). В этом методе происходит округление с точностью до 2.