для сторонних модулей (и даже частично включенных от битрикса типа bitrix.learningtemplates) после перехода с php7 на php8 у нас возникла ошибка во вкладке Обновление решений (update_system_partner.php) с текстом .... Ошибка описания модуля ... (Ux11).... если гуглить, то по этим ключевым словам успешно ищутся за предыдущие годы посты и веб-страницы где описывается почему такое может возникать. Но в нашем случае оказалось, что есть очень много "дремлющих" модулей, которые нигде не проявляются, но их insall/index.php логика все равно срабатывает и как я понимаю, есть "старый" способ интродукции модуля через метод function {mynamespace.mymodule} и он в php7 работал, поэтому все эти дремлющие, давно не обновляемые не конфликтовали, а в php8 он почему-то этот способ запрещен и требуется делать это (по новому?) через __construct. Выяснил я это случайно через гугление по этой ошибке с недавней датой и на странице какого-то модуля в маркерплейсе разработчик пишет, что нужно поменять {mynamespace.mymodule}->__construct чтобы обновление этого решения и других решений снова стало работать.
Я у нас пробежал все эти дремлющие и исправил, заработало. Но... у меня ощущение, что это мина замедленного действия (если разработчики битрикса не позволят модулям представлять себя "по старому"). То есть многие пользователи битрикса после перехода php7->php8 даже и не зайдут на страницу обновления сторонних решений, все будет вроде работать, а когда через некоторое время потребуется что-то обновить, они войдут и обнаружат эту ошибку. Причем я еще понимаю, что отмазка, что битрикс не отвечает за действия сторонних разработчиков в силе (а разрабочикам видимо сказано было делать по новому уже давно). Но то, что мне даже в bitrix.learningtemplates пришлось это исправлять, а там явно сказано кто хозяин [ $this->PARTNER_URI = ""; ], это значит даже в самом битриксе не до конца это пофиксили
Можно ли в битрикс реализовать поддержку "чистого" звонка ip-телефонии без использования обычных телефонных номеров?
Самый простой пример - виджет на сайте для звонка в CRM. Решений, которые ставят виджет (работающий по WebRTC) и не берут деньги, если это без использования обычной связи - много, ну или по крайней мере несколько есть. Но чтобы прикрутить их к битриксу, все равно придется как я понял, делать крюк через обычный номер, voximplant, оплату минут итд. Или можно как-то сделать так, чтобы битрикс и сотрудники в браузере смогли принимать такой звонок, а CRM их учитывала по обычной логике учета звонков и при этом не задействовать обычные телефонные каналы?
Столкнулись со следующей проблемой. Модуль обмена стоял не самый новый (Комплексная автоматизация 2). В цепочке обновления конфигурации (КА 2), на одном этапе стало понятно, что при переходе 2.4.13.282 -> 2.5.7.269 старый модуль обмена имеет ссылки на удаляемый объект (РегистрНакопления.СвободныеОстатки), поэтому пришлось сделать апгрейд модуля обмена. И я его сделал до последнего (7.0.2.5), но который заявлен как предназначенный для 2.5.7.226. Модуль встал без проблем. Но дальше при попытках обновить конфигурацию 2.4.13.282 до 2.4.14.64 или 2.4.14.78 в первом запуске клиента после обновления конфигурации (после диалога подтверждения легальности) возникает ошибка, не дающая запустить клиент.
Цитата
Тип не определен РегистрСведенийНаборЗаписей.РаспределениеЗапасов
То, что это имеет отношение к модулю обмена помог выяснить партнер, указав конкретную строку в модуле Б_ОбменССайтомСервер
Цитата
ИЛИ ТипОбъекта = Тип(РегистрСведенийНаборЗаписей.РаспределениеЗапасов")
которую надо закоментировать, чтобы ошибку преодолеть
Понятно, что в частном случае вопрос, как нам лучше поступить (не хочется делать локальное исправление, если потом может выйти боком), а в общем случае вопрос, можем ли мы расчитывать на работоспособность модуля обмена, когда он "обгоняет" версию решения или нужно строго параллельно цепочке обновления конфигурации ставить аккуратно модули обмена, не перегоняя версию решения. То есть в нашем случае, поставить сначала 7.0.1.41 (предназначенный для 2.4.13.57). И если это так, хотелось бы ссылку на документацию, которую я возможно пропустил.
Спасибо
Особенность генерации img с srcset в битрикс и связанные проблемы в Chrome-е
Все-таки выглядело как косяк браузера, и вот похоже разработчики подтвердили, что это так.
Цитата
This is caused by the AvoidDownloadIfHigherDensityResourceIsInCache heuristic (combined with the preloader) which will cause us to think that the 2x alternative is already available/downloaded and use that.
Кэш упомянут, теперь скорее всего понятно, почему блоки лендингов с fancybox-галереей иногда увеличенные картинки не показывали.
Цитата
Виталий Соков написал: Наверное, больше шансов уговорить Битрикс пофиксить код.
Еще вчера я бы с Вами на все сто согласился, но вот ведь как...
Особенность генерации img с srcset в битрикс и связанные проблемы в Chrome-е
Прежде чем мучить поддержку, хотел посоветоваться со спецами, кто знает или замечал.
В двух проблемных местах (одном - анимированный gif, другой - галерея на fancybox), заметил, что битрикс часто отдает в тег img на атрибуты src и на srcset с масштабом 2x один и тот же файл. Последствия примерно те, что в firefox все всегда нормально, а в chrome-е проблемы с масштабированием (gif-ка меньше, чем если бы здесь был обычный статический файл) или кэшированием (fancybox галерея, всплывающая картинка часто не показывается).
Чтобы вне битрикса увидеть, что браузеры по разному себя ведут, просто тест. Текущие FF (Developer) и Chrome (пользовательский) рендерят по разному следующий код <html><head></head> <body> <img src="testpicture.jpg" srcset="testpicture.jpg 2x"> </body></html>
(testpicture.jpg можете любой подставить) Результат - в FF картинка как есть, в Chrome-е картинка в два раза меньше.
То есть не исключено, что спецификация не определяет, как должны вести себя браузеры, если то, что заявлено как двойной масштаб, оказывается таким же, вот и получаем разницу.
И вот вопрос, кого нужно уговаривать пофиксить код, Битрикс или Google?
При импорте компаний (вместе с реквизитами "Организация"), столкнулись в тем, что если в некоторых записях данные отсутствуют (например, "корпоративный сайт"), то импорт недоволен и не пропускает такую запись (Отсутствуют значения ключевых полей). Если передавать прочерк, то он доволен. Такое исправление нежелательно, но в крайнем случае пошло бы, но... Для e-mail прочерк не срабатывает по причине не прохождения проверки на корректный e-mail. Есть ли работающий способ передавать пропуски? Я исхожу из того, что если при редактировании карточки необязательно заполнять все поля, то и импорт вроде бы должен это поддерживать
Мне казалось, что самый первый вопрос туда был простой. Кинул скриншот из хэлпа битрикса, где показал, что наши лендинги были сделаны с помощью иконки "Сайты24" в админке, после апгрейда мы ее не видим, это нормально? На этот вопрос поддержка перенаправила нас на инженера, с которым мы совсем не совпадаем по времени уже много дней.
А ведь от ответа на этот простой вопрос зависят наши действия, которые возможно даже не требуют использования ценного времени инженеров битрикса.
Варианты ответов:
"Да, должна, функциональность БУС-Сайты24 мы из ИМ+CRM не убирали и не планируем". Вывод: что-то не так в нашей конфигурации, будем искать.
"Нет, функциональность БУС-Сайты24 теперь отстутствует в ИМ+CRM, но ваши лендинги должны были переехать в часть CRM-Сайты24". Вывод: импорт-экспорт не сработал, возможно нам придется вручную переносить лендинги.
"Нет, функциональность БУС-Сайты24 теперь отстутствует, а то, что лендинги исчезают - это техническая особенность, просто явно она нигде не озвучена. Экспорт-импорт на автомате не предусмотрен". Вывод: возможно придется заново верстать лендинги, а возможно какое-то время существовать в состоянии хака (см. выше)
Может кто-то квалифицированно ответить на этот вопрос?
Проапгрейдились до ИМ+CRM (Интернет-магазин + CRM) со стороны БУСа (Управление сайтом), столкнулись с тем, что Лендинги (Сайты24), которые были сделаны в БУСе и настроены на отдельные домены (смешанным, не совсем многодоменным приемом), перестали работать (Сайт не найден) и конструктор лендингов в админке БУСа перестал видиться, лендинги не оказались также после апгрейда в Сайтах на стороне CRM. Поддержка пока молчит, поэтому возможно пока не признан багрепорт, здесь скорее обсуждение.
Фоновая информация. У нас есть еще Коробочный CRM, самый младший участник Bitrix24 в коробке, поэтому Сайты24 мы и там поробовали, в том числе обнаружив принципиальную разницу. В портале они хостятся на bitrix24.site и как следствие иногда могут тормозить по внутренним причинам этого сайта, и как легальное следствие, требуют активной лицензии для существования. Лендинги в БУСе же согласно нашим наблюдениям, шаблоны и заготовки свои берут удаленно, но потом копируют их локально. В силу этой разницы, я не был удивлен, что наши лендинги не перекочевали из БУСа в CRM, ведь это потребовало бы сложную операцию экспорта из локала - импорта в удаленку.
Расследование показало, что многие php-шки битрикса общие для БУСа и портала и иногда ветвятся в логике по понятным причинам, ориентируюясь на результат метода \Bitrix\Landing\Manager::isB24. И собственно до апгрейда результат его был false, после - true. Соответственно "поехали" как минимум две вещи
Вычисление сайта (по http запросу и домену) в \bitrix\components\bitrix\landing.pub\class.php. Из-за этого для двух работающих лендингах на доменов у нас стал появляться "Сайт не найден"
Показ кнопки лендинг-конструктора в \bitrix\modules\landing\admin\menu.php. Из-за этого в админке нигде не видно наших лендингов. Если найти в старых записях ссылку на редактор лендингов с концовкой landing_site.php , то редактор можно увидеть без кнопки, но видно, что менюшных контекст потерян в этом случае.
Если там и там немного подправить (Вызов forceB24disable в одном случае, удаление преждевременного return в другом), Сайты24 в БУСовом варианте возвращаются и их можно редактировать вроде бы, хотя есть некоторые визуальные странности.
Наверное мы можем использовать этот хак для наших сайтов какое-то время, но хотелось бы выяснить, планируются ли Сайты24 (БУС вариант) к возврату в ИМ+CRM или нет. Хочется надеется, что да, учитывая утверждение генерального в презентации, что битрикс позаботился о том, чтобы сайты после апгрейда продолжили работу. А лендинги - это все-таки сайты, учитывая, что можно завести новый, выбрав шаблон Landing 24. Возможно, кто-то решил, что два места с лендингами в новом продукте - это слишком для среднестатистической головы, но о текущих клиентах, мне кажется, тоже нужно помнить.
Спасибо
Виджет на сайте и конфликт скриптов с родным окружением
Ок, выкладываю два файла () Если в вашей системе другая версия mootools, то все это может и не заработать. Поэтому пользуйтесь с осторожностью и всегда бэкаптесь .
Со следующим текстом внутри (текст в архиве содержит пару синтаксических ошибок
Цитата
Изменение mootools-файлов версии 1.4.5, чтобы они не конфликтовали с полифилом виджетов Битрикс24
Суть изменения - завести копию Array.from как Array.convert и заменить внутренние вызовы mootools с Array.from на Array.convert, чтобы mootools всегда пользовался этой копией, а не полифилом Array.from, идущим от Битрикса. Необходимость этого связана с тем, что Array.from, появившийся в стандарте считает переданный нулевой объект ошибкой, а ранние версии Array.from от mootools не считали это ошибкой.
Пример замены в случае Joomla 2.5 (в вашей cms может быть другая логика расположения) Необходимо в папке \media\system\js Заменить файлы mootools-core.js mootools-more.js
Виджет на сайте и конфликт скриптов с родным окружением
Пришло личное сообщение (мгновенное сообщение) от пользователя с похожей проблемой, но это сообщение в профиле отсутствует, так что ответить могу только здесь (надеясь, что пользователь Игорь подписался)
Для одного сайта рецепт примерно такой. Правка mootools, поэтому это должен быть необновляемый сайт, где mootools точно никто не подменит
Внутри mootools заводим копию Array.from как Array.convert (то есть полная копия тела функции, но с другим названием) и везде внутри mootools меняем вызовы Array.from на Array.convert. Тем самым библиотека становится привязана к своей реализации Array.from (не из полифила). Что-то у меня помечено как особая проблема с IE каких-то версий, но свои заметки уже с трудом интерпретирую
Dmirtiy Karasev написал: Коллеги, подскажите эти самые строчки, которые надо добавить в dbconn.php чтобы виджеты работали по https.
Судя по нашим настройкам $SERVER_PORT = $_SERVER["SERVER_PORT"] = 443; $HTTP_HOST = $_SERVER["HTTP_HOST"] = {хост вашего корпоративного сайта без протокола (http или https)};
видимо после этого пересоздать виджеты и заново скопировать их код на сайты. Интересно, оригинальный постер все свои посты удалил, это какая-то обида? Без его вопроса и реплик как-то контекст дискуссии теряется.
Виджет на сайте и конфликт скриптов с родным окружением
"Виджет на сайт", круглая кнопка внизу хостовой страницы с показом запроса по e-mail, чата и прочего, что в crm-е настроено. У которой небольшой скрипт копируется после настройки и по рекомендации вставляется перед закрывающим тегом </body>. Сам фрагмент указывает на скрипт типа loader_2_aw54m5.js , а он в свою очередь грузит /bitrix/js/imopenlines_widget/script.js , который содержит кроме прочего набор полифилов из разных источников
Виджет на сайте и конфликт скриптов с родным окружением
в данном случае mottols переопределяет методы полифилов bitrix
Я бы сказал наоборот. Виджет битрикса - "гость" на сайте, его скрипт переопределяет функцию Array.from, которая как я уже упоминал, вообще давно создана в mootools, и к наступлению ES6 стала стандартом, но со своими особенностями.
Еще добавлю технических подробностей.
Mootools как минимум 1.4.5 до 1.5.2 имеет следующую реализацию Array.from
Как видно, по undefined будет возвращен [] (то, что undefined == null можно проверить в консоли)
По поводу изменений в 1.6.0 (
Цитата
Array.from deprecated, now called Array.convert: Following the conclusion of the ES6 specs we know now that Array.from will have a different implementation than the one MooTools uses.Because of this we renamed Array.from to Array.convert to not overwrite the Native implementation. We kept it as it was though in the compat layer for compatibility reasons if you really to use it still.
Но как я упоминал, резкий upgrade mootools на сайте ради виджета битриска - слишком опасное действие.
Фрагмент полифила, который используется в битриксе (оригинал, из которого сжатый script.js сделан). Это та реализация Array.from, которая начинает работать для всей страницы, когда скрипт виджета полностью исполняется.
А здесь видно, что arrayLike сразу приводится к Object, и в том же исходнике можно дойти до вызова цепочке throw TypeError("Can't call method on " + it); в случае undefined. Что мы и получаем на наших сайтах (Can't call method on undefined) Пока склоняюсь в текущей версии mootools сделать то, что они сделали в 1.6.0 - заменить Array.from на Array.convert. Вернее сделать Array.convert для всех внутренних вызовов mootools.
Виджет на сайте и конфликт скриптов с родным окружением
Александр Медведев написал: То есть конфликт скриптов битрикса со скриптами джумлы?
Можно сказать, что скриптов битрикса со скриптами mootools, исполняемыми в контексте джумлы и ее расширений.Хронологически было так, что виджеты были установлены осенью, все работало, потом в новом году начались глюки, которые оказались связаны с виджетом, который стал работать по другой логике начиная с какого-то update-а.
Виджет на сайте и конфликт скриптов с родным окружением
Александр Медведев написал: По идее полифил не должен ничего делать, если браузер итак это умеет.
В чём конкретно конфликт?
По идее да, но я своими глазами видел на joomla-странице дебаггер заходит в Array.from от битрикса из кода, не имеющего отношения к битриксу.
Конфликт ранних скриптов, которые прерываются по первому throw exception (который из-за Array.from(undefined). Соответственно какие-то ссылки недогружены, недоработают, итд.
Виджет на сайте и конфликт скриптов с родным окружением
Из коробки crm используем "виджет на сайт", который пару месяцев как стал конфликтовать с парой сайтов, оба joomla, но версии разные, с разным набором модулей. Поддержка просто говорит о конфликте скриптов. Но все-таки провели расследование и ситуация такая вырисовывается.
Виджет коробки видимо пару месяцев как перешел на полный полифил видимо в свете упоминания в документации, что с 2019 года везде будут новые скрипты только ES6. Но если бы это была проблема страниц, показываемых коробкой, то и ладно, но включенный в конец body скрипт по сути перехватывает все, что только можно и начинает следовать стандарту ES6, как для своего кода, так и остального кода страницы.
Что в итоге. Оказалось, что в случае обоих сайтов, проблема как минимум возникла вокруг Array.from, если ему передан undefined. Судя по всем, это функция, которую изобрели в mootools, и ее в итоге перетащили в стандарт ES6. Но в mootools он по undefined всегда возвращал []. В битриксе этот полифил взят из библиотеки core-js, он сразу на параметр вызывает toObject, что предсказуемо по стандарту генерирует exception. Но не сомневаюсь, что за все время существования Array.from в mootools с таким поведением накопилось немало кода, который не расчитывает, что ему по undefined дадут в глаз, при этом часть этого кода находится внутри mootools. Из того, что я увидел у нас на сайтах, например, если используются классы в понимании mootools (... new Class ()...) и у класса не будет определена переименная Binds, то она пройдет через внутренний код mootools с вызовом Array.from(undefined)
Mootools 1.6, на фоне перехода Array.from в стандарт заменили на Array.convert вызовы. В принципе мы можем на сайтах попробовать на него заменить, но необдуманный upgrade крупной библиотеки может породить новые проблемы.
Другой вариант - мы можем попробовать подкорректировать все места, где может вызваться Array.from(undefined), но их может быть много и неявных. Поэтому вопросы такие возникают:
Прав ли автор core-js в том, что он Array.from(undefined) не приводит к []. Я честно говоря не нашел однозначного ответа про ES6. Я вижу, что в битриксе коробке используется версия core-js 2.5.*, сейчас на github у автора 3.0.0, но кажется код Array.from не изменился.
Может ли битрикс реализовать на полную, а условную отдачу полифила, например основываясь на User-Agent. Я подозреваю, что генерить script.js на лету никто не будет, но можно хотя бы капитально отсекать всех, кто сидит на свежем браузере и не передавать им полифил совсем. Я сильно подозреваю, что если полифил к коробке был добавлен в последние месяцы, то число сайтов со вставками виджета, где что-то не так стало работать, будет разрастаться.
Может быть есть какая-то хитрость еще, чтобы избежать массового срабатывания полифила на родительской странице?
Спасибо
Сделать шаблон компонента как небольшое изменение другого кастомизированного шаблона
Прямая кастомизация шаблона компонента понятна, есть документация.
Но в ситуации, когда нужно сделать еще один шаг, непонятно как эффективно поступить. То есть есть кастомизированный шаблон вывода компонента ШаблонВывода, нужно создать еще один, который использует максимум функционала ШаблонаВывода, переопределив небольшое количество файлов.
Самое прямое решение - полностью скопировать ШаблонВывода в новое имя (папку). Но это очень избыточно. Иногда хочется изменить небольшую часть и оставить остальное официально обновляемым (в нашем случае речь об изменении шаблона вывода купленного решения, поэтому здесь имеется в виду обновление решения, не битрикса). Другое решение приходит в голову - создать в своей папке все "официальные" файлы (например для каталога element.php, section.php и прочее) и добавить туда вставку php-файлов соответствующих из того шаблона, который хотим изменить. Но здесь нет уверенности, что прием гарантированно сохранит нужный контекст, и другие проблемы возможны, технические и логические.
Есть ли какой-то более удобный способ или кто-то что-то подобное реализовывал и выработал алгоритм работы?
Так как по гуглению [site:1c-bitrix.ru WebSocket 1006] в мировом разуем только эта страница, наречем ее мини базой знаний
У нас Bitrix Push server (aka NodeJS) тоже работал с этой ошибкой. Все привело к тому, что нужно правильно настраивать гейтвей, если виртуальная машина битрикс живет за NAT-ом. В нашем случае nginx. Чтобы работал WebSocket, настраиваем правильную секцию upgrade ( ). Проверять можно по Chrome-у, он должен зацепить в network-секции средств разработчика WS соединение и показывать, что на запрос ответ получен и соединение живо.Был тайм-аут, который в нашем случае крутился вокруг 75 секунд. Это подозрительно совпадает с дефалтовым keepalive_timeout у nginx-а (), но увеличение явно не помогло. Но зато помог proxy_read_timeout, при этом если его поставить скажем 300 секунд (5 минут), то видно, что код страницы стучится домой (на сервер) где-то раз в четыре минуты, поэтому 5 минут никогда не иссякают.
Лучше бы конечно документация упоминала особенности связанные с житием за гейтвеем и NAT-ом.
Должны ли оплаты корректно работать на недефалтовом сайте
Речь на примере о платежных системах, ссылка на оплату через которые в битрикс-магазине может появляться в разных местах (сразу после оформления, в кабинете, при смене способа оплаты). Обратил внимание, что часто сторонние разработчики шаблонов не до конца отрабатывают то, чтобы ссылки оставались в подпути магазина, поэтому частенько они ссылаются на /personal корня, что конечно не является проблемой в случае дефлатового сайта, но приводит к ошибке "заказ не найден", если сайт недефалтовый. При этом я даже два сценария некорректного формирования ссылки заметил на eshop-е (Современном магазине от битрикса). Все это так или иначе это правится, если добраться до нужных php override-ов и прочего. Но ... есть результат платежной системы (/bitrix/tools/sale_ps_result.php), прописанный в нашем случае в настройках yandex-кассы. Видно, что у него нет подсайта в url-е, но я сильно расчитывал, что ему приходит id заказа и ему все равно, это заказ дефалтового сайта или нет. Но тесты показывают, что ему не все равно, то есть статус оплаченности меняется на успешный только для дефалтового сайта.
Соответственно вопрос главный - сценарий сосуществования нескольких магазинов на мультисайтовости официально поддерживается? Если да, то что нужно скрипту sale_ps_result.php, чтобы корректно относиться к заказам недефалтового сайта?
Спасибо
Подключение стороннего jQuery-плагина к странице "Сайты24"
Есть pdf-листалка (Real3d jQuery), реализованная как jQuery plugin, пытаюсь вставить его в одну из страниц "Сайты24"
Общая логика от разработчика (работающая в его примерах) такая 1. В Head добавляем jQuery <script src="; 2. В Head добавляем его инициализатор <script src="..../flipbook.min.js"></script> 3. По концу загрузки DOM от jQuery вставляем инициализацию объекта <script type="text/javascript"> $(document).ready(function () { $("#container").flipBook({ ... </script> 4. В Body в нужном нам месте заводим div с id="container", например <div style="position:relative;width:100%;height:700px"> <div id="container" style="position:absolute;width:100%;height:100%"> </div> </div>
Пытаюсь реализовать это через расширенные дела "Сайтов24", то есть
1. все, что нужно вставить в Head (пункты 1, 2, 3) в свойствах страницы "Сайтов24" в пользовательский Script/css вставляю, 2. div контейнера (пункт 4) - через html-блок внутри самой страницы определяю место, где плагин будет показывать листалку.
Итог: никакой листалки и ошибка javascript "flipBook is not a function"
Сам разработчик в комментах по поводу этой ошибки говорит, что так может быть, если скрипт не подключен или кто-то снес хуки функций jQuery. Что скрипт подключается - точно, я оттуда в лог сообщения отладочные кидаю. А кто может сносить хуки функций - непонятно.
При этом сразу после включения flipbook.min.js проверка console.log("flipBookAccess type is: " + typeof ($("#container").flipBook)); возвращает, что это функция, но тот же вызов внутри $(document).ready возвращает undefined
Есть одно решение, но оно не очень нравится, так как не объясняет проблемы. Если включение <script src="..../flipbook.min.js"> перенести в html блок, который непосредственно в body создается, то создание объекта в ready начинает работать.
В чем тут может быть проблема?
Заранее спасибо.
Отправить "маркетинговый" e-mail шаблон по обычному почтовому событию
В битриксе по сути два места где e-mail-ы создаются и определяются - почтовые события сайта и Маркетинг. Но они как-то плохо сочетаются. В маркетинге полная верстка с предпросмотром, но их можно отправлять только по событиям маркетинговым в контексте рассылок (штук пять-шесть). Можно ли как-то все-таки письма из Маркетинга подключить на отправку основных событий сайта, то есть всяких "Регистрация пользователя", "Изменение статуса", и прочих? Или может быть подключить расширенный редактор маркетинговых писем к обычным письмам?
Проблема в том, что если я, что зная про html как таковой, особенности html e-mail-ов в разных почтовиках, могу ручным "шитьем" добиться нужного результата в обычных почтовых шаблонах, то обычному редактору нужен визивиг, берущий все эти проблемы на себя, но такой есть только в "маркетинге".
Спасибо
Правильный способ публичного отключения одного из сайтов
Вопросы про публичное отключение одного из сайтов здесь неоднократно задавались. Есть в итоге официальный совет на странице , но с ним есть засада. Там используется хэндлер по PrologBefore и как следствие оказалось, что скрипт ответа платежной системы (в нашем случае yandex-касса, но похоже для других тоже) sale_ps_result.php умирает если применить этот прием (у скрипта ответа есть require(.... /prolog_before.php") . При этом штатное отключение публичной части для всех сайтов не вызывает такой проблемы, судя по всему потому, что его die находится в PrologAfter, который скриптом ответа платежной системы не используется совсем.
Проблема была обойдена использованием анализа $_SERVER['SCRIPT_FILENAME'] на соответствие имени файла sale_ps_result.php, но осадок остался.
В данном случае немного странно, что тот, кто описывал этот хак на битриксовском сайте, не использовал PrologAfter, таким образом поведение штатного отключения и этого приема было хотя бы отчасти сходно и скорее всего не было бы проблем с платежными системами.
Или может быть есть какой-то другой, более правильный способ посайтового отключения, который не создает опосредованных проблем типа этой платежной?
