Создание группы или проекта. Правильный старт и развитие bitrix проекта Почему следует переносить проект на bitrix

16.12.2023 Отчетность

За все время своей работы с Битрикс мне довелось поработать с очень большим количеством проектов, которые кто-то разрабатывал до меня. Тут и мелкие доработки, фикс различных багов и ошибки работы логики, редизайн сайта и глобальные изменения существующего функционала. И, как и любой другой разработчик, я терпеть не могу разгребать чужой мусор, костыли и «временные» заплатки, которые на деле помнят еще 8 редакцию продукта.

Здесь я постараюсь не акцентировать внимание на стандартных «worst practice» при программировании на PHP, типа наплевательского отношения к выборам имен переменных и функций, излишних запросов к БД в цикле, отсутствия проверок пользовательских данных в формах, игнорирование комментариев и тому подобного. Я попытаюсь коснуться именно моментов, свойственных разработке на Битриксе, которые в последствии позволят избежать негодования и проклятий в ваш адрес от программиста, которому выпало сопровождать ваш код. И да, нередко этим программистом будете оказываться вы сами через год, или более, когда уже совершенно забудете, зачем вы вставляли сюда тот или иной костыль.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс

Первое, и самое, на мой взгляд, важное - ради всего святого, используйте папку local . Это просто жизненно необходимо при использовании системы контроля версий – все, что вам нужно – добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще – приводит дерево проекта в более опрятный, «человеческий» вид.

Не модифицируйте ядро . Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента – перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.

Не засоряйте файл init.php . Объединяйте функции для работы с каким-то конкретным модулем или функционалом в класс, весь этот класс записывайте в отдельный файл, а в init.php просто подключайте эти файлы и прописывайте обработчики событий. Мне встречались файлы init.php по 500Kb, где в кашу были смешаны функции, определение констант, классы и инициализация обработчиков. Разумеется, когда приходилось разбираться в этих файлах, я сыпал проклятиями на своих предшественников.

Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ – не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни . Лично я придерживаюсь философии – лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть – техзадание, варианты реализации и тому подобное, но забывать про «Бритву Оккама» все-таки не стоит. Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог – огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?

Используйте API . Не изобретайте велосипеды там, где это не нужно. Юзайте документацию – весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.

Избегайте прямых запросов к базе . Это частный случай предыдущего пункта – используйте API. Необдуманные, незащищенные запросы могут привести к порче, утере или даже к компрометации данных.

Не используйте компоненты с ЧПУ из корня сайта . Последствия, как правило, довольно печальны, так как ЧПУ использует файл обработчика адресов, попытка использовать его из корня легко ломает вам адресацию других компонентов, а так же 404 страницы. Ничего страшного не будет, если статьи у вас будут адресоваться относительно папки /articles/, а товары относительно /catalog/.

Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью html-тегов. Используйте объект класса \Bitrix\Main\Page\Asset и функции addJs() и addCss(). Это позволит объединять файлы и, в последствии, кешировать их одним нажатием чекбокса в настройках главного модуля

Ну и напоследок, ошибка касается не только Битрикса, но уж больно часто я стал встречать проблемы, связанные с ней. Проверяйте на пустоту массив с результатами выборки . Как пример, последний раз встретился с данной проблемой при работе с одним интернет-магазином. Жалоба: страницы иногда грузятся по 16 секунд. С чем связано – не ясно. Методом проб и ошибок выяснил, что страницы грузятся неприлично долго только тогда, когда корзина пустая. Казалось, с чего бы? Как выяснилось, у корзины при наведении появлялось всплывающее окно, в котором отображались изображения товара, положенного в корзину. Ну что сделал предыдущий разработчик? Взял результат работы компонента «маленькая корзина» и в файле result_modifier.php сделал вызов GetList() товаров для выборки изображений с фильтром из массива ID товаров, потом из результатов выборки в массив соответствующего товара добавлял src изображения. В итоге, когда товаров в корзине не было, фильтр уходил пустой, и в выборку попадал ВЕСЬ каталог товаров. Ну а дальше цикл по каждому и… имеем то, что имеем. Ясно, что на этапе разработки при тестовых 15 товарах это было незаметно, и проблемы возникли уже в боевых условиях. Хотя, казалось бы, чего стоило поставить проверку на empty($arResult[‘ITEMS’])…

На этом я заканчиваю свой личный топ «worst practice», касательно разработки на Битрикс. Если хоть кому-то данная информация поможет избежать ошибок в будущем и улучшить свой стиль разработки, значит это было не зря.

