Все-таки выглядело как косяк браузера, и вот похоже разработчики подтвердили, что это так.
Цитата
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 каких-то версий, но свои заметки уже с трудом интерпретирую
Alex Zverev написал: Решили проблему? Не вижу что поддержка хоть как-то реагирует.
Все, что выяснил, написал в , который примерно об этом и явно более популярный (особенно если обратить внимание, что ответов здесь не было совсем), поэтому я тоже что-то писал. В нашем случае было дело в nginx-е и пробрасывании правильных портов. Если ваш тайминг какой-то регулярный, смотрите timestamp в косноли браузера между рассоединениями, мне собственно это помогло понять, что время совпадало с дефалтовым временем nginx-а
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, чтобы корректно относиться к заказам недефалтового сайта?
У нас в CRM-коробке периодически возникает пересоединение с сервером как в фронтенде, так и в виджетах (чат). То есть все нормально, но с паузой от пары минут до большего числа минут может возникнуть полоса "Отсутствует соединение с сервером", сменяющаяся "Соединение с сервером установлено". Если в этот момент что-то критичное было (входящий Voximplant звонок или сообщение ответное), то может на какое-то время быть неотзывчивым (а звонящему сообщают, что . Также иногда это влияет на срабатывание очереди по сотрудникам, которые должны отвечать.
В настройках Push&Pull выбран "Виртуальная машина 7.1 и выше (Bitrix Push server)".Документация на "Bitrix Push server" (aka NodeJS во многих постах) довольно скудная. Написано, что идет вместе с виртуальной машиной и должно работать из коробки. Штатная проверка у нас выдавала Socket-ошибки и последующие тоже. Оказалось, что сценарий с установленным сертификатом только на сайт в данном случае не подходит, обязательно чтобы была цепочка сертификатов. Браузеры с одиноким сертификатом работают, потому что поддерживают свой кэш доверенных, а для функционала "битрикса" этого оказалось недостаточно. После установки полной цепочки вся проверка сайта выдается на ура. Субъективно вроде стало лучше, но пересоединения все равно есть.
Ведь есть еще вопрос с портами. У нас портал за гейтвеем, поэтому по пробороске не http/https портов нужно решать в индивидуальном режиме. С этой точки зрения пугает широкие требования к UDP-портам, которые видимо в документации еще от nginx-push сервера идут (ну и понятно, что они для Voximplant-а нужны, но там хотя бы от ip-адресов входящих можно разрешить широкий диапазон). Нужны они в случае "Bitrix Push server" для обмена сообщениями или достаточно, чтобы 443 запросы корректно пробрасывались?
Спасибо
Подключение стороннего 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, таким образом поведение штатного отключения и этого приема было хотя бы отчасти сходно и скорее всего не было бы проблем с платежными системами.
Или может быть есть какой-то другой, более правильный способ посайтового отключения, который не создает опосредованных проблем типа этой платежной?
Похоже на 18.06.2018 для версии "1С-Битрикс: Корпоративный портал 18.0.0" настройка двух строчек в dbconn.php работает (без нее жуть-жуткая со смешанным контентом). Неужели эта ветка этого форума теперь единственное место, делящееся этим сокровенным знанием?
Тема давняя, но поиск решения проблем приводит и к давним тоже. По-прежнему корректная работа виджетов по https в коробочном Битрикс24 требует изменения в dbconn.php или это должно работать без дополнительных действий низкого уровня?
