была у меня в закладках хорошая статейка, а щас вот открыл - а ее нет:( хорошо, хоть у гугла есть сохраненная копия страницы. автор, простите за репост без подписи ...
В веб-окружении Битрикса по-умолчанию стоит msmtp для отправки писем. Если ваш домен привязан к Яндекс.Почте для домена, и вы хотите отправлять почту через реально существующий почтовый ящик с авторизацией, вам придётся внести в файл конфигурации некоторые изменения, чтобы всё работало хорошо.
Файл /home/bitrix/.msmtprc:
account default
logfile /var/log/msmtp.log
host smtp.yandex.ru #(smtp.gmail.com - для гугла) #
port 587 # именно этот порт! #lkz гугля рекомендуют ставить 465, хотя в просторах сети читал, что и 587 подходит ...#
from robot@domain.ru
keepbcc on
auth on
user robot@domain.ru
password <password>
tls on
tls_starttls on # обязательно для Яндекс.ПДД
tls_certcheck off
И не задавайте слишком длинных паролей.
P.S: при работе с GMail вторую строку (tls_starttls) наоборот включать не нужно.
UPDATE 2014-09-08
полный файлик с настройками для gmail:
account default
logfile /var/log/msmtp.log
host smtp.gmail.com
port 587
from user@gmail.com
auth on
user user@gmail.com
password password
tls on
tls_starttls on
tls_certcheck off
keepbcc on
для корректности настройки можно выполнить из сервера команду:
php -r "mail('test@email.com', 'Test', 'Test');"
UPDATE 2014-12-02
Для проверки из сайта, в командную строку можно ввести код:
if (mail("moe_mylo@gmail.com","test subject", "test body","From: otpravitel@bitrix.ru"))
echo "Сообщение передано функции mail, проверьте почту в ящике.";
else
echo "Функция mail не работает, свяжитесь с администрацией хостинга.";
Только email-адресы ставьте ваши
P.P.P.S Перенес инструкцию (вместе с дополнениями) себе на сайт
Настроил через сервер smtp.yandex.ru, почта уходит но почему то если приходит на gmail то попадает в спам, а отправителем стоит EMPTY-FROM конфиг такой
# smtp account configuration for default
account default
logfile /home/bitrix/msmtp_default.log
host smtp.yandex.ru
port 587
from simple@yandex.ru
keepbcc on
auth on
user simple@yandex.ru
password XXXXXXXXX
tls on
tls_starttls on
tls_certcheck off
Часто возникают вопросы производительности проектов на базе "1С-Битрикс", для решения которых нет необходимости прибегать к "экстремальным методам". Чтобы, помочь в решении таких проблем, особенно разработчикам только начинающим работать с "1С-Битрикс", рассмотрим пример оптимизации "некой" страницы информационного сайта. Для этого будем использовать только встроенный в продукт инструментарий.
И так, что мы имеем:
VMBitrix (512M памяти)
инфоблок новостей ~12600, в каждой новости заполнен анонс, детальная информация, название, теги и ряд свойств
страница с 2-мя компонентами news.list, которые выводят два блока новостей (топ 0 - 10 шт и обычные - 10 шт).
топ новости, не должны попадать в обычные
разделение на топ и обычные новости происходит при помощи числового свойства MAIN_NEWS
при выводе новостей проверяется период активности, ежедневно добавляется 5 - 10 новостей
Характерны следующие проблемы:
тяжёлая фильтрация по дате активности
кэширование в период максимальной нагрузки не может полностью закрыть проблему производительности. Так как, обычно в этот же момент происходит довольно частый сброс кэша, после добавления новостей, их изменения или при других событиях (добавление комментариев, оценок и.т.д.). Поэтому необходимо добиться быстрой генерации страницы без использования кэширования.
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (7) AND UPPER(BP.CODE)=UPPER('PHONE')
таким образом если мы достаем 20 свойств то получаем 20 запросов к таблице b_iblock_property для одного компонента, а если на странице 5 компонентов то это уже 100 запросов.
Вопрос к разработчикам: Почему бы получение описания свойств внутри одного запроса GetList не объединить в один запрос который получает описание сразу всех нужных свойств?
В тикете 66176 подымался данный вопрос, но предлагалось только кешировать эти запросы что не оптимально.
Что значит "+" это какая-то устаревшая терминология? Обычные инфоблоки, которые в 14 версии не highload, которые как раз в таблицах b_iblock_property, b_iblock
Эта технология называется Инфоблоки 2.0. В документации к Bitrix Framework, в сообщениях форума на сайте компании и в других местах могут встречаться прежние названия технологии: инфоблоки +.
Вначале немного представлюсь. Меня зовут Рыжонин Николай, в "1С-Битрикс" я курирую направление производительности продуктов компании. Если у вас есть вопросы, предложения или пожелания, касающиеся производительности, обращайтесь e-mail: rns@bitrix.ru
Данная тема уже не раз подымалась (например тут), но тем не менее все таки решил опубликовать обобщенное решения для выполнения всех агентов из под cron.
Для начала полностью отключим выполнение агентов на хите. Для этого выполним следующую команду в php консоли.
После этого все агенты и отправка системных событий будут обрабатывается из под cron, раз в 5 минут. Чтобы не увеличивалась очередь отправки почтовых сообщений, советую изменить параметр отвечающий за количество почтовых событий обрабатываемых за раз. Для этого выполняем в php консоли следующую команду
Сделал по инструкции, при ручном запуске файла выдаёт ошибку: PHP Parse error: syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' in /bitrix/modules/main/lib/loader.php on line 578
Силуянов Александр, Да. Так и будет, потому что с 99% вероятностью Вам нужен не crontab root`а, crontab пользователя под которым установлена система. Чаще всего это bitrix, но может быть что угодно. В зависимости от того как установили. У меня это название сайта. Тогда команда должна выглядеть так: crontab -u <имя_пользователя> -e Где -u - это ключ вызывающий crontab конкретного пользователя -e - это ключ, который говорит о том, что Вы хотите его отредактировать. Если хотите через nano, то должно быть так EDITOR=nano crontab -u <имя_пользователя> -e
На одном своем проекте обнаружил следующую проблему. Время генерации страниц было от 1.3 до 2.4 (причем никаких тяжелых компонентов нет.) Что бы убедиться, что это не мои кривые руки не компоненты, - создал пустой шаблон.
Обнаружил, что даже на пустом шаблоне, 90% нагрузки идет на Эпилог-Ядро
Нагуглил на форумах битрикса подобные вопросы. В частности, эта тема мне помогла. В итоге, удалил я модуль bitrixcloud, и мои страницы теперь отдаются веселей - 0.085 сек.
Калашнов Антон написал: Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Нет, для этих целей надо запретить отгрузку каких-либо тестовых скриптов в продуктивную среду. Тестовым скриптам место лишь в тестовой среде.
Если же речь идет о служебных механизмах, то те из них, которые могут быть запущены из терминала, следует располагать выше корневой директории сайта. Те же, что предназначены к запуску из браузера, следует размещать в административной части сайта с соответствующими проверками прав доступа.
Apache — это, по большому счёту, такой рудемент уже. И держится он только потому, что много в мире виртуальных хостингов, на которых .htaccess решает. Ну и всяких специфических расширений к нему куча (если уж случилась ситуация, что такое расширение нужно — тут да, тут без вариантов Apache).
Представим, что мы на собственном сервере, на котором имеются все возможности доступа к конфигурации. Тогда что нам мешает полностью избавиться от Apache в пользу nginx? Мне не помешало ничего
Далее я просто приведу пару подводных камней и путей из обхода, с которыми пришлось столкнуться при переходе.
Собственно, основная проблема только с ЧПУ, с тем, как его настроить. Решается просто:
server {
...
if (!-e $request_filename) {
rewrite ^(.*)$ /bitrix/urlrewrite.php last;
}
location ~ \.php$ {
if (!-f $request_filename) {
rewrite ^(.*)/index.php$ $1/ redirect;
}
...
}
...
}
Далее, наткнулся на ограничение максимального размера заголовка. Возможно, это я такой везучий, но так уж случилось у меня с настройками по умолчанию, поэтому, думаю, может и у других быть. Я решил проблему на уровне всего сервера:
Если для решения проблемы "Got error 139 from storage engine" вы воспользоваться советов приведенным в посте Инфоблоки+ и "Got error 139 from storage engine" у вас может возникнуть следующая проблема:
При работе в базе разваливается одна из таблиц при этом в логи сервера БД валяться ошибки с сообщением 'нет доступа к странице xxx возможно она повреждена или удалена' (нет оригинала сообщения поэтому вольная интерпритация).
При этом база в общем то работает и даже из поврежденной таблици можно вытащить всю информацию кроме конкретной записи и того что после нее.
Данная ошибка возникает из за того что после увеличения страницы памяти при пересборке мускуля видимо отключается или перестает корректно работать проверка на максимальную длину строки таблицы. Таким образом если у вас теоретически при заполнение все полей эта вставка будет больше 32 кБ произойдет описанная выше ошибка.
Чтобы избежать ее небходимо:
1. для инфоблоков с большим количеством свойств проверить не превышает ли теоретически они этот предел (в таблицах b_iblock_element_prop_xxs).
2. ну и делать чаще дамп
Если же произошла ошибка то помогает только удаление целиком таблици и восстановление ее из дампа либо того что удалось вытащить, но лучше при возникновении этой ошибки удалить и восстановить целиком базу так как иногда наблюдался "пост эффект" (аналогичная ошибка на других таблицах на которых она теоретически не должна была появляться).
В целом же если учесть это и в проверить то других ошибок не возникает, база работает стабильно.
А что если, например, сделать одно множественное свойство для текстовых характеристик?
Так-то да. Но: - там ограничение на 255 символов - есть ряд свойств, обладающие списочными значениями (например,, тот же размер колес из примера выше редактору проще выбирать из списка)
В общем с одной стороны да, можно закастомизировать свой тип свойств со всякими рюшечками, но очень сильно будет жать ограничение символов.
В PostgreSQL кластеризация работает из коробки. Недавно была задачка на VPS с весьма low-end характеристиками установить Битрикс и Zabbix в одном флаконе. Для Битрикса использовалась Percona XtraDB. После старта сервера Zabbix, сервер перконы ложился напочь. Ok. Пусть Битрикс живёт со своей Percona, а Zabbix мы отправим в SQLite. Заработало. Но (ессно) медленно. Ok. Поставим рядом PostgreSQL и пусть Zabbix работает с PostgreSQL, а Битрикс со своей перконой. И вот тут всё сложилось: все работают, никто не тормозит. Возникает вопрос: почему бесплатный Zabbix можно поставить и на SQLite, и на MySQL, и на PostgreSQL, и на Oracle, и на IBM DB2, а в Битрикс надо выбирать между MySQL и Oracle? При том что PostgreSQL оказывается явно производительней хвалёных форков MySQL "из коробки" и всё это происходит на фоне воплей об импортозамещении? Вопрос риторический, ответов не жду..
Коллеги, в связи с подготовкой к выпуску в одном из ближайших обновлений Главного модуля, встроенного механизма оптимизации CSS файлов, решил опубликовать краткий анонс данного функционала.
Скорость отображения страницы браузером пользователя зависит, как непосредственно от времени генерации на сервере, так и от скорости загрузки браузером пользователя. Тут возникает ряд проблем, которые и призван решить новый функционал главного модуля.
браузеры создают ограниченное количество параллельных запросов к одному хосту
при разработке продукта в идеологии Битрикса, создается большое количество мелких css файлов
IE имеет ограничение на количество подключаемых внешних CSS файлов
Для решения данных проблем многие разработчики в ручную переносили стили компонентов в стили шаблонов сайтов. Данный подход обладает рядом минусов:
теряется целостность компонентов/шаблонов компонентов, что усложняет перенос компонент/шаблонов между сайтами или разными проектами
усложняется работа с компонентами и их шаблонами
Новый функционал позволяет автоматизировать данный процесс, и лишен приведенных выше недостатков. Для его включения необходимо в настройках главного модуля установить галочку «Объединять CSS файлы шаблонов в один файл».
С этого момента ядро начнет собирать объединенный файл стилей сайта, по мере открытия пользователями разных страниц сайта. При этом для каждого шаблона сайта создается следующие файлы стилей:
объединенный файл стилей шаблонов компонент
объединенные файлы стилей шаблонов компонент для IE (с учетом ограничения на количество селекторов в одном файле)
объединенный файл стилей для шаблонов сайта (styles.css, template_styles.css)
Объединенный файл стилей, после того как соберет все стили используемые в данном шаблоне сайта, заново не формируется. За исключением случая изменения одного из файла стилей который входит в его состав, в этом случае «накопление» объединенного файла стилей начинается заново.
результат объединения сss стилей (print.css и colors.css не объединялись, так как явно прописаны в шаблоне)
Дополнительным бонусом является возможность формировать уже сжатую копию объединенного файла стилей. Данная возможность позволяет отдавать файлы стилей в сжатом виде (например при помощи nginx и mod_gzip_static) не сжимая их на лету. Для этого необходимо в настройках главного модуля включить «Создавать сжатую копию объединенного файла CSS » а также настроить nginx:
gzip_static on;
gzip_http_version 1.0;
в результате скорость отдачи файлов стилей увеличивается на порядок: без сжатия
Server Software: nginx/0.7.67 Document Path: /bitrix/cache/css/s1/light_red_styles.css?1307718092 Document Length: 199325 bytes Time taken for tests: 27.775 seconds Requests per second: 36.00 [#/sec] (mean) Transfer rate: 7017.45 [Kbytes/sec] received
с сжатием
Server Software: nginx/0.7.67 Document Path: /bitrix/cache/css/s1/light_red_styles.css?1307718092 Document Length: 153107 bytes Time taken for tests: 2.236 seconds Requests per second: 447.29 [#/sec] (mean) Transfer rate: 67002.39 [Kbytes/sec] received
Важно! Включая данный функционал на своем проекте вы должны понимать, что в виду того что все стили используемых шаблонов компонент объединяются, возможно возникновение ситуации пересечения стилей из разных шаблонов. Учитывая это вы должны для всех шаблонов создавать уникальное название стилей, при соблюдение этого правила верстка вашего сайта не пострадает.
При редактировании css файла в шаблоне, изменений на сайте не происходит, т.к. стили тянутся с /bitrix/cache/css. Сброс кеша в битриксе и в браузере не помагает. Как очистить кеш и сделать, чтобы новые стили применялись?
Товарищи разработчики, у кого свои собственные сайты на битриксе, и кто пишет статьи по своей работе, я, наконец-то, поднял свой сайт, начал собирать на него все свои наработки и, о ужас!, на то, чтобы из блога перенести свою статью на сайт, уходит огромное количество времени из-за махинаций по выводу html- и php-кода
Отсюда у меня вопрос - каким образом вы вставляете код в текст? Я уж думал, завести множественное доп.свойство и кидать куски кода в него, а потому уже в публичке с помощью регулярных выражений, выводить этот код пользователю, что, тоже геморройно, да и не рационально
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».