Форум

А где код самого агента?

Для повторного запуска он должен возвращать свой вызов, т.е. последней строкой агента должно быть echo "[COLOR=#219161]Agent_Oneway::Add();"[/COLOR]

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

Так у вас обработчик не вызовется. Вы ссылаетесь на класс, а надо на метод.

AddEventHandler("iblock", "OnAfterIBlockElementAdd", Array("MyClassAddPhoto", "OnAfterIBlockElementAddHandler")); или вытаскивайте функцию из класса.



$arIBlockElement = GetIBlockElement($arFields["ID"]);  уже лишнее, у вас все те же данные приходят в $arFields, его и используйте.

Алексей, вы как-то странно реагируете... Никто подробностей вашей задачи не знает, мы со Станиславом предлагаем решение в общем виде. Вы так и делаете по сути, но с отличиями в деталях, но все неправы оказываются. Ну успехов, конечно...

Честно говоря, у вас муть получилась...
1. Вы правите модули, а это неверно и в вашей задаче совсем не нужно.
2. вы прогоняете все обработчики, привязанные на ваше событие добавления в инфоблок, но сами новый обработчик не создали
3. событие ADD_NEW_PHOTO создали или просто такое имя придумали? если создали, то шаблон привязали?
3. вызываете функцию отправки CSaleMobileOrderPush::send, которая здесь вообще никаким боком...

Концепцию вообще меняйте. Модуль трогать не надо. Создайте почтовое событие, на него почтовый шаблон, затем вешайте обработчик на событие OnAfterIBlockElementAdd, в котором вызываете ваше почтовое событие, если добавление было в выбранный инфоблок-галерею.

Добавьте в ваш вызываемый кроном скрипт обработки еще и выборку элементов. Например, отсортируйте по ID, последний обработанный запоминайте в COption. Сам так делал, когда надо большой массив данных кусками обработать.

C 1C не работал, но подозреваю, что ваш обработчик синхронизации должен вызывать стандартные функции, т.е. у вас выстрелит событие OnSaleBeforeStatusOrder или  OnSaleStatusOrder, привяжите на него свой обработчик и скиньте в лог, что у вас на входе.

Схем такая:
1. Создаете новое почтовое событие с нужными вам полями.
2. Создаете привязанный к этому почтовому событию шаблон
3. Отключаете стандартный шаблон
4. Вешаете обработчик на нужное событие (в вашем случае OnStatusUpdate модуля sale), в котором заполняете поля события нужными вам данными.
5. В обработчике вызываете вами созданное событие.

Где-то на форуме это уже все в деталях не один раз обсуждалось.

Инесса, в моем коде именно так все и происходит. И писал я его не под вас, т.е. у самого так же все работает. Просто понимаю, что это неправильно, но поделать с собой ничего не могу.
По опыту пользователи, подписанные принудительно на рассылку, редко отписываются, чаще нажимают на кнопку "спам", благо в большинстве клиентов она на виду. А с учетом облачных технологий, несколько таких нажатий от нескольких пользователей, и вашу рассылку больше не видит никто из пользователей этого почтового сервиса.
Сознательно подписавшиеся на рассылку так себя не ведут, поэтому в долгосрочной перспективе честная работа с подписчиками выгоднее. Но быстро набрать почтовую базу проще так, как вы планируете сделать, конечно. Но и потерять ее также просто, причем сразу почти всю. Например, gmail складывает рассылки в отдельную папку, а если несколько пользователей пожалуются, то сразу в спам, да еще и предупреждение вешает, что имейте в виду, другие пользователи жаловались! И чтобы получать такие письма в инбокс адресату придется заносить ваш адрес в белый список. А многие будут это делать?.. Так что подходите к решению взвешенно.
Эпоха почтового маркетинга прошла с развитием антиспам-технологий. Ориентируйтесь в доставке своих материалов до клиентов лучше на соц. сети, они дают гораздо больший отклик на сегодня.

Дмитрий, задача похожа, но в вашем коде идет более правильная работа с подпиской, пользователь все же должен подтвердить свое желание получать подписку. Инесса хочет подписать зарегистрированных принудительно :)