Вы можете помочь и перевести немного средств на развитие сайта

Клиенты обращаются к нам не только для создания нового сайта, но и за редизайном уже имеющегося. Можно выделить три основные причины из-за которых сайт нужно обновить:

Разработан новый фирменный стиль. Нужно привести сайт в соответствие.
Стоимость поддержки сайта достигла критических значений и требуется оптимизировать эту статью расходов.
Нужно добавить новый большой функционал, а имеющаяся архитектура недостаточно гибкая.

Конечно, встречаются различные комбинации этих причин. Как правило, мы рекомендуем клиентам одновременно с внешним обновлением, перенести сайт на битрикс. Это позволит заложить большие возможности по развитию проекта в будущем, снизить зависимость от подрядчиков и получить доступ к Маркетплейсу — площадке с проверенными решениями, позволяющими быстро и дешево расширять функционал своего сайта.

Первый вопрос, который мы слышим от клиентов, — «Сколько стоит переезд на Битрикс?». Ответ будет зависеть от того, какой проект мы переносим и как много функционала мы в итоге добавляем. Для сайта, продающего товары и услуги, от этого, как минимум, будет зависеть стоимость лицензии «1С-Битрикс».

Тем не менее, наша практика показывает, что редизайн сайта и перезапуск его на новой CMS стоит дороже чем создание сайта с нуля на той же. Это происходит в силу следующих обстоятельств:

Необходимость переноса всего контента со старого сайта. При этом, наибольшие проблемы возникают с каталогом, пользователями и заказами. Помимо того, что надо сохранить целостность базы, то есть все данные и связи между ними, крайне важно сохранить структуру url и конечные адреса страниц. Ведь для сайтов, имеющих хорошую видимость в поисковых системах, вариант с сохранением адресации предпочтительнее чем настройка 301 редиректов на новые адреса.
Часто, вместе с перемещением данных, требуется перенос специфического функционала, например, калькуляторов, системы скидок и т.д. Сложность заключается в том, что копируемый функционал не документирован, может содержать ошибки (особенно в граничных условиях) и, зачастую, клиент вместе с переносом, хочет немного улучшить его.
Создание инфраструктуры разработки и необходимость ее обновления перед запуском. Это означает, что, создав полную копию данных старого сайта и начав разработку, которая, в лучшем случае займет пару месяцев, перед запуском проекта вам потребуется актуализировать данные. Например, номенклатуру, цены и остатки товаров, список и заказы пользователей.
Подключение к внешним системам. Тут может скрываться большое количество подводных камней. Бывает, что клиент не может актуализировать модуль обмена в своей системе учета «1С», а вам для настройки синхронизации с 1С, как раз требуется новый модуль.
Аккуратный и тщательный запуск сайта на основном домене. Одна ошибка, которая при запуске нового сайта может не иметь никаких последствий, при редизайне может привести к серьезным проблемам.

Резюмируя вышесказанное, можно сказать что перевод сайта на «Битрикс», совмещенный с редизайном, является более сложной и дорогостоящей процедурой, чем разработка нового сайта. В сложных случаях, разница может достигать 100%, другими словами обойдется вам в два раза дороже чем создание проекта с нуля. Мы уже писали ранее о формировании стоимости, при создании проекта электронной коммерции.

Если сравнивать с магазинами, то, для корпоративных сайтов разница в трудоемкости между созданием нового сайта и редизайном старого, совмещённого со сменой платформы будет ниже, а для сайтов портального типа, разница будет немного выше.

Если же не менять систему управления, то, вероятно, лучше будет продолжать сотрудничать с вашими подрядчиками и ориентироваться на их подход к ценообразованию работ.

Очевидно, что любой проект должен оказаться на сервере, чтобы начать свою работу. Вопрос в том, как это сделать быстро, удобно и безопасно.

Автоматическое развертывание проектов (деплой)

Что же такое автоматическое развертывание проектов (деплой)? Для себя мы определили его как процесс переноса кода и структуры базы данных с локальной машины разработчика («песочницы», если угодно) на сервер (или кластер серверов), на котором в будущем и будет работать этот проект. В том числе в этот процесс входят и различного рода подготовительные операции, как, например, очистка и подогрев кэша.

Зачем он нужен? Каждый из нас на своем пути прошел разные варианты переноса проекта на «боевой» сервер: это и ftp (на нашей памяти были разработчики, которые сразу писали код на сервере, взаимодействуя с ним исключительно по ftp), и sftp, и rsycn, и git pull — все эти способы имеют множество недостатков, а главное, что они требуют монотонной рутинной работы. Мы решили, что лучше потратить это время на разработку, а всю монотонность доверить машине.

