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

Сам и отвечаю)) - сменил php с 7.4 на 8.1 и все заработало.

В чем может быть причина? Обмен происходит, товары меняются, в логах 1С - данные успешно обработаны сервером. А событие не вызывается - в init.php пишу обработчик просто в лог написать что событие вызвано - нет ничего в логах после обмена.

Посмотрите в настройках апача какая директория прописана в php_admin_value upload_tmp_dir и существует ли она и доступна ли на запись.

Если по каким-то причинам невозможно добраться до настроек, попробуйте грузить картинки в инфоблок через медиабиблиотеку.

извините, недочитал, что "1С-Битрикс: Управление сайтом 16.5.8". Тогда не годится такой способ

разверните демо сайт и возьмите с него все что нужно

Тогда найдите js, который запускает ajax отправку формы и  в функции-коллбэке, которая запускается при успешном результате, вставьте эти строки. Если отправляется $.ajax, то это функция, которая в параметре success.

Вот как проще - "при успешной отправке выскакивает просто попап" - найдите в js место, где открывается этот попап, это как раз и будет нужный коллбэк и добавьте туда  рядом с вызовом попапа ваши строки.

Зависит от того, как обрабатываются результаты этих форм - компонентом веб-формы или своим скриптом с перезагрузкой страницы или своим скриптом без перезагрузки (аяксом)

Торговые предложения

подпишитесь на событие  Bitrix\Sender\MailingTable::OnAdd и в обработчике отправляйте купон

непонятно, что вы имеете в виду. Что вы моделировали случай, задавая жестко $oldStocks пустым, а не выборкой и все равно этот кусок скрипта каким-то чудом удалял все элементы при том, что цикл не выполнялся и CIBlockElement::Delete не вызывался?


обратите внимание, что если $productId у вас пустой, то выберутся все элементы инфоблока.

Эксперименты показали, что причина в моем случае с высокой степенью вероятности в том, что хилый VPS с 1 гигом памяти слабоват для нагрузки, которую создает задача апгрейда-даунгрейда php. Что там внутри происходит, то ли технологии виртуализации убивают какие-то процессы, которые грузят систему выше лимита, то ли еще что - тонкости этой темы от меня далеки - но увеличение параметров vps в 2 раза до 2 гигов памяти и процессорного лимита от этой проблемы вроде избавляют.

что-то вы остановились на самом интересном. Тоже столкнулся в первый раз с тем, что ни в dbconn, ни в ,settings.php после восстановления нет паролей логинов.Терять лишнее время на то, чтобы лезть каждый раз командной строкой в mysql не хочется. поделились бы ответом.
PS Извините, в ,settings.php все есть, не туда посмотрел. Тогда неважен этот вопрос.

привести в рабочее состояние ладно, восстановил снапшот системы вчерашний. Но почему это и что делать, чтобы этого не было - актуально.
Есть подозрение, что из-за слабенького сервера - 1 гиг оперативки. Может из-за этого быть?

опять то же самое с новым сервером. Действия

1) агрейд php 8.0, 8.1
2) попытка даунгрейда до 7.4 - error
3) даунгрейд до 8.0 - норм
4) попытка даунгрейда до 7.4 - error
5) Update server (bitrix)

результат There are servers that cannot be used!

Теперь на сервере лежит нужная копия.
Как привести в рабочее состояние? Что не так делал?

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

то есть редакция выше, например, бизнес, не нужна

можно. Никакие модули более старших редакций эту задачу не облегчат.

посмотрел на одном из клиентских сайтов - папка fff давно создана и заполнена, полет нормальный. Может, у вас и вправду что-то не то с временным каталогом для загрузки?

диагностировать проблему непросто, нужно глубоко копнуть, чтобы обнаружить, что на данном конкретном сайте мешает агенту отработать отправку писем с такими симптомами. У меня это был самописный скрипт импорта, но обнаружил я это экспериментально, так и не докопавшись до внутренней причины-конфликта. Причем, дело, похоже, не просто в загрузке системы - на другом сайте штатный модуль обмена с 1С потребляет ресурсов гораздо больше и грузит систему до предела, но письма отправляются нормально.
Поэтому, не разобравшись в причинах, называть это багом движка было бы неправильно.
Если есть много времени, то можно попробовать докопаться до корня проблемы, причем, скорее всего, копать придется гораздо глубже и шире, чем просто функции ядра битрикса - придется и в системные дела и процессы и логи линукса погружаться. Они (агенты) ведь иногда отрабатывают (лостукиваются до msmtp), иногда нет, значит надо ловить момент, когда они не отработали и смотреть разные линуксовские логи на предмет того, что именно в этот момент времени происходило с разными процессами - что совпало и т.д. У обычных людей нет на это времени, поэтому применяют этот костыль как вариант решения (обхода) этой проблемы.

смотрите внимательно на шаблон и элементы, что шаблон в href вставляет - у вас этот атрибут пустой у второй галереи в отличие от первой. Скорее всего, в href идет детальная картинка, а в src превью. А во второй галерее у вас детальные, возможно, пустые, из-за этого такой результат будет.

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

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

Была такая же проблема, я склонился к тому, что виноват скрипт обновления каталога, импортирующий товар. Сильно и часто грузящий БД. Оптимизировал его + добавил по крону проверку последних записей таблицы b_event - если F, то обратно на N, чтобы пытаться с нескольких попыток отправить письмо. Вроде помогло, клиент не жалуется больше.