Добрый день коллеги.
В общем не дождался я от Битрикса когда они внедрять свою либу маски для телефона в основную поставку своих JS. Напомню в чем проблема, стандартный плагин jquery mask работает криво на андроид устройствах, а именно скачет каретка. А у битрикса в веб-формах корпортала маска своя и работает она просто чудесно. Поэтому я решил ее ручками внедрить. Все кому это так же актуально, набросал тут небольшую статейку, как ее внедрить
|
Разработчикам |
Последние сообщения блогов
Нормальная маска ввода в форме. Будет работать и в андроид.
28.11.201713:0728.11.2017 13:07:27
Настройка Windows для веб разработки в 2017 году https://habrahabr.ru/post/343312/ (https://habrahabr.ru/post/343312/) Полезно о настройке VMware Player 7.x для работы в Unit режиме и не только. Bitrix VM 7.x не поддерживает Unit режим?
27.11.201723:0327.11.2017 23:03:49
Настройка Windows для веб разработки в 2017 году
Полезно о настройке VMware Player 7.x для работы в Unit режиме и не только.
Bitrix VM 7.x не поддерживает Unit режим?
Полезно о настройке VMware Player 7.x для работы в Unit режиме и не только.
Bitrix VM 7.x не поддерживает Unit режим?
Фото:
Создание и удаление сайта (CreateDelete site) в BitrixVM 7.x ======================== Способ №1 1) Авторизуемся под root в виртуальной машине битрикс 2) Переходим в меню "6. Manage Sites in the pool" => "1. Create site" 3) Сделуем в
26.11.201715:4226.11.2017 15:42:25
Создание и удаление сайта (CreateDelete site) в BitrixVM 7.x
========================
Способ №1
1) Авторизуемся под root в виртуальной машине битрикс
2) Переходим в меню "6. Manage Sites in the pool" => "1. Create site"
3) Сделуем всем этапам создания сайта (имя домена\директории сайта напр smallbusiness.loc, пользователя БД, имя БД, пароль от БД)
4) Запускаем текстовый редактор от имени администратора, жмем "файл => открыть" и вбиваем путь C:\Windows\System32\drivers\etc
5) Добавляем запись для адресации к сайту через IP нашего сервера BitrixVM: 192.168.0.5 smallbusiness.loc
6) В консоли выполняем команду перезагрузки сервера "reboot"
7) Перезапускаем браузер и набираем в адресной строке
========================
Способ №2
Если при с создании сайта из меню BitrixVM не создался виртуальный хост и сайт не работает.
Создаем сайт ext_kernel не из консоли виртуальной машины:
1) Устанавливаем права 777 на файл /root/bitrix-env/add_site.sh
2) Запускаем BitrixVM входим под root, и выходим из меню BitrixVM в корень сервера, и запускаем /root/bitrix-env/add_site.sh
3) Сделуем всем этапам создания сайта (имя домена\директории сайта напр smallbusiness.loc, пользователя БД, имя БД, пароль от БД)
4) Запускаем текстовый редактор от имени администратора, жмем "файл => открыть" и вбиваем путь C:\Windows\System32\drivers\etc
5) Добавляем запись для адресации к сайту через IP нашего сервера BitrixVM: 192.168.0.5 smallbusiness.loc
6) Устанавливаем права 644 на файл /root/bitrix-env/add_site.sh
7) В консоли выполняем команду перезагрузки сервера "reboot"
8 ) Перезапускаем браузер и набираем в адресной строке
P/S
Если вы создавали сайт ext_kernel по первому способу из меню виртуальной машины, и папка сайта создалась в /home/bitrix/ext_www/ то перед тем как создавать сайт способом №2 нужно удалить этот сайт.
Для начала попробуйте удалить из мею BitrixVM: "6. Manage Sites in the pool" > "2. Delete site",
и если не получится то выйдите из меню виртуальной машины и удалите командой из консоли вебсервера: rm -rf /home/bitrix/ext_www/smallbusiness.loc
========================
По теме:
kernel - в случае создания дополнительного сайта в рамках отдельной установки - отдельное ядро продукта «1С-Битрикс» в новой директории сайта.
ext_kernel - отдельное ядро продукта «1С-Битрикс» в новой директории сайта для создания линков на это ядро в рамках многосайтовости, ядро будет недоступно напрямую, а только через дополнительные сайты (работает в паре с сайтами типа link).
link - в случае создания дополнительного сайта в рамках многосайтовости - общее ядро и данные в общей базе с уже установленным продуктом «1С-Битрикс» (работает в паре с ядром ext_kernel).
========================
Способ №1
1) Авторизуемся под root в виртуальной машине битрикс
2) Переходим в меню "6. Manage Sites in the pool" => "1. Create site"
3) Сделуем всем этапам создания сайта (имя домена\директории сайта напр smallbusiness.loc, пользователя БД, имя БД, пароль от БД)
4) Запускаем текстовый редактор от имени администратора, жмем "файл => открыть" и вбиваем путь C:\Windows\System32\drivers\etc
5) Добавляем запись для адресации к сайту через IP нашего сервера BitrixVM: 192.168.0.5 smallbusiness.loc
6) В консоли выполняем команду перезагрузки сервера "reboot"
7) Перезапускаем браузер и набираем в адресной строке
========================
Способ №2
Если при с создании сайта из меню BitrixVM не создался виртуальный хост и сайт не работает.
Создаем сайт ext_kernel не из консоли виртуальной машины:
1) Устанавливаем права 777 на файл /root/bitrix-env/add_site.sh
2) Запускаем BitrixVM входим под root, и выходим из меню BitrixVM в корень сервера, и запускаем /root/bitrix-env/add_site.sh
3) Сделуем всем этапам создания сайта (имя домена\директории сайта напр smallbusiness.loc, пользователя БД, имя БД, пароль от БД)
4) Запускаем текстовый редактор от имени администратора, жмем "файл => открыть" и вбиваем путь C:\Windows\System32\drivers\etc
5) Добавляем запись для адресации к сайту через IP нашего сервера BitrixVM: 192.168.0.5 smallbusiness.loc
6) Устанавливаем права 644 на файл /root/bitrix-env/add_site.sh
7) В консоли выполняем команду перезагрузки сервера "reboot"
8 ) Перезапускаем браузер и набираем в адресной строке
P/S
Если вы создавали сайт ext_kernel по первому способу из меню виртуальной машины, и папка сайта создалась в /home/bitrix/ext_www/ то перед тем как создавать сайт способом №2 нужно удалить этот сайт.
Для начала попробуйте удалить из мею BitrixVM: "6. Manage Sites in the pool" > "2. Delete site",
и если не получится то выйдите из меню виртуальной машины и удалите командой из консоли вебсервера: rm -rf /home/bitrix/ext_www/smallbusiness.loc
========================
По теме:
kernel - в случае создания дополнительного сайта в рамках отдельной установки - отдельное ядро продукта «1С-Битрикс» в новой директории сайта.
ext_kernel - отдельное ядро продукта «1С-Битрикс» в новой директории сайта для создания линков на это ядро в рамках многосайтовости, ядро будет недоступно напрямую, а только через дополнительные сайты (работает в паре с сайтами типа link).
link - в случае создания дополнительного сайта в рамках многосайтовости - общее ядро и данные в общей базе с уже установленным продуктом «1С-Битрикс» (работает в паре с ядром ext_kernel).
Изменение логики для пользовательского поля типа «файл» в 17.5
25.11.201700:2325.11.2017 00:23:38
С определенной версии ядра (примерно с 17.5) для пользовательских полей типа «файл» была изменена логика.
Теперь, если требуется обновить поле, добавив туда ещё несколько файлов, недостаточно просто передать ID уже загруженных, необходимо ещё выполнить процедуру регистрации этих файлов.
Разберем подробнее.
1. Создаем для пользователя пользовательское поле типа «Файл», множественное
2. Загружаем в папку /upload/testfiles/ 3 картинки:
3. Выполняем код. У пользователя будут установлены 2 картинки
Если передать полю другое значение:
то все картинки будут перезалиты заново. В т.ч. изменяются их пути, что немаловажно.
4. Допустим, мы загрузили картинку 1 и 3
5. Через день хотим добавить ещё туда картинку 2.
Раньше такой код работал (на версии 17.0.9 еще работает):
У пользователя в поле UF_FILES получалось 3 файла: 2 существующих файла и 1 новый.
На последних версиях это уже не работает: Остается 2 файла, а внутри выдается ошибка.
Чтобы у пользователя стало 3 файла, необходимо зарегистрировать существующие:
где, USER-18-UF_FILES – Id контрола, который формируется из параметров поля:
Чтобы автоматически получить ID контрола, можно выполнить следующий код:
Возможно это баг. Или новая фича безопасности.
Техподдержка разбираться не стала: «В административной части сайта работает добавление файла, значит бага нет, а ошибка в вашем скрипте.»
Теперь, если требуется обновить поле, добавив туда ещё несколько файлов, недостаточно просто передать ID уже загруженных, необходимо ещё выполнить процедуру регистрации этих файлов.
Разберем подробнее.
1. Создаем для пользователя пользовательское поле типа «Файл», множественное
2. Загружаем в папку /upload/testfiles/ 3 картинки:
3. Выполняем код. У пользователя будут установлены 2 картинки
Если передать полю другое значение:
то все картинки будут перезалиты заново. В т.ч. изменяются их пути, что немаловажно.
4. Допустим, мы загрузили картинку 1 и 3
5. Через день хотим добавить ещё туда картинку 2.
Раньше такой код работал (на версии 17.0.9 еще работает):
У пользователя в поле UF_FILES получалось 3 файла: 2 существующих файла и 1 новый.
На последних версиях это уже не работает: Остается 2 файла, а внутри выдается ошибка.
Чтобы у пользователя стало 3 файла, необходимо зарегистрировать существующие:
где, USER-18-UF_FILES – Id контрола, который формируется из параметров поля:
Чтобы автоматически получить ID контрола, можно выполнить следующий код:
Возможно это баг. Или новая фича безопасности.
Техподдержка разбираться не стала: «В административной части сайта работает добавление файла, значит бага нет, а ошибка в вашем скрипте.»
Прикрепление файлов к письму на windows-1251
24.11.201722:3124.11.2017 22:31:34
Уже достаточно давно в продукте появилось поддержка прикрепления файлов к почтовым событиям.
Прикрепить файл просто: вызываем метод Bitrix\Main\Mail\Event::send, в ключе FILE передаем либо массив ID из базы, либо массив путей. В старом методе CEvent::Send, который по факту уже является оберткой для нового, указываем параметр $files (описан в документации).
При передаче путей, Битрикс предварительно сохраняет файлы в таблицу b_file с помощью CFile::SaveFile. Общая логика такая:
- Добавляется событие (b_event)
Сохраняются файлы в таблицу b_file (в случае указания путей)
Добавляется запись в таблицу b_event_attachment, которая содержит ID события (EVENT_ID) и ID файла (FILE_ID).
Агент рассылает письма, выбирая эти данные.
Пусть у нас есть:
- почтовое событие SOME_EVENT
почтовый шаблон для события SOME_EVENT с заранее заполненным полем «Кому»
два файла в корне file.jpg и file.jpg.
Следующий код успешно отправит письмо с 2 вложениями, но только на кодировке utf-8:
use Bitrix\Main\Mail\Event; Event::send([ "EVENT_NAME" => "SOME_EVENT", "LID" => "s1", "C_FIELDS" => [], "FILE" => [ $_SERVER["DOCUMENT_ROOT"]."/файл.jpg", $_SERVER["DOCUMENT_ROOT"]."/file.jpg" ] ); |
С windows-1251, в лучшем случае, в письме придет только один файл.
Необходимо правильно указать путь, так как кодировка сайта у нас windows-1251, а кодировка файловой системы – utf-8.
Полный код будет выглядеть следующим образом:
use \Bitrix\Main\Mail\Event; use \Bitrix\Main\IO; Event::send([ "EVENT_NAME" => "SOME_EVENT", "LID" => "s1", "C_FIELDS" => [], "FILE" => [ IO\Path::ConvertLogicalToPhysical($_SERVER["DOCUMENT_ROOT"]."/файл.jpg"), $_SERVER["DOCUMENT_ROOT"]."/file.jpg" ] ]); |
Стоит отметить, что Битрикс не выдает вообще никакой ошибки в первом варианте (когда CFile::SaveFile отработал некорректно), а просто заносит в таблицу b_event_attachment в поле FILE_ID значение 0.
C IO\Path::ConvertLogicalToPhysical файл сохраняется корректно.
Вроде бы задача решена. Но если мы попробуем сейчас выполнить этот код, то придет 2 файла:
«file.jpg» - нормальный, а «файл.jpg» с нулевой длиной.
Происходит это из-за бага, который есть внутри ядра. Тикет создан в феврале 2017 с категорией «Ошибки», пока исправления нет. Суть в том, что агент, который отправляет письма производит двойную конвертацию имени файла. Сначала в CFile::MakeFileArray, а затем в классе Bitrix\Main\Mail\Mail:: setAttachment при вызове Bitrix\Main\IO\File::getFileContents
«Исправляем» это:
- Открываем файл /bitrix/modules/main/lib/mail/mail.php
И вносим правки в ядро
, добавляя в метод setAttachment блок исключения:
Было:
try {
$fileContent = File::getFileContents($attachment["PATH"]);
} catch (\Exception $exception) {
$fileContent = '';
} |
Стало:
try {
$fileContent = File::getFileContents($attachment["PATH"]);
} catch (\Bitrix\Main\IO\FileNotFoundException $exception) {
try {
$fileContent = File::getFileContents(\Bitrix\Main\IO\Path::convertPhysicalToLogical($attachment["PATH"]));
} catch (\Exception $exception) {
$fileContent = '';
}
} catch (\Exception $exception) {
$fileContent = '';
} |
Т.е. если при попытке получить содержимое файла вывалилось исключение «Файл не найден», пробуем получить содержимое по сконвертированному в обратную сторону имени файла. Теперь все файлы отправляются
Повторяем черную пятницу или проводим своевременно.
23.11.201712:4723.11.2017 12:47:22
Уважаемые, коллеги, мы получаем ваши сообщения о повторе распродажи
В связи с тем, что завтра глобальная черная пятница, повторяем акцию
Для вашего удобства проводим с захватом двух рабочих дней (пятница+понедельник).
Правда, таких скидок как в прошлой акции
уже не будет, но все же
Примечание
1. Стоимость решения без учета стоимости лицензии Битрикс составляет 13000 рублей.
2. Даты, в течение которых будет действовать указанная в акции стоимость: с 24 ноября 2017 года по 27 ноября 2017 года включительно.
Пожалуйста, учитывайте данную информацию при планировании покупок.
В связи с тем, что завтра глобальная черная пятница, повторяем акцию
Для вашего удобства проводим с захватом двух рабочих дней (пятница+понедельник).
Правда, таких скидок как в прошлой акции
уже не будет, но все же
Примечание
1. Стоимость решения без учета стоимости лицензии Битрикс составляет 13000 рублей.
2. Даты, в течение которых будет действовать указанная в акции стоимость: с 24 ноября 2017 года по 27 ноября 2017 года включительно.
Пожалуйста, учитывайте данную информацию при планировании покупок.
Акция по распродаже решения BXReady: Флагман завершена
22.11.201709:1822.11.2017 09:18:42
20 ноября мы анонсировали начало акции
21 ноября акция стартовала, но в настоящий момент она завершена. (Цена старая пока только по техническим причинам)
Обратите внимание:
Все акционные комплекты проданы.
Сегодня после 23:55 московского времени цена решения будет изменена до 25000 рублей
Пожалуйста, не пишите нам обращения с просьбой пересмотреть условия акции и увеличить лимиты.
С одной стороны мы вас прекрасно понимаем, и мы еще вчера получили несколько таких обращений, просто поймите, что мы публиковали условия и несем ответственность.
Да и просто надо быть честными до конца.
Тем не менее, мы получили несколько доводов в пользу обращавшихся. Самый распространенный - физически бухгалтерия не может оплатить в срок до 24 часов из-за бизнес-процессов компании.
Поэтому, я обещаю, что сегодня мы подумаем над этими доводами и обращениями в индивидуальном порядке.
Ооднако,
Цены в 10000 рублей уже не будет. Это было ограниченное и исключительное предложение. Большое спасибо участникам акции за доверие к продукту и нашей компании.
По техническим и организационным причинам мы не можем переключить цену мгновенно, вы еще можете воспользоваться этим и приобрести решение по данной цене еще сегодня, но это скорее наш баг или недосмотр, чем исключение
21 ноября акция стартовала, но в настоящий момент она завершена. (Цена старая пока только по техническим причинам)
Обратите внимание:
Все акционные комплекты проданы.
Сегодня после 23:55 московского времени цена решения будет изменена до 25000 рублей
Пожалуйста, не пишите нам обращения с просьбой пересмотреть условия акции и увеличить лимиты.
С одной стороны мы вас прекрасно понимаем, и мы еще вчера получили несколько таких обращений, просто поймите, что мы публиковали условия и несем ответственность.
Да и просто надо быть честными до конца.
Тем не менее, мы получили несколько доводов в пользу обращавшихся. Самый распространенный - физически бухгалтерия не может оплатить в срок до 24 часов из-за бизнес-процессов компании.
Поэтому, я обещаю, что сегодня мы подумаем над этими доводами и обращениями в индивидуальном порядке.
Ооднако,
Цены в 10000 рублей уже не будет. Это было ограниченное и исключительное предложение. Большое спасибо участникам акции за доверие к продукту и нашей компании.
По техническим и организационным причинам мы не можем переключить цену мгновенно, вы еще можете воспользоваться этим и приобрести решение по данной цене еще сегодня, но это скорее наш баг или недосмотр, чем исключение
Получение параметров компонента
21.11.201713:5021.11.2017 13:50:25
$signer = new \Bitrix\Main\Security\Sign\Signer;
$params = $signer->unsign($request->get('signedParamsString'), 'sale.order.ajax');
$params = unserialize(base64_decode($params));
Надеюсь не ошибся в предназначении этого кода, нашёл в одном кастомном компоненте, решил сохранить на будущее.
$params = $signer->unsign($request->get('signedParamsString'), 'sale.order.ajax');
$params = unserialize(base64_decode($params));
Надеюсь не ошибся в предназначении этого кода, нашёл в одном кастомном компоненте, решил сохранить на будущее.
Новый интернет магазин BXReady: Флагман и черная пятница
20.11.201712:3220.11.2017 12:32:42
| Прочитал - передай другому |
Демо-сайт решения:
Накануне черной пятницы, мы не оставим данное событие без внимания
Будущий ценник решения от 25000 рублей (точная цена не определена, советам рады)
Но с 21 по 26 ноября у вас будет шанс приобрести его намного дешевле!
Только не упустите момент. Предложение ограничено!
Примечания:
1. Стоимость со скидкой, но без учета редакции Битрикс составляет 10 000 рублей. Действуют партнерские скидки
2. Акция действует до 26 ноября или до выполнения условия 3
3. Акция распространяется ТОЛЬКО НА 10 ЭКЗЕМПЛЯРОВ. Если 10 экземпляров будут проданы ранее 26 ноября АКЦИЯ БУДЕТ ОСТАНОВЛЕНА ДОСРОЧНО!
Возможности решения:
Кастомная регистрация с ReCaptcha
17.11.201717:0917.11.2017 17:09:47
Здравствуйте, выкладываю черновой вариант регистрации пользователя с возможностью использовать . Данный компонент - это модификация стандартного main.register.
Так же компонент поддерживает:
- Соглашения
- Регистрация без ввода логина(только e-mail)
- Обновление стандартной каптчи кнопкой
Событие OnAfterUserRegister сработает только в случае удачной регистрации пользователя.
События НЕ переведены на D7
Отправка сообщений пользователю осуществляется при помощи Bitrix\Main\Mail\Event::sendImmediate
Внутри компонента присутствует библиотека ReCaptcha взятая с
В шаблоне подключается компонент авторизации через соц-сети, если это возможно.
Как включить ReCaptcha:
1. Добавить и настроить на странице
2. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->Использовать CAPTCHA при регистрации.
В настройках компонента отметить "Использовать ReCaptcha", ввести данные в поля "Секретный ключ" и "Ключ".
Если в настройках компонента не отметить "Использовать ReCaptcha" и не ввести данные в поля "Секретный ключ" и "Ключ", то будет отображаться стандартная каптча.
Как убрать поле "Логин":
1. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->E-mail является обязательным полем
2. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->Проверять E-mail на уникальность при регистрации
3. В настройках компонента отметить галочку "Использовать e-mail для входа на сайт"
Ссылка на компонент
Так же компонент поддерживает:
- Соглашения
- Регистрация без ввода логина(только e-mail)
- Обновление стандартной каптчи кнопкой
Событие OnAfterUserRegister сработает только в случае удачной регистрации пользователя.
События НЕ переведены на D7
Отправка сообщений пользователю осуществляется при помощи Bitrix\Main\Mail\Event::sendImmediate
Внутри компонента присутствует библиотека ReCaptcha взятая с
В шаблоне подключается компонент авторизации через соц-сети, если это возможно.
Как включить ReCaptcha:
1. Добавить и настроить на странице
2. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->Использовать CAPTCHA при регистрации.
В настройках компонента отметить "Использовать ReCaptcha", ввести данные в поля "Секретный ключ" и "Ключ".
Если в настройках компонента не отметить "Использовать ReCaptcha" и не ввести данные в поля "Секретный ключ" и "Ключ", то будет отображаться стандартная каптча.
Как убрать поле "Логин":
1. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->E-mail является обязательным полем
2. В админке: Настройки->Главный модуль->Вкладка "Авторизация"->Проверять E-mail на уникальность при регистрации
3. В настройках компонента отметить галочку "Использовать e-mail для входа на сайт"
Ссылка на компонент
Continuous integration 1C-Bitrix
16.11.201708:2016.11.2017 08:20:04
Процесс разработки сайта у всех web-студий обычно состоит из четких и понятных шагов: бриф, ТЗ, дизайн, верстка, программирование, тесты. После того, как сайт сдан, кажется, можно расслабиться и приниматься за другую работу, но многие студии всегда смотрят в будущее — а что будет с проектом после окончания работ? Будет ли проект развиваться? Ведь сайт, как ребенок, постоянно растет, учится чему-то новому, предлагает пользователям новые возможности. И каждому сотруднику хочется продолжать работать над интересными проектами вдолгую. После сдачи, проект переходит в стадию «поддержки» или/и «развития».
Поддерживать проект — достаточно кропотливая и непростая задача: много коротких задач, желание заказчика видеть изменения на сайте как можно чаще, большое количество специалистов, задействованных в работе над проектом. Чтобы проект не превратился в сбор хлама и разрозненного кода, существует философия разработки — Continuous Integration (Непрерывная интеграция, CI).
Непрерывная интеграция (CI, англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем (wikipedia.org).
Статей о непрерывной интеграции web-приложений написана масса. Я же хочу поговорить о CI в CMS 1С Битрикс.
Философия. CI vs Bitrix
Для начала нужно понять что мы хотим иметь на практике? Основная философия CI заключается в следующем:
Версионность кода;
Версионность БД;
Автоматические сборки новых версий проекта.
Один и тот же код на production и develop версиях сайта;
Одна и та же структура БД на production и develop;
Автоматический перенос изменений на production (желательно вообще без участия специалиста) по расписанию или по событию.
Неприкосновенность ядра;
Неприкосновенность структуры БД;
Возможность обновления ядра без последствий;
Технология «эрмитаж», позволяющая администратору сайта создавать разделы/страницы на бою с помощью визуального редактора;
Настройки компонентов (читай разделов сайта) хранятся в файлах.
Поддержка .git
Давным давно, когда Битрикс был молодым и неопытным, публичные файлы проекта лежали рядом с ядром, что очень осложняло работу — приходилось писать километровые .gitignore для исключения файлов, постоянно следить за новыми модулями. Но наступил 2013 год и в Битриксе появилась поддержка папки /local/, которая имеет преимущество перед папкой /bitrix/ (ядро проекта). В этой папке мы можем хранить все публичные файлы сайта:
- /local/templates — шаблоны сайта;
- /local/php_interface — init.php;
- /local/modules — модули сторонних разработчиков;
- /local/components — компоненты сторонних разработчиков;
- /local/include/ — папка для своих доставок и платежных систем.
/nbproject/ *.swp *.swo .idea /bitrix /upload /sitemap* *.tst *.zip *.log *.pdf *.xls *.txt *.html *.old gitignore gitignore/* |
Ок, с репозиторием разобрались, но как нам доставлять изменения на develop и production сервера? Если с dev сервером проблем не возникает (git pull), то на production могут возникнуть проблемы — не всегда есть поддержка .git, заказчик вносит изменения в код сайта (через визуальный редактор), как следствие — масса конфликтов, каждый коммит превращается в ад. На помощь приходят автоматические сборщики кода.
Автоматический сборщик кода в вакууме представляет собой некую службу, которая умеет:
Отслеживать изменения в репозитории;
Делать git pull нужной ветки;
Архивировать файлы;
ssh.
Мы пошли еще дальше и решили автоматизировать и процесс слияния веток.
У нас есть 2 основные ветки кода: master для production и ветка develop для develop версии сайта.
Мы в итоге пришли к следующей схеме: программист Саша и верстальщик Вова работают над одним проектом. Программист Саша переписывает каталог, Вова «наверстывает» новую форму обратной связи. Каждый из них работает в своей ветке. Вова быстрее справился с задачей, коммитит стилевые файлы и выталкивает свою ветку в репозиторий. Его ветка в репозитории изменяется, срабатывает триггер, его ветка автоматически сливается с веткой develop.
Develop ветка изменяется, срабатывает триггер — сборщик запускает процесс деплоя: вытягивает ветку develop в свою папку текущего билда, архивирует все полученные файлы и заливает архив на сервер в папку сайта. После этого подключается по ssh, создает папку на сервере выше корня сайта с названием «release» и распаковывает в эту папку все файлы из архива. После этого в этой же папке создает все символьные ссылки, которые необходимы для работы проекта (ссылка на ядро bitrix, на папку upload и т.д.). На данный момент document root сайта смотрит на символьную ссылку «current», т.е. работа сайта не останавливается ни на секунду! После того, как ссылки проставлены, сборщик переименовывает папку «last_release» в «old_release», а папку «release», где лежит наш свежий код — в папку «last_release».
И вот Вова уже через несколько минут (процесс деплоя даже на больших проектах занимает 2-3 минуты) любуется новой формой на develop сайте и закрывает задачу. Но невидимый глазу сборщик продолжает свою работу. После успешного деплоя на сервер, сборщик сливает ветку develop со всеми другими ветками разработчиков.
Программист Саша наконец-то закончит задачу, закоммитит свои изменения и попытается вытолкнуть ветку. Но удаленный репозиторий не разрешит ему этого сделать. Сначала попросит вытянуть его свежую ветку. Что Саша с радостью и сделает: сольет ветки на локали, решит конфликты, если таковые будут, и с чистой совестью вытолкнет свою ветку — процесс деплоя начнется с самого начала.
Тут еще стоит сказать о встроенной поддержке .git в современных IDE, например, таких, как NetBeans. Саша вообще не переключается между окнами — все происходит в одной среде, ничего не нужно запускать, нажимать.
После того, как заказчик проверил изменения и ему все понравилось, ветка develop сливается с веткой master и начинается процесс деплоя уже на боевой сервер (за исключением слияния рабочих веток). Profit! Все счастливы, все довольны.
А где же тут Битрикс?
Включаемые области
Первая проблема, с которой мы столкнулись, — включаемые области: номера телефонов, ссылки на социальные сети, промо-тексты. Для всего этого используются включаемые области (). Неужели придется все эти области выносить в .gitignore? Чтобы этого не делать, мы написали модуль — включаемые области через БД. Принцип работы сохраняется — администратор сайта может править включаемые области через визуальный редактор, но информация сохраняется не в файл, а в БД, дополнительно указывается символьный код в настройках компонента, по которому мы однозначно определяем включаемую область. Теперь администратор может управлять включаемыми областями, изменения сохранятся на сайте.
Контентные страницы, меню
Вторая проблема — построение меню и организация контентных страниц на сайте. Как известно, меню в Битрикс строится на основе специальных файлов .*.menu.php — если заказчик добавит в файл пункт меню, а мы об этом не узнаем, при следующем билде мы просто затрем его изменения.
Проблему мы решили подключением файлов .*menu_ext.php, в которых структуру меню строим исходя из структуры разделов и элементов специального «контентного» инфоблока. Раздел инфоблока = раздел сайта, элемент инфоблока=страница на сайте.
Заказчику говорим создавать страницы и пункты меню не через «сайт», а через инфоблок. Тем более для него это привычнее: товары, меню, новости — все создается по одному принципу, не нужно запоминать несколько разных алгоритмов действий.
Контент выводим на сайте посредством компонента bitrix:catalog с настроенным ЧПУ от корня сайта:
"SEF_URL_TEMPLATES" => array( "sections" => "", "section" => "#SECTION_CODE_PATH#/", "element" => "#SECTION_CODE_PATH#/#ELEMENT_CODE#/", "compare" => "", "smart_filter" => "#SECTION_CODE_PATH#/#ELEMENT_CODE#/#SMART_FILTER_PATH#/", ) |
array( "CONDITION" => "#^/#", "RULE" => "", "ID" => "bitrix:catalog", "PATH" => "/pages/index.php", ), |
Таким образом, все страницы, которые физически не находятся на сервере будут отправляться в этот компонент.
Но как нам быть со страницами типа /about/news/ ? Страница /about/ это обычная текстовая страница, а /about/news/ — раздел с новостями сайта из инфоблока новостей. Для таких случаев нами написано свойство инфоблока, которое позволяет определить тип контентной страницы: текстовая страница, внешняя ссылка или компонент:
Структура БД
Вернемся к нашему проекту. Изначально программист Саша работал над проектом не один — ему помогал программист Рома. Рома внедрял новости, акции, текстовые страницы, Саша занимался каталогом и магазином. Работы велись одновременно. В процессе работы и Саша и Рома должны создать инфоблоки, свойства этих инфоблоков и т.д. Изначально мы решали проблему «одинаковости» БД для обоих программистов удаленным подключением к серверу, где лежит база данных. У каждого программиста свой код на локале, а вот БД одна. Но оказалось, не все так гладко: такой подход хорош при разработке сайта — потом сделаем дамп и все выльем на production. Когда проект уже находится на бою, такой номер не пройдет, придется руками создавать все новые инфоблоки и свойства. Решение, на самом деле, очевидно — миграции БД. Каждый программист работает со своей локальной БД, а изменения доставляет на сервер в виде файлов-миграций. Мы выбрали решение от наших коллег из компании WorkSolutions — . Этот модуль отлично нам подошел: миграции создаются легко, все четко и понятно. Есть поддержка консоли (наш сборщик проектов очень рад, так как ему добавляется дополнительное задание в каждом билде на миграцию базы данных).
Теперь процесс немного изменился: как только Саша коммитит свои изменения и пытается вытолкнуть свою ветку, удаленный репозиторий просит его сначала вытянуть свою ветку и слить со своей локальной. Когда Саша это сделает, у него появятся новые файлы миграции БД. Запустив у себя на локали обновление базы данных через модуль, он получит все изменения БД, которые внес другой программист.
Казалось, все достаточно стройно и красиво, но при использовании миграций БД сразу же возникает проблема настройки компонентов. Как известно, все списковые компоненты, которые работают с инфоблоками требуют указания ID инфоблока в настройках. ID у нас автоинкрементный, поэтому когда Саша и Рома в один и тот же день в своих локальных базах создадут по инфоблоку, у обоих этих инфоблоков будет ID=1. Рома создаст страницу /news/index.php, там разместит компонент новостей с настройкой IBLOCK_ID=1, Саша сделает то же самое с каталогом, но уже в другом файле /catalog/index.php. Когда они сольют код в единую ветку, наш сборщик успешно проведет обе миграции — получится, что мы имеем на сайте 2 разных компонента, которые работают с одним инфоблоком с ID=1. Например, первым создался инфоблок новостей, а вот инфоблок каталога с ID=2 остался не у дел. Подобная ситуация получится и у каждого программиста на локали, когда они проведут миграции.
Мы нашли выход в использовании констант. На событии «OnPageStart» мы запускаем вот такой метод:
public static function Definders() {
\Bitrix\Main\Loader::includeModule('iblock');
$result = \Bitrix\Iblock\IblockTable::getList(array(
'select' => array('ID', 'IBLOCK_TYPE_ID', 'CODE'),
));
while ($row = $result->fetch()) {
$CONSTANT = ToUpper(implode('_', array('IBLOCK', $row['IBLOCK_TYPE_ID'],
$row['CODE'])));
if (!defined($CONSTANT)) {
define($CONSTANT, $row['ID']);
}
}
} |
Теперь мы не используем конкретные ID в настройках компонента — указываем константу, например, IBLOCK_CONTENT_NEWS или IBLOCK_CATALOG_CATALOG. На develop версии, на production, у Саши и у Ромы все инфоблоки имеют разные ID, но это никак не влияет на работу сайта.
Конечно, мы не утверждаем, что такая схема разработки идеальна и подходит всем и каждому. В каждой студии свои особенности. Однажды мы поняли, что не хотим использовать программистов для рутинной работы — наши специалисты пишут код и логику, все остальное можно переложить на плечи автоматики. Специалист теперь думает о проекте, а не о решении проблем с «переносом». Уверен, что мы не остановимся на достигнутом, в будущем, наверняка, появятся и другие улучшения в процессе разработки, о которых мы обязательно вам расскажем.
autocomplete="new-password" не работает в Mozilla версия 56.0.2 (https://dev.1c-bitrix.ru/community/webdev/user/374762/forum/message/102979/511965/) Обратился в техподдержку Битрикс 10 ноября со следующей проблемой. У некоторых пользователей (ка
15.11.201707:5115.11.2017 07:51:08
Обратился в техподдержку Битрикс 10 ноября со следующей проблемой.
У некоторых пользователей (как выяснилось в зависимости от используемого браузера) при редактировании профиля возникала ошибка при сохранении - "Неверное подтверждение пароля".
За 5 дней техподдержка ничего вразумительного не ответила
, хотя как оказалось дело было вот в чем. Браузер Mozilla автоматически добавлял сохраненный пароль в поле
<input name="PASSWORD" autocomplete="new-password" type="password" class="content-edit-form-field-input-text"/>
autocomplete="new-password" было проигнорировано браузером.
Путем научного тыка (пришлось потратить на выявление причины и поиск решения некоторое время) заменил на
<input name="PASSWORD" autocomplete="false" readonly onfo cus="this.removeAttribute('readonly');" type="password" class="content-edit-form-field-input-text"/>
Протестировал в Opera, Mozilla, IE, Chrome. Все работает.
Текст вакансии для техдиректора
14.11.201709:5314.11.2017 09:53:12
к сабжу: нужна помощь в подготовке не просто текста, а скорее профиля сей личности
что должен уметь, знать, какими четами обладать
заранее благодарен за любые комментарии
что должен уметь, знать, какими четами обладать
заранее благодарен за любые комментарии
Делаем собственный sale.order.ajax на d7
14.11.201706:4614.11.2017 06:46:42
Написал новую статью о том как сделать собственный компонент заказа:
Статья получилась большая, с большим количеством форматирования, поэтому полный текст по ссылке
Штатный bitrix:sale.order.ajax очень сложно кастомизировать. Я думаю никто не будет со мной спорить. Битриксовцы подумали над процедурой заказа, о том как заказ должен выглядеть в идеале, а потом реализовали придуманную процедуру в продукте. Все сделано хорошо, однако если у заказчика представления по процедуре заказа отличаются от штатной реализации, то изменить шаблон компонента bitrix:sale.order.ajax практически нереально. Собственно сами битриксовцы на одной из конференций предложили писать отдельный компонент заказа. В этой статье я покажу один из вариантов по реализации такого компонента. И может быть попутно поясню непонятные моменты по созданию заказа на API. Само API по созданию заказа получилось прям отличное, несмотря на сложности кастомизации sale.order.ajax. Если вдруг разработчики читают эту статью, то спасибо вам, прямо приятно работать
По большей части вся статья только про серверный код.
Содержимое статьи:
1 Компонент
1.1 Создание виртуального заказа
1.2 Добавляем свойства заказа
1.3 Добавляем отгрузку (службу доставки)
1.4 Добавляем платежную систему
1.5 Подключение шаблона и сохранение
2 Шаблон компонента
2.1 Корзина
2.2 Работа со свойствами
2.2.1 Форма
2.2.2 Отображаемое местоположение
2.2.3 Получение свойства по коду
2.3 Прочие возможности
2.3.1 Стоимость доставки и заказа
2.3.2 Выбранная служба доставки
2.3.3 Выбранная система оплаты
2.4 Итого по шаблону
3 Добавляем ООП
3.1 Расширяем корзину
3.2 Расширяем заказ
3.3 Итого по ООП
4 Прикручиваем ajax
4.1 Actions компонента
4.2 Поиск местоположений
4.3 Метод расчета стоимости доставки
5 Общий итог
TL;DR
При каждом вызове компонента, неважно аяксом или на странице создаем объект заказа. По необходимости добавляем новые методы в объекты корзины и заказа. В шаблоне компонента пользуемся объектом заказа напрямую, $arResult скорее всего не пригодится. При ответе аяксом возвращаем json где передаем чистые данные + сразу html нужного куска шаблона.
Статья получилась большая, с большим количеством форматирования, поэтому полный текст по ссылке
Штатный bitrix:sale.order.ajax очень сложно кастомизировать. Я думаю никто не будет со мной спорить. Битриксовцы подумали над процедурой заказа, о том как заказ должен выглядеть в идеале, а потом реализовали придуманную процедуру в продукте. Все сделано хорошо, однако если у заказчика представления по процедуре заказа отличаются от штатной реализации, то изменить шаблон компонента bitrix:sale.order.ajax практически нереально. Собственно сами битриксовцы на одной из конференций предложили писать отдельный компонент заказа. В этой статье я покажу один из вариантов по реализации такого компонента. И может быть попутно поясню непонятные моменты по созданию заказа на API. Само API по созданию заказа получилось прям отличное, несмотря на сложности кастомизации sale.order.ajax. Если вдруг разработчики читают эту статью, то спасибо вам, прямо приятно работать
По большей части вся статья только про серверный код.
Содержимое статьи:
1 Компонент
1.1 Создание виртуального заказа
1.2 Добавляем свойства заказа
1.3 Добавляем отгрузку (службу доставки)
1.4 Добавляем платежную систему
1.5 Подключение шаблона и сохранение
2 Шаблон компонента
2.1 Корзина
2.2 Работа со свойствами
2.2.1 Форма
2.2.2 Отображаемое местоположение
2.2.3 Получение свойства по коду
2.3 Прочие возможности
2.3.1 Стоимость доставки и заказа
2.3.2 Выбранная служба доставки
2.3.3 Выбранная система оплаты
2.4 Итого по шаблону
3 Добавляем ООП
3.1 Расширяем корзину
3.2 Расширяем заказ
3.3 Итого по ООП
4 Прикручиваем ajax
4.1 Actions компонента
4.2 Поиск местоположений
4.3 Метод расчета стоимости доставки
5 Общий итог
TL;DR
При каждом вызове компонента, неважно аяксом или на странице создаем объект заказа. По необходимости добавляем новые методы в объекты корзины и заказа. В шаблоне компонента пользуемся объектом заказа напрямую, $arResult скорее всего не пригодится. При ответе аяксом возвращаем json где передаем чистые данные + сразу html нужного куска шаблона.
Почтовое уведомление о неудачном бэкапе
09.11.201713:0309.11.2017 13:03:24
Ситуация
Настроено регулярное резервное копирование с выгрузкой бэкапа в облако Битрикс.
По какой-либо причине создание бэкапа не удается полностью завершить (в моем случае не удалось залить в облако).
В журнале резервного копирования это может выглядеть так:
Если вовремя не обнаружить проблему, то ее обнаружат посетители, т.к. рано или поздно работа сайта будет нарушена из-за нехватки свободного места на диске. Хуже, если в рамках данного дискового пространства работают также и другие сайты. Кроме того, вы рискуете остаться без свежей версии бэкапа.
Правильным решением, в случае неудачного создания бэкапа, будет немедленное сообщение об этом случае администратору.
Как реализовать? В голову сразу приходит использовать обработчик события создания бэкапа. К сожалению, поиски по документации, форумам и блогам результата не дали.
Ну ок, тогда лезем в исходники...
Ага, вот они мои родимые!
Итак мы нашли два, интересующих нас, недокументированных события: OnAutoBackupError и OnAutoBackupUnknownError.
Добавляем свой обработчик
Добавляем тип почтового события:
Добавляем для него почтовый шаблон:
А вот и пример результата наших стараний:
Теперь при каждом неудачном резервном копировании вы получите уведомление на указанный почтовый адрес.
Аналогичным образом можно настроить уведомления при каждом удачном резервировании - все зависит от степени вашей параноидальности
За это, кстати, отвечает событие OnAutoBackupSuccess.
Настроено регулярное резервное копирование с выгрузкой бэкапа в облако Битрикс.
По какой-либо причине создание бэкапа не удается полностью завершить (в моем случае не удалось залить в облако).
В журнале резервного копирования это может выглядеть так:
Если вовремя не обнаружить проблему, то ее обнаружат посетители, т.к. рано или поздно работа сайта будет нарушена из-за нехватки свободного места на диске. Хуже, если в рамках данного дискового пространства работают также и другие сайты. Кроме того, вы рискуете остаться без свежей версии бэкапа.
Правильным решением, в случае неудачного создания бэкапа, будет немедленное сообщение об этом случае администратору.
Как реализовать? В голову сразу приходит использовать обработчик события создания бэкапа. К сожалению, поиски по документации, форумам и блогам результата не дали.
Ну ок, тогда лезем в исходники...
| /bitrix/modules/main/tools/backup.php |
Итак мы нашли два, интересующих нас, недокументированных события: OnAutoBackupError и OnAutoBackupUnknownError.
Добавляем свой обработчик
//добавляем обработчик на оба события
AddEventHandler("main", "OnAutoBackupError", "OnAutoBackupError");
AddEventHandler("main", "OnAutoBackupUnknownError", "OnAutoBackupError");
//сам обработчик
function OnAutoBackupError($error){
//какую информацию передадим в уведомление
$arEventFields = array(
"DATE_CREATE"=> date("d.m.Y H:i:s"),
"ERROR"=> $error['ERROR'],
"ERROR_CODE"=> $error['ERROR_CODE'],
"ITEM_ID"=> $error['ITEM_ID'],
);
//создаем почтовое событие
CEvent::Send("BACKUP_UNKNOWN_ERROR", SITE_ID, $arEventFields);
} |
Добавляем для него почтовый шаблон:
А вот и пример результата наших стараний:
Теперь при каждом неудачном резервном копировании вы получите уведомление на указанный почтовый адрес.
Аналогичным образом можно настроить уведомления при каждом удачном резервировании - все зависит от степени вашей параноидальности
За это, кстати, отвечает событие OnAutoBackupSuccess.
Удалить модуль, если он поломал админку.
09.11.201712:1909.11.2017 12:19:45
Памятка на будущее.
Если установил модуль, а он выдаёт тысячи ошибок и страница удаления выглядит как-то вот так:
Удалить можно перейдя по ссылке:
Где #MODULE_ID# - id модуля, который надо удалить (например "bitrix.liveapi"), а #SESSID# можно получить вот этой функцией в консоли браузера: BX.bitrix_sessid().
Или, если всё равно использовать консоль, можно сделать редирект оттуда:
Если установил модуль, а он выдаёт тысячи ошибок и страница удаления выглядит как-то вот так:
Удалить можно перейдя по ссылке:
/bitrix/admin/partner_modules.php?id=#MODULE_ID#&lang=ru&uninstall=Y&sessid=#SESSID# |
Где #MODULE_ID# - id модуля, который надо удалить (например "bitrix.liveapi"), а #SESSID# можно получить вот этой функцией в консоли браузера: BX.bitrix_sessid().
Или, если всё равно использовать консоль, можно сделать редирект оттуда:
BX.adminPanel.Redirect([], '/bitrix/admin/partner_modules.php?id=#MODULE_ID#&lang=ru&uninstall=Y&sessid=#SESSID#', event) |
Кто верит, что программисты работают 8 часов в день? Нужно ли заставлять их работать? Все о Javascript и разработке интерфейсов (https://zen.yandex.ru/id/5ea4a76a7c806053df5029a2)
06.11.201700:0706.11.2017 00:07:41
Кто верит, что программисты работают 8 часов в день? Нужно ли заставлять их работать?
Какие паттерны проектирования использует битрикс
06.11.201700:0306.11.2017 00:03:49
Мы все живем в современном, быстро растущем и меняющемся мире. Новые современные технологии и методики разработки появляются с ужасающей скоростью. Не успеешь закончить какой то проект, как смотришь, уже появились решения, с помощью которых можно было все сделать проще и быстрее.
Сложность больших проектов в их неспособности быстро адаптироваться под все новое и современное. А надо ли? Этот вопрос всегда вызывает много споров и разногласий. В конечном итоге все сводится к тому, что особо не надо, но все равно приходится. Программист который отлично писал на PHP4, но забил на изучение PHP5, может сегодня остаться без работы. Хотя в проектах, которые он делал, фичи PHP5 по большому счету не нужны. Проект и так хорошо работал (и возможно работает) на PHP4.
Сейчас паттерны проектирования(design patterns) считаются хорошей практикой разработки. Это практика стала настолько хороша, что иногда программисты вставляют паттерны везде где только можно, не задумываясь, а нужны ли они тут вообще. Современный разработчик как правило знает несколько распространенных в практике паттернов (обычно это singleton, factory method, observer, decorator, возможно MVC).
На практике не всегда можно сходу "узнать" паттерн в коде приложения, т.к сам паттерн описывает некую архитектурную конструкцию приложения, но не ее реализацию в коде. Итак, хочу познакомить вас с несколькими паттернами проектирования, реализованными в битрикс
Небольшое отступление: вообще тема про паттерны в битрикс возникла случайно в моем разговоре с . Он хотел написать про это, но похоже я его немного опередил. Возможно ему будет что добавить от себя.
Observer(наблюдатель)
Мы все очень часто пользуемся обработчиками событий в битрикс, вещаем их на инфоблоки и другие объекты, так вот это очень похоже на observer. Классический observer немного более ограничен, т.к не имеет информации о том, какое событие произошло. Другой кандидат на эту должность это event dispatcher.
Singleton(одиночка)
В точности singleton в битрикс не реализован, но можно предположить, что глобальные переменные $APPLICATION и $DB это как раз прямые кандидаты в singleton.
MVC (Модель - представление - контроллер)
Мы все про него много знаем. Всем нам вдалбливали в голову, что при разработке web-приложений нужно обязательно следовать MVC. Да, я согласен . MVC в битрикс - это компоненты 2.0. Компонент - это контроллер, шаблон - представление, а модули - это модель.
Front controller (единая точка входа в приложение)
Это мой любимый паттерн. В битрикс его нет, но если предположить, что есть некий глобальный комплексный компонент для всего сайта, то его можно будет назвать Front controller.
Adapter
$DB это практически и есть адаптер. Мы подключаем конкретную реализацию для конкретной базы данных, при это все реализации имеют единый интерфейс для работы с базой.
Decorator
Компоненты 2.0 кроме MVC это еще и немножко декораторы. Мы можем изменить поведение компонента вне самого компонента, например в эпилоге компонента. Правда decorator предусматривает наличие двух объектов, а у нас компонент и эпилог объектами не является, но общее с decorator все равно есть.
Стоит добавить, что в битрикс не совсем очевидная реализация вышеперечисленных паттернов. Возможно некоторые другие паттерны я упустил из виду. Кстати компоненты 2.0, если верить мануалу битрикс, реализуют другой паттерн - Carrier Rider Mapper. Я сути этого паттерна не уловил, поэтому для меня это просто MVC.
Сложность больших проектов в их неспособности быстро адаптироваться под все новое и современное. А надо ли? Этот вопрос всегда вызывает много споров и разногласий. В конечном итоге все сводится к тому, что особо не надо, но все равно приходится. Программист который отлично писал на PHP4, но забил на изучение PHP5, может сегодня остаться без работы. Хотя в проектах, которые он делал, фичи PHP5 по большому счету не нужны. Проект и так хорошо работал (и возможно работает) на PHP4.
Сейчас паттерны проектирования(design patterns) считаются хорошей практикой разработки. Это практика стала настолько хороша, что иногда программисты вставляют паттерны везде где только можно, не задумываясь, а нужны ли они тут вообще. Современный разработчик как правило знает несколько распространенных в практике паттернов (обычно это singleton, factory method, observer, decorator, возможно MVC).
На практике не всегда можно сходу "узнать" паттерн в коде приложения, т.к сам паттерн описывает некую архитектурную конструкцию приложения, но не ее реализацию в коде. Итак, хочу познакомить вас с несколькими паттернами проектирования, реализованными в битрикс
Небольшое отступление: вообще тема про паттерны в битрикс возникла случайно в моем разговоре с . Он хотел написать про это, но похоже я его немного опередил. Возможно ему будет что добавить от себя.
Observer(наблюдатель)
Мы все очень часто пользуемся обработчиками событий в битрикс, вещаем их на инфоблоки и другие объекты, так вот это очень похоже на observer. Классический observer немного более ограничен, т.к не имеет информации о том, какое событие произошло. Другой кандидат на эту должность это event dispatcher.
Singleton(одиночка)
В точности singleton в битрикс не реализован, но можно предположить, что глобальные переменные $APPLICATION и $DB это как раз прямые кандидаты в singleton.
MVC (Модель - представление - контроллер)
Мы все про него много знаем
. Всем нам вдалбливали в голову, что при разработке web-приложений нужно обязательно следовать MVC. Да, я согласен . MVC в битрикс - это компоненты 2.0. Компонент - это контроллер, шаблон - представление, а модули - это модель.Front controller (единая точка входа в приложение)
Это мой любимый паттерн
. В битрикс его нет, но если предположить, что есть некий глобальный комплексный компонент для всего сайта, то его можно будет назвать Front controller.Adapter
$DB это практически и есть адаптер. Мы подключаем конкретную реализацию для конкретной базы данных, при это все реализации имеют единый интерфейс для работы с базой.
Decorator
Компоненты 2.0 кроме MVC это еще и немножко декораторы. Мы можем изменить поведение компонента вне самого компонента, например в эпилоге компонента. Правда decorator предусматривает наличие двух объектов, а у нас компонент и эпилог объектами не является, но общее с decorator все равно есть.
Стоит добавить, что в битрикс не совсем очевидная реализация вышеперечисленных паттернов. Возможно некоторые другие паттерны я упустил из виду. Кстати компоненты 2.0, если верить мануалу битрикс, реализуют другой паттерн - Carrier Rider Mapper. Я сути этого паттерна не уловил, поэтому для меня это просто MVC.
Кеширование в 1С-Битрикс на Redis
01.11.201717:3701.11.2017 17:37:48
Сразу оговорюсь, тут не будет инструкции как сделать типовое кеширование в битриксе. Если оно вам надо, то . Cмена системного кеширования opcache или memcached на Redis не дает никакого преимущества в производительности. Все эти системы позволяют хранить кеш в оперативной памяти, их производительность находится в одном порядке - сотни тысяч операций чтения/записи в секунду. Ниже будет речь о том, как использовать Redis для хранения данных и как эти данные использовать, что это дает. Мы уйдем от кеширования в битриксе в принципе и посмотрим, что из этого получится в плане производительности.
Проблема производительности при фильтрации
Возьмем популярный сайт, созданный на 1С-Битрикс, и популярный раздел на нем, пусть это будет Hoff и раздел "". Чтобы увидеть скорость генерации страницы битриксом, нужно в URL добавить параметр show_page_exec_time=Y, внизу страницы появится время генерации. На Hoff, кажется, они вырезают этот блок через JS, но в исходном коде страницы он всегда виден. Так даже удобнее. Для объективности лучше делать несколько обновлений страниц и получить некий средний результат. Конкретно в данный момент мне показывается время генерации страницы от 0.23 до 0.5 с для первой страницы раздела диванов.
Казалось бы, 0.5 секунды для генерации ключевой страницы на сайте - это уже катастрофа, но нет. Катастрофа начинается, когда вы будете менять значения фильтра. Например, по цене. Я поставил значение , время генерации страницы было более 5 секунд. Как видите, ценовой диапазон задается параметром в URL вида prices=15000_399990. Повторное обновление страницы с тем же ценовым диапазоном показало время 0.5 секунд. И все последующие обновления страницы с той же ценой показывают примерно такое же нормальное время генерации страницы. Поменяйте ценовой диапазон на 1 и у вас история повторится - 5 секунд для первого запроса и 0.5 для всех последующих.
Проблема заключается в том, что любое изменение параметров фильтрации, а также сортировки или изменения количества выводимых товаров на страницу вызывают перегенерацию кеша компонента bitrix:catalog.section или его кастомного аналога, который отвечает за вывод товаров. На hoff.ru еще включена опция "Кешировать при установленном фильтре" - это значит, что при любом значении фильтра будет создаваться новый кеш, именно поэтому повторные запросы с установленным ценовым диапазоном выполнялись за относительно небольшое время. Это не проблема именно Hoff, она наблюдается на многих сайтах, использующих 1С-Битрикс: "Читай-город", "Красное&Белое", "ЦУМ" и т.д.
Как кеширует битрикс
Это был иронический пролог, эта цитата меня всегда умиляла.
Сама концепция кеширования 1С-Битрикс заключается в том, что кешируется результат целиком. Будь то $arResult в работе компонентов или готовый кусок html-кода. Любое изменение входящих переменных образует новый кеш, потому что меняется ключ, формируемый из параметров, а с ним и множество запросов к БД, даже если результат остается таким же. Кеш сохраняется в отдельных файлах и при неверной настройке кеширования количество этих файлов может быть очень большим. Использование opcache или memcached существенно ускоряют работу кеша, но принцип его работы остается тем же, только данные хранятся уже не на диске, а в оперативной памяти. Кроме того, весь кеш генерируется на пользовательских хитах, а не где-то там фоновым процессом темными ночами. Если на сайте низкая посещаемость, то пользователи неизбежно столкнутся с высоким временем генерации страниц, а владелец сайта при низком трафике будет видеть высокую нагрузку на сервере, потому что многие пользователи получают некешированные данные. Особенно, если код на сайте неоптимальный и кеширование используется для его сокрытия (когда без кеша 6000 запросов к БД на хите - я такое видел часто).
Решение кеширования на Redis
Почему бы тогда не кешировать отдельные части результата? Например, не список товаров на страницу, а каждый товар отдельно? Отдельно цены, отдельно порядок следования элементов, отдельно свойства инфоблока и т.д. Divide et impera.
Для решения этой проблемы решено было использовать Redis. Данная NoSQL-СУБД широко распространена, быстрая, обладает хорошим функционалом для хранения как строк, так и структур (наборы, списки, хэш-таблицы). Касательно производительности, то, как и многие подобные системы, хранящие данные в оперативной памяти, он быстрый. Допустим, на моем обычном офисном компе показывает 150 тысяч операций записи/чтения (set/get) в секунду. На сервере на базе 2-х Xeon 4114 / DDR4 более 200 тысяч для одного потока. Ограничения запредельные, допустим, строка может быть максимум 512 Мб, а длина списков более 4 млрд. элементов. Если мы работаем не с BigData, то такие пределы даже для большого интернет-магазина являются достаточными.
Для эксперимента я создал типовой интернет-магазин на базе редакции "Бизнес", загрузил в него реальные товары из партнерских XML-файлов "Озон". Загружено было более 12 тысяч товаров, с ценами, названиями, описаниями и фото. Заполнено было лишь 4 свойства инфоблока, на остальные руки уже не дошли. Данная модель не совсем корректна, потому что у многих интернет-магазинов десятки и сотни свойств инфоблока могут быть заполнены различной информацией. В них часто хранят кроме общей информации (бренд, артикул, штрихкод и т.д.) еще и специфические характеристики для типов товаров (диагональ экрана, процессор и т.д.), что по-моему, совсем неправильно. Встречал интернет-магазины, где использовалось более 2000 свойств инфоблока - редактировать инфоблок и элементы стало невозможным.
Следующий шаг - это подготовка данных. Мы будем генерировать весь кеш в фоне, а пользовательские хиты не будут вызывать перегенерации кеша ни в коем случае. И прежде чем генерировать в фоне кеш, мы должны определиться с его структурой. Она получилась такой:
Теперь нам необходимо создать свой компонент для вывода списка товаров. Он не будет использовать кеш битрикса вообще. Основная логика компонента - это узнать список ID подходящих товаров, выбрать эти товары и отобразить шаблон с данными.
Компонент в качестве параметров может получать: ID инфоблока, ID раздела, фильтр по значениям свойств инфоблока, сортировку, количество выводимых товаров на страницу. Я не нашел правильного способа высчитывать пересечения множеств различного типа в Redis прямо в нем, поэтому решено было использовать расчет пересечений функциями PHP, благо количество элементов измеряется лишь десятками тысяч, а в качестве значений выступают только целые числа (ID товаров).
Логика компонента получилась очень простой:
Пример работы фильтра
С фильтром нужно дать небольшое пояснение как он будет работать. Например, у нас есть раздел телевизоров, у телевизоров есть два свойства: бренд и диагональ. При подготовке кеша мы должны создать индекс значений обоих характеристик. В случае бренда - это справочник, нам надо для каждого бренда создать свой набор (Set) ID товаров, принадлежащих конкретному бренду. В итоге получатся ключи примерно такого вида:
i:1:f:DIAGONAL = 50 1, 55 2, 55 3, 49 4, 43 5...
В дальнейшем из этого ключа будет удобно выбирать ID товаров по диагонали от и до. Или даже считать среднее, если оно вам вдруг понадобится.
Выбор телевизора определенного бренда и определенной диагонали - это будет пересечение двух массивов с ID товаров. Допустим, нам нужен Samsung диагональю от 50 до 55 дюймов. Выбираем два массива в PHP: все ID из ключа i:1:f:BRAND:v:SAMSUNG и все ID из ключа i:1:f:DIAGONAL, где Score больше 50 и меньше 55. Ну а далее array_intersect и получаем список допустимых ID товаров для вывода.
Если же вы хотите выбрать телевизор не только Samsung, но и Sony, то механизм будет немного другим. Для бренда нам уже нужен список из двух ключей, его уже можно получить с помощью функции . Хотя вы также можете получить 2 массива в PHP и соединить их с помощью array_merge. Скорость работы на сотнях и тысячах товаров примерно одинаковая и будет измеряться миллионными долями секунд.
Ну и дальше уже отфильтрованный список ID накладывается на отсортированный полный список и по нему выбираются товары.
Итоги
Сайт с прототипом запущен здесь -
Постраничную навигацию не прикручивал пока.
Главной целью эксперимента было увеличение производительности страницы со списком товаров на произвольных запросах с различными фильтрами и сортировками. Были получены следующие цифры:
Эта картинка выше показывает тайминги для работы различных частей компонента.
Также было проведено нагрузочное тестирование с помощью ab и siege. Под тестовую виртуальную машину было выделено 16 ядер процессора и 32 Гб памяти, используется php_fpm + nginx, opcache, PHP 7.0.23, Redis 4.0.2, Centos 7. Оценка производительности битрикса выдает 220-240 попугаев. При тестировании нагрузка на CPU была около 85%. На Redis идет около 35% нагрузки и только 1 ядра из 16.
Прочие наблюдения при работе с Redis:
Пересмотр архитектуры значительной части сайта дает существенный прирост в производительности и решает серьезные проблемы. Лично для меня результаты работы с Redis в битриксе похожи на переход с обычного HDD на SSD - тот же эффект wow! Лучший апгрейд, который мог произойти. Да, сильно дороже в производстве и поддержке, усложняется логика, повышается требование к квалификации разработчиков, но результаты того стоят. Если вы не шарашкина контора с полутора сотрудниками, то такая разработка вам по карману. То, что сейчас опубликовано и работает как концепт по времени разработки заняло 24 рабочих часа программиста. Даже если взять топовые зарплаты - это несколько десятков тысяч рублей на рабочий концепт. Ну пусть далее требуется доработка до готового решения, надо написать другие компоненты, оптимизировать, еще месяц-другой, все равно суммы здесь небольшие на разработку, вполне доступные таким компаниям, которые покупают Enterprise за полтора миллиона рублей или сервера для кластера в надежде решить проблемы с производительностью.
И это только вершина айсберга. Использование Redis, его возможности работы с данными, открывают действительно новый потенциал для Битрикса. Нулевое количество обращений к БД на нагруженном сайте - вполне реально. Сотни тысяч посещений на обычном сервере в аренде - запросто. Всё это дает сокращение инфраструктурных расходов в разы.
Проблема производительности при фильтрации
Возьмем популярный сайт, созданный на 1С-Битрикс, и популярный раздел на нем, пусть это будет Hoff и раздел "". Чтобы увидеть скорость генерации страницы битриксом, нужно в URL добавить параметр show_page_exec_time=Y, внизу страницы появится время генерации. На Hoff, кажется, они вырезают этот блок через JS, но в исходном коде страницы он всегда виден. Так даже удобнее. Для объективности лучше делать несколько обновлений страниц и получить некий средний результат. Конкретно в данный момент мне показывается время генерации страницы от 0.23 до 0.5 с для первой страницы раздела диванов.
Казалось бы, 0.5 секунды для генерации ключевой страницы на сайте - это уже катастрофа, но нет. Катастрофа начинается, когда вы будете менять значения фильтра. Например, по цене. Я поставил значение , время генерации страницы было более 5 секунд. Как видите, ценовой диапазон задается параметром в URL вида prices=15000_399990. Повторное обновление страницы с тем же ценовым диапазоном показало время 0.5 секунд. И все последующие обновления страницы с той же ценой показывают примерно такое же нормальное время генерации страницы. Поменяйте ценовой диапазон на 1 и у вас история повторится - 5 секунд для первого запроса и 0.5 для всех последующих.
Проблема заключается в том, что любое изменение параметров фильтрации, а также сортировки или изменения количества выводимых товаров на страницу вызывают перегенерацию кеша компонента bitrix:catalog.section или его кастомного аналога, который отвечает за вывод товаров. На hoff.ru еще включена опция "Кешировать при установленном фильтре" - это значит, что при любом значении фильтра будет создаваться новый кеш, именно поэтому повторные запросы с установленным ценовым диапазоном выполнялись за относительно небольшое время. Это не проблема именно Hoff, она наблюдается на многих сайтах, использующих 1С-Битрикс: "Читай-город", "Красное&Белое", "ЦУМ" и т.д.
Как кеширует битрикс
Это был иронический пролог, эта цитата меня всегда умиляла.
Сама концепция кеширования 1С-Битрикс заключается в том, что кешируется результат целиком. Будь то $arResult в работе компонентов или готовый кусок html-кода. Любое изменение входящих переменных образует новый кеш, потому что меняется ключ, формируемый из параметров, а с ним и множество запросов к БД, даже если результат остается таким же. Кеш сохраняется в отдельных файлах и при неверной настройке кеширования количество этих файлов может быть очень большим. Использование opcache или memcached существенно ускоряют работу кеша, но принцип его работы остается тем же, только данные хранятся уже не на диске, а в оперативной памяти. Кроме того, весь кеш генерируется на пользовательских хитах, а не где-то там фоновым процессом темными ночами. Если на сайте низкая посещаемость, то пользователи неизбежно столкнутся с высоким временем генерации страниц, а владелец сайта при низком трафике будет видеть высокую нагрузку на сервере, потому что многие пользователи получают некешированные данные. Особенно, если код на сайте неоптимальный и кеширование используется для его сокрытия (когда без кеша 6000 запросов к БД на хите - я такое видел часто).
Решение кеширования на Redis
Почему бы тогда не кешировать отдельные части результата? Например, не список товаров на страницу, а каждый товар отдельно? Отдельно цены, отдельно порядок следования элементов, отдельно свойства инфоблока и т.д. Divide et impera.
Для решения этой проблемы решено было использовать Redis. Данная NoSQL-СУБД широко распространена, быстрая, обладает хорошим функционалом для хранения как строк, так и структур (наборы, списки, хэш-таблицы). Касательно производительности, то, как и многие подобные системы, хранящие данные в оперативной памяти, он быстрый. Допустим, на моем обычном офисном компе показывает 150 тысяч операций записи/чтения (set/get) в секунду. На сервере на базе 2-х Xeon 4114 / DDR4 более 200 тысяч для одного потока. Ограничения запредельные, допустим, строка может быть максимум 512 Мб, а длина списков более 4 млрд. элементов. Если мы работаем не с BigData, то такие пределы даже для большого интернет-магазина являются достаточными.
Для эксперимента я создал типовой интернет-магазин на базе редакции "Бизнес", загрузил в него реальные товары из партнерских XML-файлов "Озон". Загружено было более 12 тысяч товаров, с ценами, названиями, описаниями и фото. Заполнено было лишь 4 свойства инфоблока, на остальные руки уже не дошли. Данная модель не совсем корректна, потому что у многих интернет-магазинов десятки и сотни свойств инфоблока могут быть заполнены различной информацией. В них часто хранят кроме общей информации (бренд, артикул, штрихкод и т.д.) еще и специфические характеристики для типов товаров (диагональ экрана, процессор и т.д.), что по-моему, совсем неправильно. Встречал интернет-магазины, где использовалось более 2000 свойств инфоблока - редактировать инфоблок и элементы стало невозможным.
Следующий шаг - это подготовка данных. Мы будем генерировать весь кеш в фоне, а пользовательские хиты не будут вызывать перегенерации кеша ни в коем случае. И прежде чем генерировать в фоне кеш, мы должны определиться с его структурой. Она получилась такой:
- Кеш свойств инфоблока - он с большим TTL, можно неделю, храним поля свойств инфоблока, справочники списков и связанных элементов (например, связанный бренд).
- Кеш разделов - я много разделов не создавал, но на обычном сайте пара тысяч разделов инфоблока может быть вполне нормой. Будем хранить всё дерево разделов, все их связи, описания.
- Кеш сортировок - мы можем получить из MySQL последовательный список ID товаров во всех используемых на сайте сортировках. По названию, по цене, по рейтингу и т.д. Тут был задействован тип данных List в Redis. Он позволяет хранить упорядоченные ряды
- Кеш элементов - список с описанием товаров, все поля элемента инфоблока, цены и значения свойств инфоблока
- Кеш привязок элементов к разделам - список ID товаров, привязанных к конкретным разделам. Использованы ряды (Sets) - этот тип данных позволяет хранить неупорядоченный набор значений. Нам просто надо знать список доступных ID товаров для конкретного раздела,
- а за сортировку отвечает другой кеш.
- Кеш цен - список цен для товаров. Использованы упорядоченные ряды (Sorted sets), данный функционал в Redis позволяет хранить уникальные значения, упорядоченные по оценке (Score), в качестве оценки выступает цена. Очень удобно, когда нужно выбрать значения от и до или получить цену по конкретному ID товара.
- Кеш фильтров - это список ID товаров, доступных для каждого значения фильтруемых свойств. Например, в отдельном ключе хранится список ID товаров, где brand=samsung. Также со всеми фильтруемыми свойствами. Если у вас 1000 вариантов значений для 10 свойств, то у вас будет 1000 ключей с рядами допустимых ID товаров. Опять же использованы неупорядоченные наборы (Sets).
Теперь нам необходимо создать свой компонент для вывода списка товаров. Он не будет использовать кеш битрикса вообще. Основная логика компонента - это узнать список ID подходящих товаров, выбрать эти товары и отобразить шаблон с данными.
Компонент в качестве параметров может получать: ID инфоблока, ID раздела, фильтр по значениям свойств инфоблока, сортировку, количество выводимых товаров на страницу. Я не нашел правильного способа высчитывать пересечения множеств различного типа в Redis прямо в нем, поэтому решено было использовать расчет пересечений функциями PHP, благо количество элементов измеряется лишь десятками тысяч, а в качестве значений выступают только целые числа (ID товаров).
Логика компонента получилась очень простой:
- Узнать подходящие ID товаров для раздела
- Узнать подходящие ID товаров для фильтра, если есть
- Узнать порядок ID товаров
- Найти пересечение всех множеств, определенных ID и получить упорядоченный список ID
- Выбрать информацию о товарах из определенного выше списка и отдать в шаблон
Пример работы фильтра
С фильтром нужно дать небольшое пояснение как он будет работать. Например, у нас есть раздел телевизоров, у телевизоров есть два свойства: бренд и диагональ. При подготовке кеша мы должны создать индекс значений обоих характеристик. В случае бренда - это справочник, нам надо для каждого бренда создать свой набор (Set) ID товаров, принадлежащих конкретному бренду. В итоге получатся ключи примерно такого вида:
- i:1:f:BRAND:v:SAMSUNG = 1, 2, 3, 4, 5...
- i:1:f:BRAND:v:SONY = 6, 7, 8, 9, 10...
- i:1:f:BRAND:v:LG = 11, 12, 13, 14...
- и т.д.
i:1:f:DIAGONAL = 50 1, 55 2, 55 3, 49 4, 43 5...
В дальнейшем из этого ключа будет удобно выбирать ID товаров по диагонали от и до. Или даже считать среднее, если оно вам вдруг понадобится.
Выбор телевизора определенного бренда и определенной диагонали - это будет пересечение двух массивов с ID товаров. Допустим, нам нужен Samsung диагональю от 50 до 55 дюймов. Выбираем два массива в PHP: все ID из ключа i:1:f:BRAND:v:SAMSUNG и все ID из ключа i:1:f:DIAGONAL, где Score больше 50 и меньше 55. Ну а далее array_intersect и получаем список допустимых ID товаров для вывода.
Если же вы хотите выбрать телевизор не только Samsung, но и Sony, то механизм будет немного другим. Для бренда нам уже нужен список из двух ключей, его уже можно получить с помощью функции . Хотя вы также можете получить 2 массива в PHP и соединить их с помощью array_merge. Скорость работы на сотнях и тысячах товаров примерно одинаковая и будет измеряться миллионными долями секунд.
Ну и дальше уже отфильтрованный список ID накладывается на отсортированный полный список и по нему выбираются товары.
Итоги
Сайт с прототипом запущен здесь -
Постраничную навигацию не прикручивал пока.
Главной целью эксперимента было увеличение производительности страницы со списком товаров на произвольных запросах с различными фильтрами и сортировками. Были получены следующие цифры:
- Вся хранимая информация для 12 тысяч товаров в Redis заняла 40 Мб. То есть даже если грузить сотни тысяч товаров, тысячи разделов, сотни значений характеристик для каждого товара, то использование памяти будет на уровне пары-тройки Гб, что по современным меркам очень незначительно. И это финальный размер кеша, он не будет расти из-за нагрузки.
- Время полного обновления кеша - 27 секунд. При увеличении количества товаров и сложности данных это время будет расти пропорционально. Но пусть даже обновление всего кеша займет 300 секунд - это всё равно лучше, чем выполнять обновление кеша на хитах посетителей. И обновлять можно по ночам, раз в сутки. Также можно обновлять части кеша, например, по событиям изменения разделов, товаров, цен, свойств инфоблока, прав доступа и т.д.
- Время генерации компонента со списком товаров составило несколько тысячных, от 0.005 до 0.008 с.
- При фильтрации время генерации компонентом увеличивается в 3-7 раз. 15-35 тысячных вместо 5-8 тысячных секунды - это небольшая разница, но наверняка есть варианты оптимизации хранения данных и расчета пересечений, которые позволят убрать это увеличение времени работы компонента.
- Расходы компонента по памяти около 2-3 Мб для вывода 60 товаров, они стабильны при любом фильтре.
Эта картинка выше показывает тайминги для работы различных частей компонента.
- getSorting_TIMER - это время получения упорядоченного списка ID товаров, используя все выборки. Это основной функционал компонента и он занимает почти половину времени работы компонента. В нем по сути ищется пересечение и разница множества массивов, один из которых содержит 12 тысяч элементов, остальные чуть меньше. В реальных условиях в разделах не хранится по 12 тысяч товаров, поэтому время работы компонента должно быть хотя бы на четверть быстрее.
- getItems_TIMER - время получения информации о товарах
- Template_TIMER - время обработки шаблона
- COMPONENT_TIMER - время работы всего компонента, включая шаблон
- COMPONENT_MEMORY_USAGE - использование оперативной памяти процессом PHP для компонента (изменение пикового значения)
- Property BRAND dictionary ready
- 0.098195 properties ready (3) - время подготовки кеша для 3 свойств инфоблока и создания справочника по брендам
- 0.009647 sections ready (7) - время подготовки кеша для всех разделов, сейчас их всего 7
- 0.367995 items-sections ready (12819) - время подготовки кеша связей товаров с разделами
- 23.35159 items ready (0) - время подготовки кеша с товарами, их около 12 тысяч
- 3.348402 sorting items ready - время пересчета всех доступных сортировок товаров
Также было проведено нагрузочное тестирование с помощью ab и siege. Под тестовую виртуальную машину было выделено 16 ядер процессора и 32 Гб памяти, используется php_fpm + nginx, opcache, PHP 7.0.23, Redis 4.0.2, Centos 7. Оценка производительности битрикса выдает 220-240 попугаев. При тестировании нагрузка на CPU была около 85%. На Redis идет около 35% нагрузки и только 1 ядра из 16.
- Запросы к первой странице без фильтрации - около 300 запросов/секунду.
- Запросы со случайными значениями ценового диапазона - 120 запросов/ в секунду.
Прочие наблюдения при работе с Redis:
- Redis может работать через сокет и по TCP. Через сокет получается в 1.5-2 раза быстрее.
- Master-slave репликация примерно на 30% снизила скорость работы master и на 10-20% для slave.
- Есть возможность записывать и читать данные сразу по множеству ключей, но на небольшом количестве данных (тысячи ключей разом) скорость почти такая же. И нельзя установить TTL сразу на пачку ключей.
- Бонусом вы можете в Redis хранить php-сессии
- Redis позволяет использовать несколько баз данных, в них можно разделить логические части. Например, если вы будете использовать Redis для хранения PHP-сессий, то они будут записываться в базу с индексом 0. Базу с индексом 1 вы можете использовать для системного кеша битрикса на Redis. Ну и базу с индексом 2 уже для хранения каких-то своих данных. Это удобно для очистки. Вы можете очистить либо всё (FLUSHALL), либо всю базу (FLUSHDB). Если у вас всё хранилось бы в одной базе с индексом 0, то при очистке кеша у вас бы очищались и сессии. А так вы можете очистить только базу с кешем битрикса или только со своими данными.
- По возможности используйте сериализацию igbinary - она сильно быстрее
Пересмотр архитектуры значительной части сайта дает существенный прирост в производительности и решает серьезные проблемы. Лично для меня результаты работы с Redis в битриксе похожи на переход с обычного HDD на SSD - тот же эффект wow! Лучший апгрейд, который мог произойти. Да, сильно дороже в производстве и поддержке, усложняется логика, повышается требование к квалификации разработчиков, но результаты того стоят. Если вы не шарашкина контора с полутора сотрудниками, то такая разработка вам по карману. То, что сейчас опубликовано и работает как концепт по времени разработки заняло 24 рабочих часа программиста. Даже если взять топовые зарплаты - это несколько десятков тысяч рублей на рабочий концепт. Ну пусть далее требуется доработка до готового решения, надо написать другие компоненты, оптимизировать, еще месяц-другой, все равно суммы здесь небольшие на разработку, вполне доступные таким компаниям, которые покупают Enterprise за полтора миллиона рублей или сервера для кластера в надежде решить проблемы с производительностью.
И это только вершина айсберга. Использование Redis, его возможности работы с данными, открывают действительно новый потенциал для Битрикса. Нулевое количество обращений к БД на нагруженном сайте - вполне реально. Сотни тысяч посещений на обычном сервере в аренде - запросто. Всё это дает сокращение инфраструктурных расходов в разы.
Адаптивный форум 2.0 и 2.5: поддержка Schema.org, рейтинги и файлы
31.10.201716:3031.10.2017 16:30:15
В этих версиях модуля было сделано несколько больших доработок. И если с загрузкой картинок и файлов все понятно, это необходимый функционал, который должен был быть реализован (описано в конце статьи), то на остальном я остановлюсь подробнее.
Поддержка микроформата Schema.org
Schema.org - это особый способ разметки html-кода, позволяющий поисковым системам определять, к чему относятся определенные фрагменты текста и объекты на странице.
Я постарался внедрить поддержку такой разметки в модуле настолько полно, насколько смог. Но для разных сайтов может потребоваться разная разметка, т.к. форум может и не называться форумом на сайте, а использоваться и для немного других целей, поэтому я сделал выбор варианта разметки (сущности) формата Schema.org в параметрах компонента:
Всего на данный момент поддерживаются 8 сущностей:
Параметры издателя (имя, адрес, телефон, логотип) используются только для типов Article и NewsArticle, для остальных типов их заполнять не нужно
После установки необходимых настроек, вы можете проверить разметку Schema.org в валидаторах:
Google:
Яндекс:
Рейтинги
Также в этой версии была добавлена поддержка рейтингов (с использованием функционала рейтингов главного модуля). Может быть использован рейтинг двух видов: "Мне нравится", "Нравится/Не нравится".
При использовании второго вида ("Нравится/Не нравится"), добавляется разметка Schema.org "aggregateRating", что может позволить поисковой системе Google отображать в поиске страницы следующим образом (звезды):
Примечание: Имейте в виду, что сама по себе разметка "aggregateRating" не гарантирует появление звезд в поиске, у Google есть свои критерии, для каких сайтов использовать сниппет со звездами, для каких - нет, и она этих критериев не раскрывает.
Компонент "Профиль пользователя"
До версии 2.5, в модуле не было своего компонента профиля пользователя. Вообще, раньше я считал что он не нужен, и профиль может быть реализован с помощью других средств, которых в системе Битрикс достаточно. Но на деле оказалось, что компонент профиля все-таки нужен, хотя бы для того, чтобы просто выводить профиль (а не редактировать), а в редакции Старт есть только стандартный main.profile. D старших же редакциях, компоненты профиля не заточены под использование вне модуля социальной сети и т.д. Поэтому я все же решил его добавить, но не как страницу комплексного компонента форум, а как отдельный комплексный компонент, позволяющий как отображать, так и редактировать профиль. Вы можете разместить его в отдельном разделе, а у комплексного компонента форума указать шаблон пути к странице пользователя.
Загрузка файлов и изображений
В зависимости от настроек компонента, будет разрешена загрузка файлов и(или) изображений с прикреплением их к теме или сообщению. Файлы можно вставлять как через подменю в визуальном редакторе, так и перенесением их на область визуального редактора (таким образом можно загрузить сразу несколько файлов).
Можно установить ограничение на количество файлов, прикрепленных к сообщению, размер одного файла, установить список расширений файлов, которые могут быть прикреплены к сообщениям.
События (программистам)
Из небольших нововведений - это возможность выводить на главной странице форума не список форумов и подразделов, а один конкретный форум, который можно выбрать в параметрах компонента (но для начала придется разместить компонент со стандартными настройками, чтобы этот форум создать).
Кроме того, был устранен ряд ошибок и произведены мелкие улучшения, например, в почтовых уведомлениях теперь присутствует якорь для перехода на добавленное/измененное сообщение на странице.
было обновлено в соответствии с добавлением новых функций
Страница модуля: |
Поддержка микроформата Schema.org
Schema.org - это особый способ разметки html-кода, позволяющий поисковым системам определять, к чему относятся определенные фрагменты текста и объекты на странице.
Я постарался внедрить поддержку такой разметки в модуле настолько полно, насколько смог. Но для разных сайтов может потребоваться разная разметка, т.к. форум может и не называться форумом на сайте, а использоваться и для немного других целей, поэтому я сделал выбор варианта разметки (сущности) формата Schema.org в параметрах компонента:
Всего на данный момент поддерживаются 8 сущностей:
- DiscussionForumPosting: обсуждение на форуме (этот тип используется по умолчанию, даже если вы ничего не выбирали)
- SocialMediaPosting: пост в социальной сети
- Article: статья
- NewsArticle: новостная статья
- TechArticle: техническая статья
- ScholarlyArticle: школьная статья
- Report: отчет
- Question: вопрос
Параметры издателя (имя, адрес, телефон, логотип) используются только для типов Article и NewsArticle, для остальных типов их заполнять не нужно
После установки необходимых настроек, вы можете проверить разметку Schema.org в валидаторах:
Google:
Яндекс:
Рейтинги
Также в этой версии была добавлена поддержка рейтингов (с использованием функционала рейтингов главного модуля). Может быть использован рейтинг двух видов: "Мне нравится", "Нравится/Не нравится".
При использовании второго вида ("Нравится/Не нравится"), добавляется разметка Schema.org "aggregateRating", что может позволить поисковой системе Google отображать в поиске страницы следующим образом (звезды):
Примечание: Имейте в виду, что сама по себе разметка "aggregateRating" не гарантирует появление звезд в поиске, у Google есть свои критерии, для каких сайтов использовать сниппет со звездами, для каких - нет, и она этих критериев не раскрывает.
Компонент "Профиль пользователя"
До версии 2.5, в модуле не было своего компонента профиля пользователя. Вообще, раньше я считал что он не нужен, и профиль может быть реализован с помощью других средств, которых в системе Битрикс достаточно. Но на деле оказалось, что компонент профиля все-таки нужен, хотя бы для того, чтобы просто выводить профиль (а не редактировать), а в редакции Старт есть только стандартный main.profile. D старших же редакциях, компоненты профиля не заточены под использование вне модуля социальной сети и т.д. Поэтому я все же решил его добавить, но не как страницу комплексного компонента форум, а как отдельный комплексный компонент, позволяющий как отображать, так и редактировать профиль. Вы можете разместить его в отдельном разделе, а у комплексного компонента форума указать шаблон пути к странице пользователя.
Загрузка файлов и изображений
В зависимости от настроек компонента, будет разрешена загрузка файлов и(или) изображений с прикреплением их к теме или сообщению. Файлы можно вставлять как через подменю в визуальном редакторе, так и перенесением их на область визуального редактора (таким образом можно загрузить сразу несколько файлов).
Можно установить ограничение на количество файлов, прикрепленных к сообщению, размер одного файла, установить список расширений файлов, которые могут быть прикреплены к сообщениям.
События (программистам)
- Добавлены события для изменения списка подписчиков на тему при отправке сообщения ()
- Добавлены события для изменения базовых фильтров для форумов, разделов результатов поиска по форумам (). Данные события позволяют, например, реализовать распределение прав доступа к форумам (или просто управлять видимостью форумов в соответствии с определенными условиями). По умолчанию, глобальные фильтры содержат массив array("SITE_ID"=>SITE_ID), т.е. на каждом сайте в многосайтовой системе битрикс будут свои форумы.
Из небольших нововведений - это возможность выводить на главной странице форума не список форумов и подразделов, а один конкретный форум, который можно выбрать в параметрах компонента (но для начала придется разместить компонент со стандартными настройками, чтобы этот форум создать).
Кроме того, был устранен ряд ошибок и произведены мелкие улучшения, например, в почтовых уведомлениях теперь присутствует якорь для перехода на добавленное/измененное сообщение на странице.
было обновлено в соответствии с добавлением новых функций
Страница модуля: |
Как выбрать в карточке товара с SKU, если известен id SKU? Компонент дефолтный. все манипуляции происходят здесь /catalog.element/.default/script.js, но непонятно что там подправить. UPD В JS можно не лезть, можно инициализировать в PHP: Так и не понял ка
25.10.201716:2925.10.2017 16:29:45
Как выбрать в карточке товара с SKU, если известен id SKU?
Компонент дефолтный.
все манипуляции происходят здесь /catalog.element/.default/script.js, но непонятно что там подправить.
UPD
В JS можно не лезть, можно инициализировать в PHP:
Так и не понял как на стороне JS выбрать SKU
$_GET['pid'] - id SKU
Компонент дефолтный.
все манипуляции происходят здесь /catalog.element/.default/script.js, но непонятно что там подправить.
UPD
В JS можно не лезть, можно инициализировать в PHP:
Так и не понял как на стороне JS выбрать SKU
$_GET['pid'] - id SKU
<?php
foreach ($arResult['JS_OFFERS'] as $ind => $jsOffer)
{
if ($jsOffer['ID']==$_GET['pid'] && !empty($jsOffer['TREE']) && is_array($jsOffer['TREE']))
{
$arResult['OFFERS_SELECTED'] = $ind;
}
}
$jsParams = array( //.......
'OFFER_SELECTED' => $arResult['OFFERS_SELECTED'],
//.......
);
|
Добрый день! Ищем партнера (разработчика) на долевой основе в проект. Санкт-Петербург. Проект на Битриксе, для того, чтобы моб. приложение работало на iOS и Android, это механика увеличения объема продаж в ресторанах. Описание проекта и кого мы ищем отпра
19.10.201711:3919.10.2017 11:39:28
Добрый день!
Ищем партнера (разработчика) на долевой основе в проект. Санкт-Петербург.
Проект на Битриксе, для того, чтобы моб. приложение работало на iOS и Android, это механика увеличения объема продаж в ресторанах.
Описание проекта и кого мы ищем отправим на почту (тут не прикрепить файлы).
1) Решаем невыдуманные и актуальные проблемы. Проверили спрос, бизнес готов тестировать.
2) Развитие экосистемы для масштабирования подобных решений в РФ (Plazius, Эвотор) и по миру. Быстрый рост, не нужно продавать предприятию адресно и интегрироваться с каждой версией ПО в POS.
3) Возможность применения в механики технологии блокчейн (безопаснее, ниже операционные издержки, добавочная ценность при выпуске токенов, возможность привлечения средств через ICO).
4) Наличие квалифицированного юриста для получения патента классическим способом и через сервис на блокчейне.
P.S. Если по правилам форума, такое сообщение является рекламным, то посоветуйте, пожалуйста, где корректнее его разместить. Спасибо.
catalog.element script.js узнать id выбранного SKU switch (this.productType) { case 1: // product case 2: // set console.log(this.product.id.toString()); break; case 3: // sku console.log(this.offers[this.offerNum].ID); break; }
18.10.201714:3718.10.2017 14:37:35
catalog.element script.js узнать id выбранного SKU
switch (this.productType)
{
case 1: // product
case 2: // set
console.log(this.product.id.toString());
break;
case 3: // sku
console.log(this.offers[this.offerNum].ID);
break;
} |
Избранное с помощью сессий, очень кратко $arFavorite = &$_SESSION['FAVORITES_BY_RUSLAN']; $arFavorite[] = ['1'];
18.10.201713:4118.10.2017 13:41:57
Избранное с помощью сессий, очень кратко
$arFavorite = &$_SESSION['FAVORITES_BY_RUSLAN']; $arFavorite[] = ['1']; |
Поиск по артикулу с обновлением поискового индекса// у товара смотрим его ТП и берем артикулы, вносим их в поле, чтобы искалось по Артикулу ТП AddEventHandler("catalog", "OnProductAdd","addIDsFromSKUs"); AddEventHandler("catalog", "OnProductUpdate","addID
17.10.201722:2417.10.2017 22:24:43
Поиск по артикулу с обновлением поискового индекса
// у товара смотрим его ТП и берем артикулы, вносим их в поле, чтобы искалось по Артикулу ТП
AddEventHandler("catalog", "OnProductAdd","addIDsFromSKUs");
AddEventHandler("catalog", "OnProductUpdate","addIDsFromSKUs");
function addIDsFromSKUs($id, $arFields)
{
$TARGET_IBLOCK_ID = 2;
$artnumbers = "";
if (CModule::IncludeModule('catalog') && CModule::IncludeModule('iblock')) {
$arProductInfo = CCatalogSKU::GetProductInfo($id);
if (is_array($arProductInfo) && $arProductInfo["IBLOCK_ID"]==$TARGET_IBLOCK_ID ) {
$arOffersInfo = CCatalogSKU::GetInfoByProductIBlock($arProductInfo['IBLOCK_ID']);
$arFilter = array(
'IBLOCK_ID' => $arOffersInfo['IBLOCK_ID'],
"PROPERTY_CML2_LINK" => $arProductInfo['ID'],
//"!ID" => $id,
);
$arSelect = Array("PROPERTY_ARTNUMBER");
$obOffersList = CIBlockElement::GetList(array("SORT"=>"ASC"), $arFilter, false, false, $arSelect);
while ($arOffers = $obOffersList->Fetch()) {
$artnumbers .= $arOffers["PROPERTY_ARTNUMBER_VALUE"]. ' ';
}
$PROPERTY_CODE = "SKU_ARTNUMBERS";
$PROPERTY_VALUE = $artnumbers;
$el_id = $arProductInfo['ID'];
$iblock_id = $arProductInfo["IBLOCK_ID"];
$prop[$PROPERTY_CODE] = array('VALUE'=>array('TYPE'=>'TEXT', 'TEXT'=>$PROPERTY_VALUE));
CIBlockElement::SetPropertyValuesEx($el_id, $iblock_id, $prop);
$res = CIBlockElement::GetByID($el_id);
$ar_res = $res->GetNext();
//переиндексируем элемент, чтобы находился в поиске
CSearch::Index(
"iblock",
$el_id,
Array(
"DATE_CHANGE"=>$ar_res["DATE_CHANGE"],
"TITLE"=>$ar_res["NAME"],
"SITE_ID"=>array('s1'),
"PARAM1"=>'catalog',//$arFields["IBLOCK_TYPE_ID"],
"PARAM2"=>'2', //$arFields['IBLOCK_ID'],
"PERMISSIONS"=>array("2"),
"URL"=>str_replace("#ID#", $ar_res["ID"], $ar_res["DETAIL_PAGE_URL"]),
"BODY"=>$ar_res["DETAIL_TEXT"].' '.$artnumbers,
"TAGS"=>$artnumbers,
),
true
);
}
}
}
AddEventHandler("iblock", "OnAfterIBlockElementUpdate", "addIDsFromElementSKUs");
AddEventHandler("iblock", "OnAfterIBlockElementAdd", "addIDsFromElementSKUs");
function addIDsFromElementSKUs(&$arFields)
{
if ($arFields['IBLOCK_ID']==2 ) {
$arOffersInfo = CCatalogSKU::GetInfoByProductIBlock($arFields['ID']);
$arFilter = array(
'IBLOCK_ID' => $arOffersInfo['IBLOCK_ID'],
"PROPERTY_CML2_LINK" => $arFields['ID'],
//"!ID" => $id,
);
$arSelect = Array("PROPERTY_ARTNUMBER");
$obOffersList = CIBlockElement::GetList(array("SORT"=>"ASC"), $arFilter, false, false, $arSelect);
while ($arOffers = $obOffersList->Fetch()) {
$artnumbers .= $arOffers["PROPERTY_ARTNUMBER_VALUE"]. ' ';
}
$PROPERTY_CODE = "SKU_ARTNUMBERS";
$PROPERTY_VALUE = $artnumbers;
$el_id = $arFields['ID'];
$iblock_id = $arFields["IBLOCK_ID"];
$prop[$PROPERTY_CODE] = array('VALUE'=>array('TYPE'=>'TEXT', 'TEXT'=>$PROPERTY_VALUE));
CIBlockElement::SetPropertyValuesEx($el_id, $iblock_id, $prop);
//переиндексируем элемент, чтобы находился в поиске
CSearch::Index(
"iblock",
$el_id,
Array(
"DATE_CHANGE"=>$arFields["DATE_CHANGE"],
"TITLE"=>$arFields["NAME"],
"SITE_ID"=>array('s1'),
"PARAM1"=>'catalog',//$arFields["IBLOCK_TYPE_ID"],
"PARAM2"=>'2', //$arFields['IBLOCK_ID'],
"PERMISSIONS"=>array("2"),
"URL"=>str_replace("#ID#", $arFields["ID"], $arFields["URL"]),
"BODY"=>$arFields["DETAIL_TEXT"].' '.$artnumbers,
"TAGS"=>$artnumbers,
),
true
);
}
}
|
