Идеи пользователя 158956

Проблема
Если отсылать почтовый шаблон типа html, то text часть письма генерируется неадекватно. Зачастую, оно содержит набор css стилей, а не читаемого кириллического текста:



Из-за этого сильно увеличивается вероятность попадания письма в спам. Потому что популярной спаморез "SpamAssassin" узнает несоответствие html и text части письма. И уменьшает "спам" рейтинг письма на полтора балла (это очень много) за неадекватную text часть (если быть точным сейчас на  -1.483 балла "MPART_ALT_DIFF_COUNT").
.
На текущий момент в битриксе нет возможности отправить письмо без особых доработок, в котором обе части (html,text) заданы вручную. Приходится делать шаблон сообщения типа text, вставлять туда обе части письма и при отправке в функции custom_mail добавлять заголовок:
Только так возможно задать обе части письма. И не потерять 1.5 балла в спам рейтинге.

Как исправить проблему?
Писал об этой проблеме в техподдержку в 2014 году. Они согласились, что беда. Прошло четыре года - задачи всё ещё стоит. Возможно, разработчики не хотят слишком сильно модифицировать систему стандартной отправки шаблонов. С другой стороны, на каждом проекте создавать функцию custom_mail - уже порядком надоело (уже 2018 год как бы...).

Поэтому предлагаю три "щадящих" способа решения проблемы. Чтобы не модифицировать БУС и при этом уйти от custom_mail...


1. Можно отремонтировать автоматическую генерацию text части письма для писем типа html. Но есть подозрение, что его создаёт не БУС, а сама функцию mail() в php. В любом случае, можно же перенести её создание на сторону БУС и отправлять multipart письма с адекватными частями, как сейчас делаем это через custom_mail().


2. Можно перед отправкой почтового шаблона делать проверку, есть ли в дополнительных параметрах ключ Content-type. Если есть, то не добавлять его перед отправкой. Тогда для создания письма с двумя частями: ставим шаблону тип text, в тело вставляем обе части (html/text) с boundary обрамлением и в дополнительных параметрах шаблона пишем:



На данный момент такое сделать невозможно. Потому что при отправке принудительно вставляется Content-Type:text последним заголовком (если выбран тип шаблона text). Вот если бы он заменялся на значение Content-Type из  additional_headers, то всё бы сработало.


3. Можно сделать событие (чтобы можно было сделать его обработчик), которое вызывается после добавления  Content-Type в дополнительные заголовки системой. Чтобы можно было вручную изменить значение Content-Type непосредственно перед отправкой.


И?
Сейчас на каждом проекте приходится создавать функцию custom_mail, чтобы отправлять письма html+text с адекватным содержанием. Автоматическая генерация text части письма типа html не работает, поэтому SpamAssassin нещадно режет письма на 1.5 балла.

Было бы хорошо сделать ссылку на странице редактирования элемента инфоблока (в административном разделе), которая ведёт на детальную страницу просмотра элемента в публичном разделе.

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

В WordPress, в административном разделе, есть ссылка "Просмотреть публикацию в публичном разделе/Перейти к публикации". И эта ссылка пользуется спросом. Часто замечаешь ошибки в контенте из публичной части, которых не замечал в админке.

Условия
Показывать ссылку возможно для тех инфоблоков, у которых в настройках задан "URL страницы детального просмотра:". Если этот URL не задан или элемент не активен, то ссылку можно не выводить.

Проблема

Кажется, я - единственный кто не знал как работает "управляемый кеш".
Давайте проверим знаете ли вы! А он работает так:
Если "управляемый кеш" включен (а это рекомендуется и он включен по умолчанию!), то при изменении/добавлении/удалении одного элемента инфоблока удаляются ВСЕ файлы кеша ВСЕХ элементов этого инфоблока. Не знали?
Техподдержка подтверждает - это действительно так и это не баг! И я единственный, кто чувствует дискомфорт от этого? Поделитесь в комментариях своим мнением!

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

Я обнаружил это свойство "управляемого кеша" когда нашёл большое количество файлов кеша в очереди на удаление (файлы с именем ".~" ) в папках
bitrix/cache/s1/bitrix/news.detail
bitrix/cache/s1/bitrix/news.list
Агенты на кроне (раз в минуту) не справлялись с удалением десятков тысяч файлов в очереди - проверьте может у вас тоже это заметно. Представляете какая нагрузка на файловую систему!?

Люди, скажите, только у меня одного такой резонанс случается, когда вижу как битрикс помечает на удаление десятки тысяч файлов валидного кеша!?

Как исправить

Мне кажется, "управляемый кеш" должен работать так:
При добавлении элемента должен создавать файл кеша (точнее при первом его вызове из компонента).
При изменении элемента должен маркироваться на удаление файл кеша ИЗМЕНЯЕМОГО элемента и далее при первом вызове из компонента будет создаваться новый файл кеша этого элемента.
При удалении элемента должен маркироваться на удаление только файл кеша УДАЛЯЕМОГО элемента.

Не должны ни в коем случае удаляться все файлы кеша всех элементов инфоблока. Я не могу представить себе ситуацию когда надо удалять ВСЕ валидные файлы кеша при добавлении/изменении/удалении ОДНОГО единственного элемента!

Если в мобильном приложении запрашивать через app.openBXTable список секций с использованием bitrix:eshopapp.sections, то по умолчанию в списке появляются изображения секций. Если изображений секций нет, то появляется изображение-заглушка "/bitrix/components/bitrix/eshopapp.sections/images/no_image.png" . Нужно сделать возможность не показывать ни изображения секций ни заглушки. Т.е. в app.openBXTable, в списке параметров TABLE_SETTINGS, передавать ещё один параметр, который бы запрещал показывать изображения секций.

Пожалуйста, добавьте возможность экспорта результатов SQL запроса.