Требования к системе деплоя

Для начала мы определились с требованиями к подобной системе:

должна быть возможность развертывать проект сразу на несколько площадок или на одну из них по выбору — для каждого проекта у нас есть, как минимум, две площадки (боевая и тестовая), кроме того, некоторые проекты используют кластер серверов,
разворачивать проекты нужно из репозитория, а, кроме того, должна быть возможность развернуть разные ветки репозитория на разные площадки,
должна быть возможность быстро откатиться к предыдущему релизу,
процесс обновления должен быть максимально незаметным для пользователей сайта,
система должна быть расширяемой и позволять вводить любые дополнительные операции, которые нам потребуются (установка пакетов composer, миграции бд и т.д.),
сама система должна быстро разворачиваться и настраиваться для любого проекта,
должна быть написана на php — очевидно, что у php-разработчика настроено окружение для работы с php и заставлять его настраивать ради деплоя окружение для работы с, например, ruby — бессердечно.

Скрипты деплоя для php

Мы начали искать подходящее готовое решение. Jenkins, Capistrano и т.д. были отброшены сразу же, несмотря на их популярность. Нам нужен был скрипт, написанный на php.

Теперь, чтобы развернуть скелет проекта достаточно выполнить в консоли

composer create-project marvin255/bitrix-base

composer create - project marvin255 / bitrix - base

и вы получите всю структуру проекта, свежие версии composer, rocketeer и bitrixsetup.php. Чисто и быстро.

Как же заставить это работать?

Возможно, вначале настройка деплоя покажется вам сложной и ненужной, но мы гарантируем: стоит только попробовать и вы не сможете отказаться от rocketeer.

Для примера, алгоритм из нашего внутреннего регламента по созданию нового проекта

Разработчик сообщает серверному специалисту, что нужно настроить проект, сообщает название проекта латиницей.
Разработчик создает репозиторий в своем аккаунте в gitlab и инициирует проект пустым README.MD файлом.
Разработчик клонирует репозиторий на свой локальный стенд.
Разработчик создает структуру папок согласно статье 3 данного регламента и наполняет все служебные файлы (.gitignore, composer.json, README.MD и т.д.) или разворачивает стандартный проект с помощью команды composer create-project marvin255/bitrix-base.
Разработчик копирует в папку web файл bitrixsetup.php и с помощью него устанавливает «1С-Битрикс: Управление сайтом».
Разработчик настраивает в файле /web/local/php_interface/init.php подключение файла /vendor/autoload.php.
Разработчик инициирует composer командой php composer.phar install.
Серверный специалист сообщает разработчику все данные по тестовому серверу.
Разработчик настраивает в проекте Rocketeer согласно статье 6 данного регламента.
Разработчик вносит все изменения с локальной машины в репозиторий.
Разработчик на тестовом сервере создает ssh-ключ для пользователя проекта с помощью команды ssh-keygen. Ключ должен создаваться по стандартному пути ~/.ssh/id_rsa.pub, без указания пароля.
Разработчик добавляет открытую часть ключа, созданного ранее, в deploy keys проекта в корпоративный gitlab.
Разработчик добавляет домен корпоративного gitlab в authorized_keys для пользователя проекта.
Разработчик создает на тестовом сервере в домашней папке проекта папки shared/web/upload и shared/web/bitrix/backup.
Разработчик создает на тестовом сервере в домашней папке проекта файлы shared/web/bitrix/.settings.php и shared/web/bitrix/php_interface/dbconn.php и указывает в них верные данные для подключения к серверной базе данных.
Разработчик переносит базу данных с помощью дампа с локальной машины на тестовый сервер.
Разработчик заходит в папку проекта на своем локальном стенде в командной строке и выполняет команду php rocketeer.phar deploy.
Разработчик проверяет работоспособность тестового сайта.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» © Джон Ф. Вудс

Первое, и самое, на мой взгляд, важное - ради всего святого, используйте папку local . Это просто жизненно необходимо при использовании системы контроля версий — все, что вам нужно — добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще — приводит дерево проекта в более опрятный, «человеческий» вид.

Не модифицируйте ядро . Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента — перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.

Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ — не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни . Лично я придерживаюсь философии — лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть — техзадание, варианты реализации и тому подобное, но забывать про «Бритву Оккама» все-таки не стоит. Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог — огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?

