Форум

Да, наверно так и было. Т.к. валюта только одна, но не рубль, а в настройках показывает, что все ок. Поэтому и сохранилась на самом деле в базе старая запись.

[URL=http://ru.wikipedia.org/wiki/RUR]RUR[/URL]:
[QUOTE]
Валютный код российского рубля по ISO 4217 — RUB, до деноминации 1998 года использовался код RUR
[/QUOTE]
Кстати, до сих пор попадаются учреждения, которые используют именно этот код.

Да, может быть в валюте и есть причина, нужно будет тоже посмотреть. Только у меня вообще не рубли были.

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

[QUOTE]Алексей Комаров пишет:
Я так понимаю, что им неоткуда прийти, если они не выделены в скобках и не пристыкованы через $3.[/QUOTE]
Почему? Апач увидит тот REQUEST_URI, который его запросили и разберет его, он ничего не знает про ваше ЧПУ. Затем система urlrewrite битрикса разберет ваше правило, добавит в суперглобальные переменные ЧПУ-параметры и подправит $_SERVER['QUERY_STRING'].

Для проверки на вашей ЧПУ-странице с обычным правилом сделайте echo '<pre>'.print_r(array($_REQUEST, $_SERVER), true).'</pre>';
добавляйте какие хотите дополнительные параметры - они все будут.


P.S. А ошибку вызывает что-то другое.

Алексей, для такого правила вам не нужно ничего добавлять, все параметры и так придут.
Т.е.: #^/gospel/pericope/([0-9]+)/([0-9]+)/#
вполне достаточно

А вот если у вас ссылка такого шаблона /gospel/pericope/([0-9]+)/([0-9]+).php

тогда вот такое правило должно быть:
#^/gospel/pericope/([0-9]+)/([0-9]+)\.php.*#

Или я не совсем понял вашу проблему?

Вам нужно смотреть в АПИ пользовательских полей главного модуля, а не инфоблоков.

http://dev.1c-bitrix.ru/api_help/main/reference/cuserfieldenum/getlist.php

[QUOTE]Сергей пишет:
так как мне добавить и сделать обязательным поле "Организация"? неужели это так сложно?[/QUOTE]
Для начала я бы подумал, а действительно ли нужно выводить это поле при регистрации, а тем более делать его обязательным. Критерии оценки необходимости здесь такие: если работоспособность и цель разработки сайта без этого поля не потеряют, то его можно смело убирать.
В противном случае, нужно кастомизировать компонент оформления заказа, но возможность зарегистрироваться без этого поля на сайте все равно останется. Либо, как более простой вариант, закрыть страницу оформления заказа для незарегистрированных, тогда компонент оформления заказа кастомизировать не нужно будет. Но в любом случае придется кастомизировать саму систему авторизациии, для этого нужно будет изменить .default-шаблон компонента bitrix:system.auth.registration, в него добавить вызов компонента bitrix:main.register, который будет уже выводить форму с нужными вам полями.
Если сайт многошаблонный, то шаблоны компонентов системы авторизации лучше выносить в .default-шаблон сайта. Дополнительные сложности возникнут, если в системе задействована еще и многосайтовость, но эту тему я опущу.

[QUOTE]Дмитрий Яковенко пишет:
Используйте настраиваемую регистрацию, компонент bitrix:main.register[/QUOTE]
bitrix:main.register здесь не поможет, т.к. форма регистрации вшита прямо в компонент оформления заказа.
Вообще, все, что связано с кастомизацией регистрации в битриксе достаточно трудоемкая процедура и требует хорошего понимания системы, чтобы сделать ее правильно.

[QUOTE]Dmitry Ban пишет:
Поправка, htmlspecialcharsEx.[/QUOTE]
Согласен. Но в данной ситуации это не имеет значения.

[QUOTE]Максим Задубин пишет:
а что такого битрикс делает со строкой что ее потом никак не вытащить? [/QUOTE]
Он ее приводит к безопасному виду, делает htmlspecialchars().

[QUOTE]Максим Задубин пишет:
я и stripslahses и htmlspecialchars и addslashes жанглиролвал по всякому - 0 эффекта[/QUOTE]
А нужно было попоробовать функцию битрикса htmlspecialcharsback().