Вообще в открытом виде хранить/передавать пароли считается плохой практикой. Есть же альтернативы, более безопасные.
Первая — отладить процесс восстановления пароля, чтобы на это уходило не больше пары минут. Если покупатель вернется в магазин, и его попросят авторизоваться, то вряд ли это его оттолкнет.
Вторая альтернатива, которая лично мне кажется очень удобной — на странице "Спасибо, ваш заказ №123 успешно оформлен" вывести сообщение "вы можете установить пароль, чтобы оформлять заказы стало еще удобнее", и вывести форму с единственным полем для пароля. В результате покупатель сможет установить свой любимый qwerty123 вместо случайного автоматического пароля.
Откуда парсеру url знать, что my-awesome-tovar это символьный код товара, а не раздела? Попробуйте видоизменить шаблон адреса для товара, например так: #SITE_DIR#/catalog/good/#ELEMENT_CODE#/
Внесу 5 копеек: При разработке самописного компонента столкнулся с той же проблемой, помогла полная очистка файлов кеша, без дополнительного шаманства.
Не поленился даже залезть в код этого компонента. Там никаких намеков на кеширование нет. Это и логично, что кешировать в форме авторизации? Так что очень странно, что он "просит кеша". Я бы на вашем месте не беспокоился на этот счет.
А чем вам модуль не угодил? Если хотите закрыть доступ к магазину, это можно сделать, закрыв некоторые разделы публичной части. Например /catalog/ /personal/basket/ /personal/order/
По пункту 3: Чтобы символьные коды разделов не повторялись, можно в настройках инфоблока включить проверку кода на уникальность. Ну а для уже имеющихся разделов коды нужно поправить. Приписать ИД раздела спереди, к примеру. Будет так: /razdel_1/123-podrazdel/ /razdel_2/456-podrazdel/
В штатный функционал битрикса вроде бы не входит. Скорее всего появится в скором времени на маркетплейсе. Маркетплейс обычно чутко реагирует на новые фичи от Яндекса :-)
Попробуйте посмотреть в сторону настроек инфоблока каталога. Там есть поля с шаблонами для настройки URL. Если у вас там для обозначения разделов используется шаблон #SECTION_CODE#, то можете попробовать заменить его на #SECTION_CODE_PATH#.
#SECTION_CODE_PATH#, в отличие от #SECTION_CODE#, учитывает вложенность разделов.
Также в настройках комплексного компонента каталога проверьте, там тоже настройки ЧПУ имеются.
Попробуйте с модификатором поиграться. У вас сейчас знак вопроса стоит, сделайте например знак равенства. Если ничего не путаю, это строгий поиск. Будет так:
Этот метод вместо нужной страницы element выдает страницу detail. В ядро не полез, решил проблему в лоб: создал в шаблоне компонента файл detail.php, куда вписал следующую строчку:
Код
require('element.php');
В итоге при любом раскладе подключится файл element.php, и сопутствующие компоненты.
Приветствую всех. Ситуация следующая, делаю каталог на стандартном комплексном компоненте. В разделах необходимо выводить навигационную цепочку. С названиями пунктов и ссылками все прекрасно, html-разметка самой цепочки тоже в порядке (кастомизировал шаблон компонента bitrix:breadcrumb).
Вывод цепочки мне нужно осуществлять на странице раздела, т.е. в файле template.php компонента catalog.section. Файл template.php начинается примерно так:
И тут начинается самое интересное — html-разметка цепочки вместе с названием секции (<div class="name"><?=$arResult['NAME']?></div> ;) отображается в верхней части страницы, до основного контента, а именно прямо после тега <body>
Нутром чую, что дело здесь в отложенных функциях и буферизации, но как с этим разобраться идей пока нет.
Самое интересное, что если вывести вызов компонента цепочки из шаблона компонента куда-нибудь в индексный файл, то она отображается правильно, там где и должна быть. Я бы так и сделал, но мне не позволяет так сделать макет.
Проблема замечена мной не впервые, ранее я решал ее, создавая цепочку вручную, без использования компонента. Но хочется все же разобраться в данном вопросе.
Собственно на приведенном выше скриншоте и жду. Провел несложный опыт, вручную сбросил количество товара в ноль, в результате в каталоге для данного товара пропала кнопка "Купить", и вывелось сообщение "Нет на складе". Так что именно с этим полем и нужно работать.
Версия битрикса 11.5.9. Насколько я понимаю, функционал складского учета реализован начиная с версии 12.5.0.
Поэтому я захожу в форму редактирования нужного товара, кручу вниз до параметров торгового каталога, там вкладка "Параметры", с полем "Количество на складе" и флажок "Уменьшать количество при заказе" (см. скриншот).
Сразу к делу: есть некий товар, количество на складе — 20, галочка "Уменьшать количество при заказе" проставлена.
Кидаю в корзину этот товар в количестве 2 шт., оформляю заказ.
В итоге заказ оформлен, а количество товара на складе по прежнему 20.
При этом, если отменить заказ через админку, количество на складе увеличится на 2 шт.
Оформление заказа на стандартном компоненте sale.basket.order.ajax.
Никто не сталкивался с подобной проблемой? Понимаю, что решить можно, вручную прописав изменение количества уже после оформления заказа, но это костыль, которого хотелось бы избежать.
Приветствую всех. Суть задачи такова — в некоем самописном компоненте есть параметры "Показывать количество записей" и "Показывать количество, даже если записей нет". Естественно, если мы отключаем первый параметр, то второй нам в общем-то и не нужен, и пользователя только будет запутывать. Поэтому хотелось бы его скрывать.
Реализовал это следующим образом: в файле .parameters.php для первого параметра указал ключ REFRESH => Y, т.е. изменение этого чекбокса будет обновлять форму. Далее отлавливаем, установлен ли первый параметр несложной проверкой if ($arCurrentValues['SHOW_COUNT'] == 'Y'), и если он установлен, добавляем в массив $arComponentParameters второй параметр.
Все работает прекрасно, за исключением того, что тратится некоторое время на ajax-обновление формы.
Меня интересует вопрос, нет ли других способов решить данную задачу? Например использовать скрипты, и блокировать второй чекбокс если не проставлен первый.
Событие OnOrderUpdate срабатывает перед изменением заказа, Событие OnOrderUpdate аналогично OnBeforeOrderUpdate срабатывает перез изменением заказа, а не после
Строчку CSaleOrder::Update($ID, $arFields); в функции Package() писать не нужно.
Обработчики событий служат для модификации полей, т.е. обработчик сработал, изменил поля и сам вызвал функцию Update. А когда вы вызываете Update вручную, снова подгружается этот же обработчик. Отсюда и рекурсия.
Вот так должно прокатить:
function Package($ID, &$arFields) { $arFields['USER_ID'] = $arOrder["USER_ID"]; }
Ссылки на сторонние ресурсы можно регулярными выражениями отловить. С ненормативной лексикой сложнее, в принципе есть словари для фильтров, но искать в тексте комментария совпадения с элементами словаря — довольно долго, с учетом красочности нашего великого и могучего
Самый надежный способ — модерация / премодерация комментариев. Сделайте так: при добавлении комментария, запись в инфоблоке неактивна, а вам уходит письмо с уведомлением о новом комменте. Читаете, активируете, если он цензурный.
Вызывается перед отправкой письма о новом заказе, может быть использовано для модификации данных, изменения идентификатора типа почтового события, по которому будет осуществлена отправка, и отмены отправки письма.
Алгоритм будет такой: 1. Перехватываем это событие в init.php 2. Вытаскиваем нужные данные по ID заказа (например содержимое корзины) 3. Изменяем нужным нам образом массив полей arFields
На странице "Типы почтовых событий" (/bitrix/admin/type_admin.php?lang=ru) отыщи тип почтового события, к которому относится шаблон, который ты правишь. Перейди к редактированию этого типа. Там есть поле "Описание", в котором перечислены все макросы. Можешь добавлять произвольное количество своих макросов, по аналогии с тем, что там уже есть. Потом сможешь их использовать в шаблоне.