Используйте API . Не изобретайте велосипеды там, где это не нужно. Юзайте документацию — весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.

Избегайте прямых запросов к базе . Это частный случай предыдущего пункта — используйте API. Необдуманные, незащищенные запросы могут привести к порче, утере или даже к компрометации данных.

Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью html-тегов. Используйте объект класса \Bitrix\Main\Page\Asset и функции addJs () и addCss (). Это позволит объединять файлы и, в последствии, кешировать их одним нажатием чекбокса в настройках главного модуля

Ну и напоследок, ошибка касается не только Битрикса, но уж больно часто я стал встречать проблемы, связанные с ней. Проверяйте на пустоту массив с результатами выборки . Как пример, последний раз встретился с данной проблемой при работе с одним интернет-магазином. Жалоба: страницы иногда грузятся по 16 секунд. С чем связано — не ясно. Методом проб и ошибок выяснил, что страницы грузятся неприлично долго только тогда, когда корзина пустая. Казалось, с чего бы? Как выяснилось, у корзины при наведении появлялось всплывающее окно, в котором отображались изображения товара, положенного в корзину. Ну что сделал предыдущий разработчик? Взял результат работы компонента «маленькая корзина» и в файле result_modifier.php сделал вызов GetList () товаров для выборки изображений с фильтром из массива ID товаров, потом из результатов выборки в массив соответствующего товара добавлял src изображения. В итоге, когда товаров в корзине не было, фильтр уходил пустой, и в выборку попадал ВЕСЬ каталог товаров. Ну, а дальше цикл по каждому и… имеем то, что имеем. Ясно, что на этапе разработки при тестовых 15 товарах это было незаметно, и проблемы возникли уже в боевых условиях. Хотя, казалось бы, чего стоило поставить проверку на empty ($arResult[«ITEMS»])…

Если вам необходимо реализовать какой-то проект, вы можете создать группу, пригласить в нее только тех сотрудников, которые имеют отношение к этому проекту, поставить им задачи, загрузить необходимые файлы. Группы помогают сгруппировать все данные, задачи, файлы, сообщения, встречи в одном месте. Вы всегда сможете просмотреть какие действия, какие задачи были выполнены в той или иной группе.

В Битрикс24 есть группы и проекты. Основное отличие группы от проекта – в проекте можно задать сроки реализации проекта, сроки задач в проекте не могут выходить за рамки сроков проекта.

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

Подробнее о создании группы или проекта можно прочитать .

2. Кто может создавать группы и проекты?

Каждый сотрудник может создавать группу или проект и приглашать в нее участников. Количество групп и проектов в Битрикс24 неограниченно на всех тарифах.

3. Как посмотреть все группы (проекты), которые есть на портале?

Все группы на портале может посмотреть сотрудник с правами администратора. Для этого нужно .

4. Как архивировать группу (проект)?

Для этого во вкладке группы Основное выбрать меню Действия и в нем пункт Редактировать группу (проект) . В открывшемся окне отметить Тип группы (проекта): Архивный .

Архивные группы и проекты не отображаются в общем списке групп. Найти их можно по фильтру Архивные либо с помощью поискового запроса.

Вернуть архивную группу (проект) в работу можно аналогичным способом – снять галочку с типа группы Архивная .

5. Как удалить группу?

Для удаления группы выберите во вкладке группы Основное пункт меню Действия > Удалить группу :

После клика откроется форма подтверждения удаления группы.

Если к группе (проекту) привязаны какие-то задачи, то нужно сначала открепить или удалить задачи, а потом уже можно будет удалить саму группу (проект).

6. Как удалить группу (проект), которая принадлежит уволенному сотруднику?

Удалить такую группу может администратор портала. Для этого нужно на странице Моя страница и далее в меню Действия выбрать пункт Удалить группу :

Если группа или проект еще нужны, то можно просто поменять владельца группы (руководителя проекта) через меню Действия : либо в Редактировании группы (проекта) , либо в Редактировании состава .

7. Можно ли запретить участникам группы (проекта) видеть друг друга?

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

При этом если у вас несколько экстранет-групп (проектов), то между собой участники не видят друг друга.

8. Как пригласить экстранет-пользователя в группу (проект)?

Пользователей можно пригласить как непосредственно при создании рабочей группы (проекта), так в любой момент после создания рабочей группы (проекта) на закладке Основное страницы уже существующей группы или проекта (меню Действия > Пригласить в группу ).