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

Интерволга писала свой коннектор для MSSQL. Оттуда можно подчерпнуть много полезной информации.

В сторону кастомизации шаблона умного фильтра. В итоге все равно писать туда

Артём, вообще, фрагмент должен работать

Извините, что-то повело меня.
Скорее всего это отчет об ошибках отправки писем, а не об ошибках доставки.

cosmopit, попробуйте посмотреть в файле "/bitrix/modules/sale/ru/reports/order_form.php" - давно не работал с печатными формами, но очень похоже

Борис М., да вроде правильно

Артём, а если сделать на странице var_dump($arResult['DETAIL_PICTURE']['SRC']); то что выведет? Такое ощущение что пусто там

Ну так вроде как его и показывает.
Мол было отправлено 5, из них 2 с ошибкой (спам и т.п.). Вот в поле 2 и будет с ошибкой.

Как насчет создания собственного автоматизированных обработчиков службы доставки

Павел Леонидович, судя по коду, Вы запоминаете информацию о каждом заказе. Естественно память будет расти

Борис М., а что именно Вы хотите? Сколько почтовых ящиков было в рассылке? Сколько из них не ушло?

Евгений Шутов, ну так собери из catalog.section, catalog.sections + urlrewrite, не?

Зачем в CSR тип сервера? Непонимаю.


Указывайте nginx

Что? Зачем Вам в своем же модуле ловить события своего же модуля?



За что именно?



Вы же Сами указали эту ссылку.
Читайте внимательнее примечание:
1) Вы подписываетесь на событие компонента! OnSaleComponentOrderOneStepFinal, это не событие entity!
2) sprintf он использует в определенном месте и в определенный момент. LocalRedirect, который переводит пользователя, не ждет загрузки исполнения скриптов, а значит код на echo в случае с подпиской на entity не сработает

Не смотря на то, что Битрикс в некоторых моментах говорит о MVC, это всего лишь паттерн, а не обязательная стратегия поведения.
Если сравнивать с общедоступными паттернами, то скорее всего это больше похоже на HMVC. Но что есть, то есть и class.php + ajax жизненный цикл должны отчасти решить эту проблему.


Все верно, но не совсем так. Есть AJAX запросы на подгрузку html части, которые обрабатываются так же, но обнуляют буферизацию вывода в самом компоненте.
Есть некоторые части системы, которые взаимодействуют с /*/tools/ или services и там уже подключается только служебная части.

НО! Ни одна логика не зашита в самом шаблоне!



Нет, данная страница находится в шаблоне компонента: confirm.php

Тонкости работы компонента в режиме ajax. Первый хит на оформление заказа, затем редирект на ок-страницу для утверждения/оплаты.



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

Памятуя о Вашем примере оформления заказа - echo не должно быть на событии сохранения заказа.


1) Есть служебные скрипты которые подключаются при вызове шаблона компонента
2) Есть Asset'ы которые подключаются из любого места
3) В конце концов есть добавление в самом шаблоне/компоненте.

Где-то на странице есть код который вызывает или наборот при ready-событии на dom срабатывают биндеры


А вы открывали код этого ajax?
Он всего лишь записывает просмотр товара пользователем

Из дел счета не создаются

Обратитесь к разработчику - он умышленно (может по согласованию, может по незнанию) нарушил "естественный порядок вещей" в оформлении страницы, что и привело к таким последствиями при редактировании страницы.

Либо редактируйте параметры в коде, либо просите разработчика прописать так, чтобы изменения публичной части не ломали верстку.
Не исключено что потребуются дополнительные средства (т.е. Вы за эту работу заплатите).

Теоретически ничего не мешает, однако в таком случае есть вероятность что битрикс побьет вашу самописку.
Все же лучше на отдельном сервере и сделать поддомен

В init.php прописать подключение классов, для хардкодов.

Толерантный способ - подключить composer, установить библиотеку из composer и подключить в init.php автолоадер composer'a.
Тогда и другие пакеты сразу подтянуться.

И не должен Вы неправильно подписались на события, да еще и не на все события)

Вот работающий фрагмент (версия чуть по старше, но она не изменилась, размещать так же в init.php):



Да какие могут быть требования?
1) Правильно подписаться (чтобы оно сработало)
2) Быстро отработать (т.к. пользователь ждет ответа на запрос, никаких тяжелых операций там быть не должно)
3) Предусмотреть все варианты входных параметров (очень часто ошибаются с новыми хендлерами в d7 и после обновления элемента)

Имеешь ввиду административную форму? или та что в публичной части?
Административную можно - в b_user_options есть сериализованная структура настроек этой формы.

Не поясните цитату?

Алексей Иванчук,

1) Зацикливание
2) PHP - static

Алексей Иванчук, прописал код:



И у меня получилось

Алексей Иванчук, в коде вы оперируете $propertyCollection, который возникает из ниоткуда.

Давайте разберем Вашу логику.
0) Вы подписываетесь на событие OnSaleOrderBeforeSaved (перед сохроанением заказа)
1) На вход функции поступает переменная $event, несущая в себе экземпляр Bitrix\Main\Event
2) Из $event Вы получаете все параметры ($parameters) получая методом getParameters() на объекте $event
3) Из $parameters по ключу ENTITY Вы получаете $order
До этого момента все казалось бы логично.

Затем внезапно появляется $propertyCollection, на котором Вы пытаетесь вызвать метод getItemByOrderPropertyId, яро полагая что у пустоты есть этот метод (как бы не так)) и после - вызываете метод сохранения, зацикливая события само на себе.

Лицензионные пользователи, не имеют ничего общего с установленными модулями.
Т.е. удаления модулей не повлияет на количество линцензионных пользователей